From nobody Mon Apr 2 12:11:22 2018 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 8CF7F1267BB for ; Mon, 2 Apr 2018 12:11:20 -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, T_KAM_HTML_FONT_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rlbcB6oz_z-U for ; Mon, 2 Apr 2018 12:11:18 -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 3101C1241F8 for ; Mon, 2 Apr 2018 12:11:18 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.90_1) (envelope-from ) id 1f34rK-00054E-TI; Mon, 02 Apr 2018 20:11:15 +0100 From: "Jon Shallow" To: "'Daniel Migault'" , References: <152224582267.29792.2214827071198414612.idtracker@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C118E01184@eusaamb107.ericsson.se> In-Reply-To: <2DD56D786E600F45AC6BDE7DA4E8A8C118E01184@eusaamb107.ericsson.se> Date: Mon, 2 Apr 2018 20:11:14 +0100 Message-ID: <006001d3cab6$5edae9e0$1c90bda0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0061_01D3CABE.C0A126A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKGPvhN1FLF8NzSBt1zDUXxGEjJuQK7/3caonL8b0A= Content-Language: en-gb Archived-At: Subject: Re: [Dots] FW: New Version Notification for draft-ietf-dots-use-cases-11.txt 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, 02 Apr 2018 19:11:20 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0061_01D3CABE.C0A126A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Daniel, This is looking good to me. Several nits Nit #1 3.1 o On the other hand, the ITP may identify an enterprise network as the source of an attack and send a mitigation request for the enterprise to mitigate this at the source. Who is the mitigation request sent to? - perhaps ".. send a mitigation request to the enterprise DMS to mitigate .." Nit #2 3.1 The DOTS Server signals the DOTS Client that it can serve this request, and mitigation is initiated on the ITP network by the DMS. Perhaps for clarity ".. on the ITP network by the ITP's DMS." to clarify the DMS referred to. Nit #3 3.1 The current scenario describes the case where the DDoS Target is in the enterprise network while the DMS is provided by the upstream ITP. As the DMS term is used for both the enterprise and ITP in 3.1, which DMS does this refer to? - It would be assumptive to say that the enterprise DMS is (implied always) provided by the upstream ITP as this may not be the case - perhaps ".. while the secondary DMS is provided by the ...." to keep the focus on the ITP, or - perhaps ".. while the secondary DDoS Mitigation is provided by the upstream ITP." Nit #4 3.2 In order to steer the traffic to the DDoS Mitigation Service Provider, some network configuration are required. " some network configuration are" does not parse - perhaps "some network configuration changes are" Nit #5 3.2 Figure 3 | | | Provider | | +--------+ | | DDoS Attack | | DDoS | |<----------------+ | ++==== | | Target | | | | | || ++= | +--------+ | | | | || || It is not immediately clear that the "cleansed" traffic is the now the upper single dotted line between the ITP and Enterprise. - perhaps the addition of the word Mitigated just above the arrow as per | | | Provider | | +--------+ | Mitigated DDoS Attack | | DDoS | |<----------------+ | ++==== | | Target | | | | | || ++= | +--------+ | | | | || || Nit #6 3.2 requesting Enterprise Network DOTS Client sends a DOTS DDoS Mitigation termination requests to the DDoS Mitigation Service Provider. - perhaps singular "..Mitigation termination request to the DDoS.." Nit #7 3.3 interface. If the network administrator decides to start the mitigation, she orders through her web interface a DOTS Client to send a request for DDoS mitigation. This request is expected to be Female? - perhaps "..mitigation, they order through their web interface a DOTS Client .." Nit #8 3.3 Orchestration of the DDoS mitigation systems works similarly as described in Section XXX. The Orchestrator indicates with its status whether the DDoS Mitigation is effective. - perhaps ".. described in Section 3.1. The .." Nit #9 4. The DOTS protocol MUST be designed for minimal data transfer to address the blocking risk. Is the MUST relevant to Use Cases? - perhaps "The DOTS protocol is designed for .." Regards Jon -----Original Message----- From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Daniel Migault Sent: 28 March 2018 15:24 To: dots@ietf.org Subject: [Dots] FW: New Version Notification for draft-ietf-dots-use-cases-11.txt Hi everyone! Please find the draft-ietf-dots-use-cases-11 [1]. In order to meet the aggressive schedule agreed during the session in London, we would greatly appreciate your feed backs by the end of the week ! The current document is limited to 3 use cases described over 10ish pages. We believe the current document addresses the feed backs and comments we received from the London session. If you believe otherwise, feel free to bring this on the mailing list. We expect to publish version 12 on Tuesday April 3. This version is expected to address the received comments and be ready to WGLC. Comments can be addressed directly to the mailing list or using github pull requests on the mkd version [2]. If you believe some discussions are needed, please consider discussing those on the mailing list. Yours, Daniel [1] https://datatracker.ietf.org/doc/draft-ietf-dots-use-cases/ [2] https://github.com/dotswg/dots-use-cases/blob/master/draft-ietf-dots-use-cas es.mkd ------=_NextPart_000_0061_01D3CABE.C0A126A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Daniel,

 

This is looking good to me. 

 

Several nits

 

Nit = #1

 

3.1

   o  On the other hand, the ITP may = identify an enterprise network as

      the source of an = attack and send a mitigation request for the

      enterprise to = mitigate this at the source.

 

Who is = the mitigation request sent to?

- = perhaps ".. send a mitigation request to the enterprise DMS to = mitigate .."

 

Nit = #2

 

3.1

  =      The DOTS Server signals

   the DOTS Client that it can serve this = request, and mitigation is

   initiated on the ITP network by the = DMS.

 

Perhaps for clarity ".. on the ITP network by = the ITP's DMS." to clarify the DMS referred to.

 

Nit = #3

3.1

   The current scenario describes the = case where the DDoS Target is in

   the enterprise network while the DMS = is provided by the upstream ITP.

 

As the = DMS term is used for both the enterprise and ITP in 3.1, which DMS does = this refer to?

- It would be = assumptive to say that the enterprise DMS is (implied always) provided = by the upstream ITP as this may not be the case

- perhaps ".. while the secondary DMS is = provided by the ...." to keep the focus on the ITP, = or

- perhaps ".. while the = secondary DDoS Mitigation is provided by the upstream = ITP."

 

Nit #4

3.2

      In order = to

   steer the traffic = to the DDoS Mitigation Service Provider, some

   network configuration are = required.

 

" some network configuration are" does = not parse

- perhaps "some = network configuration changes are"

 

Nit = #5

3.2 Figure 3

 

     = |          =         |    =     | = Provider         = |

     |      = +--------+  |        = |            = DDoS Attack

     |      | = DDoS   |  = |<----------------+         | = ++=3D=3D=3D=3D

     |      | Target = |  |        = |        = |         | || = ++=3D

     |      = +--------+  |        = |   =      |       =   | || ||

 

It is = not immediately clear that the "cleansed" traffic is the now = the upper single dotted line between the ITP and = Enterprise.

- perhaps the addition = of the word Mitigated just above the arrow as per

 

     = |            =       = |        | = Provider         = |

     |      = +--------+  |  = Mitigated        =        DDoS = Attack

     |      | = DDoS   |  = |<----------------+         | = ++=3D=3D=3D=3D

     |      | Target = |  |        = |        = |         | || = ++=3D

     |      = +--------+  |        = |        = |         | || = ||

 

Nit #6

3.2

   requesting Enterprise Network DOTS = Client sends a DOTS DDoS

   Mitigation termination requests to the = DDoS Mitigation Service

   Provider.

 

- = perhaps singular “..Mitigation termination request to the = DDoS..”

 

Nit = #7

3.3

   interface.  If the network = administrator decides to start the

   mitigation, she orders through her web = interface a DOTS Client to

   send a request for DDoS = mitigation.  This request is expected to be

 

Female?

- = perhaps “..mitigation, they order through their web interface a = DOTS Client ..”

 

Nit = #8

3.3

   Orchestration of the DDoS mitigation = systems works similarly as

   described in Section XXX.  The = Orchestrator indicates with its status

   whether the DDoS Mitigation is = effective.

 

- perhaps “.. described in Section 3.1.  = The ..”

 

Nit = #9

4.

       The DOTS = protocol MUST be

   = designed for minimal data transfer to address the blocking = risk.

 

Is the MUST relevant to Use Cases?

- perhaps “The DOTS protocol is designed for = ..”

 

Regards

 

Jon

 

-----Original = Message-----
From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = Daniel Migault
Sent: 28 March 2018 15:24
To: = dots@ietf.org
Subject: [Dots] FW: New Version Notification for = draft-ietf-dots-use-cases-11.txt

 

Hi = everyone!

 

Please find the draft-ietf-dots-use-cases-11 [1]. = In order to meet the aggressive schedule agreed during the session in = London, we would greatly appreciate your feed backs by the end of the = week !

 

The current document is limited to 3 use cases = described over 10ish pages. We believe the current document addresses = the feed backs and comments we received from the London session. If you = believe otherwise, feel free to bring this on the mailing = list.

 

We expect to publish version 12 on Tuesday April 3. = This version is expected to address the received comments and be ready = to WGLC.

 

Comments can be addressed directly to the mailing = list or using github pull requests on the mkd version [2]. If you = believe some discussions are needed, please consider discussing those on = the mailing list.

 

Yours, =

Daniel

[1] https://datatracker.ietf.= org/doc/draft-ietf-dots-use-cases/

[2]  https://github.com/dotswg= /dots-use-cases/blob/master/draft-ietf-dots-use-cases.mkd=

 

 

------=_NextPart_000_0061_01D3CABE.C0A126A0-- From nobody Mon Apr 2 14:12:36 2018 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 C469D12D954 for ; Mon, 2 Apr 2018 14:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgTVoJ5-mPVc for ; Mon, 2 Apr 2018 14:12:33 -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 3A9EB12D94A for ; Mon, 2 Apr 2018 14:12:33 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.90_1) (envelope-from ) id 1f36kh-000582-0H; Mon, 02 Apr 2018 22:12:31 +0100 From: "Jon Shallow" To: "'Roman Danyliw'" , Date: Mon, 2 Apr 2018 22:12:30 +0100 Message-ID: <000001d3cac7$4fb34e10$ef19ea30$@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: AdPKx0+dxziH6OukRFeqrg1ByVaF6g== Content-Language: en-gb Archived-At: Subject: Re: [Dots] Reminder -- RE: Second WGLC on DOTS Requirements 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, 02 Apr 2018 21:12:35 -0000 In general, this document is looking good to me. Some Nits Nit #1 SIG-007 DOTS servers MUST treat a mitigation terminated due to lifetime expiration exactly as if the DOTS client originating the mitigation had asked to end the mitigation, including the active- but-terminating period, as described above in SIG-005. Should be ".. as described above in SIG-006." Nit #2 DM-008 Heartbeat Interval Representation: The data model MUST be able to represent the DOTS agent's preferred heartbeat interval, which the client may include when establishing the signal channel, as described in SIG-003. Should be "... as described in SIG-004." Regards Jon -----Original Message----- From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Roman Danyliw Sent: 29 March 2018 12:44 To: dots@ietf.org Subject: [Dots] Reminder -- RE: Second WGLC on DOTS Requirements Hello! As a reminder, this WGLC closes on April 4, 2018. Please provide any comments by then. Thank, Roman > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Roman Danyliw > Sent: Wednesday, March 21, 2018 6:16 AM > To: dots@ietf.org > Subject: [Dots] Second WGLC on DOTS Requirements > > Hello! > > Consistent with our discussion at the London meeting, we are starting > a second working group last call (WGLC) for the DOTS Requirements draft: > > Distributed Denial of Service (DDoS) Open Threat Signaling > Requirements > draft-ietf-dots-requirements-14 > https://tools.ietf.org/html/draft-ietf-dots-requirements-14 > > Please send comments to the DOTS mailing list. The WG welcomes > feedback on needed changes as well as endorsements that this draft is ready. > > This second WGLC will end on April 4, 2018. > > Thanks, > Roman > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Mon Apr 2 17:08:38 2018 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 4900312D889 for ; Mon, 2 Apr 2018 17:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 (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 qunBJc5O4lFZ for ; Mon, 2 Apr 2018 17:08:32 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::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 30AF2127076 for ; Mon, 2 Apr 2018 17:08:32 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id r82so31036473wme.0 for ; Mon, 02 Apr 2018 17:08:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=4Jbr+sM9IULmEnv8+KMniUrPhTwXUEzQI0Kp3/RxoKI=; b=JTgODxUTmcD2XTUR0lpXMJFn2y9OfhrFg9D737RbSdiKbJNeFsDy3TvsVv10/YplzX GzlMwuiobxVM4Khpi7H0g6DyP3RDmN8kQiuAC6HAB6/COOoDAVEu0O0lpG6IeA1HuHz/ VqR++tfCJV3rd0n34OXpAp1AY+xi+Hqck6klRSujV1KNHUJDRQH1BWRLSWXclOAsL5/b /89oXAS2w/xcHUf5ZECDERumRoRThWx8OQNcKcMDsGOvjdZ61oDb1dhV+lR2Yvifuzgr 7iD2MoLHJBcklRJMUygRD0pZv24HJLjvihvG1QxVMT4oCTk3BeL+H266YTAadH3rCcK3 OcjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=4Jbr+sM9IULmEnv8+KMniUrPhTwXUEzQI0Kp3/RxoKI=; b=X7bCOyMaE81T/pGfzbac+4ZEbuf24EWYPJwf+9W0JAVWGUkO1YEEXD5AbNZ52q1H1F BpvEiteQc2J3gmEXiTZ8dPB+etNfUcVS3/8jLLdta5+8997tDAAXvkZgSo3PohPVYEQs vR/aiX7RiddpJF/Si3xqooUu4zZJukH3GEEZQmjRJQoFgiY5Qe2J1Zc+FuPL44G8QlRq 8lQJ2dx4sCIb1xryiCb2n5ryyYi9qgIgrvcVbnTWivmTggxs26BKZUI/SqhcI0sXKVLB rjnHNl9AZB6qaRuGUHWV0Zl1PyxY4/tFssQI39+YhDSy41TQSrZQwvsg00qVoCVE41bx AvPQ== X-Gm-Message-State: AElRT7HPL87L64hc2Dt+8w4VL8MA5JwYrzk1UejpWE1/Uq/nC1Qdau9g 30qy/TRtdQLTSXj1tXQxPU0tu/8W5rXf04OLKZQ= X-Google-Smtp-Source: AIpwx49invGVXQg62fykXQiRtLuHa6zkYwDysXr6+eeUqJ0fgEWudfuG2y7MfFOKERby+rm7wYKylZBooB7roFoQ7jo= X-Received: by 10.46.44.1 with SMTP id s1mr6776514ljs.70.1522714110685; Mon, 02 Apr 2018 17:08:30 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.130.68 with HTTP; Mon, 2 Apr 2018 17:08:30 -0700 (PDT) In-Reply-To: <006001d3cab6$5edae9e0$1c90bda0$@jpshallow.com> References: <152224582267.29792.2214827071198414612.idtracker@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C118E01184@eusaamb107.ericsson.se> <006001d3cab6$5edae9e0$1c90bda0$@jpshallow.com> From: Daniel Migault Date: Mon, 2 Apr 2018 20:08:30 -0400 X-Google-Sender-Auth: 1kdf6W1NvT8IU2RPIL-JrNZtuBc Message-ID: To: Jon Shallow Cc: dots@ietf.org Content-Type: multipart/alternative; boundary="f4f5e80728cca9741b0568e6819f" Archived-At: Subject: Re: [Dots] FW: New Version Notification for draft-ietf-dots-use-cases-11.txt 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, 03 Apr 2018 00:08:36 -0000 --f4f5e80728cca9741b0568e6819f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jon, Thank you very much for the feed backs. I will add them in the next version= ! Yours, Daniel On Mon, Apr 2, 2018 at 3:11 PM, Jon Shallow wrote: > Hi Daniel, > > > > This is looking good to me. > > > > Several nits > > > > Nit #1 > > > > 3.1 > > o On the other hand, the ITP may identify an enterprise network as > > the source of an attack and send a mitigation request for the > > enterprise to mitigate this at the source. > > > > Who is the mitigation request sent to? > > - perhaps ".. send a mitigation request to the enterprise DMS to mitigate > .." > > > > Nit #2 > > > > 3.1 > > The DOTS Server signals > > the DOTS Client that it can serve this request, and mitigation is > > initiated on the ITP network by the DMS. > > > > Perhaps for clarity ".. on the ITP network by the ITP's DMS." to clarify > the DMS referred to. > > > > Nit #3 > > 3.1 > > The current scenario describes the case where the DDoS Target is in > > the enterprise network while the DMS is provided by the upstream ITP. > > > > As the DMS term is used for both the enterprise and ITP in 3.1, which DMS > does this refer to? > > - It would be assumptive to say that the enterprise DMS is (implied > always) provided by the upstream ITP as this may not be the case > > - perhaps ".. while the secondary DMS is provided by the ...." to keep th= e > focus on the ITP, or > > - perhaps ".. while the secondary DDoS Mitigation is provided by the > upstream ITP." > > > > Nit #4 > > 3.2 > > In order to > > steer the traffic to the DDoS Mitigation Service Provider, some > > network configuration are required. > > > > " some network configuration are" does not parse > > - perhaps "some network configuration changes are" > > > > Nit #5 > > 3.2 Figure 3 > > > > | | | Provider | > > | +--------+ | | DDoS Attack > > | | DDoS | |<----------------+ | ++=3D=3D=3D=3D > > | | Target | | | | | || ++=3D > > | +--------+ | | | | || || > > > > It is not immediately clear that the "cleansed" traffic is the now the > upper single dotted line between the ITP and Enterprise. > > - perhaps the addition of the word Mitigated just above the arrow as per > > > > | | | Provider | > > | +--------+ | Mitigated DDoS Attack > > | | DDoS | |<----------------+ | ++=3D=3D=3D=3D > > | | Target | | | | | || ++=3D > > | +--------+ | | | | || || > > > > Nit #6 > > 3.2 > > requesting Enterprise Network DOTS Client sends a DOTS DDoS > > Mitigation termination requests to the DDoS Mitigation Service > > Provider. > > > > - perhaps singular =E2=80=9C..Mitigation termination request to the DDoS.= .=E2=80=9D > > > > Nit #7 > > 3.3 > > interface. If the network administrator decides to start the > > mitigation, she orders through her web interface a DOTS Client to > > send a request for DDoS mitigation. This request is expected to be > > > > Female? > > - perhaps =E2=80=9C..mitigation, they order through their web interface a= DOTS > Client ..=E2=80=9D > > > > Nit #8 > > 3.3 > > Orchestration of the DDoS mitigation systems works similarly as > > described in Section XXX. The Orchestrator indicates with its status > > whether the DDoS Mitigation is effective. > > > > - perhaps =E2=80=9C.. described in Section 3.1. The ..=E2=80=9D > > > > Nit #9 > > 4. > > The DOTS protocol MUST be > > designed for minimal data transfer to address the blocking risk. > > > > Is the MUST relevant to Use Cases? > > - perhaps =E2=80=9CThe DOTS protocol is designed for ...=E2=80=9D > > > > Regards > > > > Jon > > > > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Daniel Migault > Sent: 28 March 2018 15:24 > To: dots@ietf.org > Subject: [Dots] FW: New Version Notification for > draft-ietf-dots-use-cases-11.txt > > > > Hi everyone! > > > > Please find the draft-ietf-dots-use-cases-11 [1]. In order to meet the > aggressive schedule agreed during the session in London, we would greatly > appreciate your feed backs by the end of the week ! > > > > The current document is limited to 3 use cases described over 10ish pages= . > We believe the current document addresses the feed backs and comments we > received from the London session. If you believe otherwise, feel free to > bring this on the mailing list. > > > > We expect to publish version 12 on Tuesday April 3. This version is > expected to address the received comments and be ready to WGLC. > > > > Comments can be addressed directly to the mailing list or using github > pull requests on the mkd version [2]. If you believe some discussions are > needed, please consider discussing those on the mailing list. > > > > Yours, > > Daniel > > [1] https://datatracker.ietf.org/doc/draft-ietf-dots-use-cases/ > > [2] https://github.com/dotswg/dots-use-cases/blob/master/ > draft-ietf-dots-use-cases.mkd > > > > > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > > --f4f5e80728cca9741b0568e6819f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jon,

Thank you very much f= or the feed backs. I will add them in the next version!

Yours,=
Daniel

On Mon, Apr 2, 2018 at 3:11 PM, Jon Shallow <= ;supjps-ietf= @jpshallow.com> wrote:

Hi Da= niel,

<= /u>=C2=A0

This is= looking good to me.=C2=A0

=C2=A0

Several nits

=C2=A0

Nit #1

=C2=A0

3.1

=C2=A0=C2=A0 o=C2=A0 On the other hand, the ITP may identify an enterpri= se network as

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the source of an attack and send a mitig= ation request for the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 enterprise to mitigate this at t= he source.

=C2=A0

Wh= o is the mitigation request sent to?

- perhaps ".. send a mitigation request to = the enterprise DMS to mitigate .."

=C2=A0

Nit #2

=C2=A0

3.1

=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0The DOTS Server signals=

=C2=A0=C2= =A0 the DOTS Client that it can serve this request, and mitigation is

=C2=A0=C2=A0 in= itiated on the ITP network by the DMS.

=C2=A0

Perhaps for clarity ".. on the ITP network b= y the ITP's DMS." to clarify the DMS referred to.

=C2=A0

Nit #3

3.1

=C2=A0=C2=A0 The current scenario desc= ribes the case where the DDoS Target is in

=C2=A0=C2=A0 the enterprise network while = the DMS is provided by the upstream ITP.

=C2=A0

As the DMS term is used for both the enterprise= and ITP in 3.1, which DMS does this refer to?

- It would be assumptive to say that t= he enterprise DMS is (implied always) provided by the upstream ITP as this = may not be the case

- perhaps ".. while the secondary DMS is provided by the ...= ." to keep the focus on the ITP, or

- perhaps ".. while the secondary DDoS = Mitigation is provided by the upstream ITP."

=C2=A0

Nit #4

3.2

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 In order to

=C2=A0=C2=A0 s= teer the traffic to the DDoS Mitigation Service Provider, some

=C2=A0=C2=A0 network c= onfiguration are required.

=C2=A0

" some network configuration are" does not parse=

- perhaps &q= uot;some network configuration changes are"

=C2=A0

Nit #5

3.2 Figure 3

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | Provider=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 +--------+=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 DD= oS Attack

= =C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | DDoS=C2=A0=C2=A0= |=C2=A0 |<----------------+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 | ++=3D=3D=3D=3D

=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | Ta= rget |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 | || ++=3D

=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--------+=C2= =A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | || ||=

=C2=A0

It is= not immediately clear that the "cleansed" traffic is the now the= upper single dotted line between the ITP and Enterprise.

=

- perhaps the addition of t= he word Mitigated just above the arrow as per

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | Provider=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 +--------+=C2=A0 |=C2=A0 Mitigated=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0DDoS Attack

=C2=A0=C2=A0=C2= =A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | DDoS=C2=A0=C2=A0 |=C2=A0 |<-= ---------------+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | ++=3D=3D= =3D=3D

=C2= =A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | Target |=C2=A0 |=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | || ++=3D

=C2=A0=C2=A0= =C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--------+=C2=A0 |=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | || ||

=C2=A0=

Nit #6

3.2

=C2=A0=C2=A0 requesting Enterpri= se Network DOTS Client sends a DOTS DDoS

=C2=A0=C2=A0 Mitigation termination requests= to the DDoS Mitigation Service

=C2=A0=C2=A0 Provider.

=C2=A0

- perhaps singular =E2=80=9C..Mitigation te= rmination request to the DDoS..=E2=80=9D

=C2=A0

Nit #7

3.3

=C2=A0=C2=A0 interface.=C2=A0 If the network administrat= or decides to start the

=C2=A0=C2=A0 mitigation, she orders through her web interface= a DOTS Client to

=C2=A0=C2=A0 send a request for DDoS mitigation.=C2=A0 This request= is expected to be

=C2=A0

Female?

- perhaps =E2=80=9C..mitigation, they order through their web interface= a DOTS Client ..=E2=80=9D

=C2=A0

Nit #8

3.3

=C2=A0=C2=A0 Orchestration of the DDoS mitigation systems works simila= rly as

=C2= =A0=C2=A0 described in Section XXX.=C2=A0 The Orchestrator indicates with i= ts status

= =C2=A0=C2=A0 whether the DDoS Mitigation is effective.

=C2=A0

- perhaps =E2=80=9C.. described i= n Section 3.1.=C2=A0 The ..=E2=80=9D

=C2=A0

Nit #9

4.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The DOTS protocol MUST b= e

=C2=A0= =C2=A0 designed for minimal data transfer to address the blocking risk.<= /u>

=C2=A0=

Is the MUST rele= vant to Use Cases?

- perhaps =E2=80=9CThe DOTS protocol is designed for ...=E2=80=9D<= u>

=C2= =A0

Regards

=C2=A0

Jon

=C2=A0

-----Original Mes= sage-----
From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Daniel Migault
= Sent: 28 March 2018 15:24
To: dots@ietf.org
Subject: [Dots] FW: New Version Notification = for draft-ietf-dots-use-cases-11.txt

=C2=A0

Hi everyone!

=C2=A0

Please find the draft-ietf-dots-use-cases-11 [1]. In = order to meet the aggressive schedule agreed during the session in London, = we would greatly appreciate your feed backs by the end of the week !

=C2=A0

The current docume= nt is limited to 3 use cases described over 10ish pages. We believe the cur= rent document addresses the feed backs and comments we received from the Lo= ndon session. If you believe otherwise, feel free to bring this on the mail= ing list.

= =C2=A0

We = expect to publish version 12 on Tuesday April 3. This version is expected t= o address the received comments and be ready to WGLC.

=C2=A0

Comments can be addressed directl= y to the mailing list or using github pull requests on the mkd version [2].= If you believe some discussions are needed, please consider discussing tho= se on the mailing list.

=C2=A0

Yours,

Daniel

[1] https://datatracker.ietf.org/doc/draft-ietf-dots-use-cases/

[2]= =C2=A0 https://github.com/dotswg/dots-use-cases/blob/= master/draft-ietf-dots-use-cases.mkd

=C2=A0

=C2=A0


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


--f4f5e80728cca9741b0568e6819f-- From nobody Mon Apr 2 17:21:09 2018 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 37FF812DA1A for ; Mon, 2 Apr 2018 17:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9uobeRMfwPU for ; Mon, 2 Apr 2018 17:21:06 -0700 (PDT) Received: from guri.nttv6.jp (guri.nttv6.jp [115.69.228.140]) by ietfa.amsl.com (Postfix) with ESMTP id 03A6D12DA21 for ; Mon, 2 Apr 2018 17:21:05 -0700 (PDT) Received: from z.nttv6.jp (z.nttv6.jp [192.168.8.15]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id BB30925F68D; Tue, 3 Apr 2018 09:21:04 +0900 (JST) Received: from [IPv6:::1] (fujiko.nttv6.jp [115.69.228.141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 9711E7634F7; Tue, 3 Apr 2018 09:21:04 +0900 (JST) To: Roman Danyliw , "dots@ietf.org" References: <359EC4B99E040048A7131E0F4E113AFC014C373711@marathon> From: kaname nishizuka Message-ID: <9ef8b562-7674-07ab-d6ef-eb8e8ecaa37c@nttv6.jp> Date: Tue, 3 Apr 2018 09:21:04 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC014C373711@marathon> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Dots] Reminder -- RE: Second WGLC on DOTS Requirements 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, 03 Apr 2018 00:21:08 -0000 I support this draft. It's ready. Nit: "DDoS attack telemetry" is defined in 1.2. Terminology, however it is used in nowhere. This document is OK even if there is no definition of "DDoS attack telemetry". regards, Kaname On 2018/03/29 20:44, Roman Danyliw wrote: > Hello! > > As a reminder, this WGLC closes on April 4, 2018. Please provide any comments by then. > > Thank, > Roman > >> -----Original Message----- >> From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Roman Danyliw >> Sent: Wednesday, March 21, 2018 6:16 AM >> To: dots@ietf.org >> Subject: [Dots] Second WGLC on DOTS Requirements >> >> Hello! >> >> Consistent with our discussion at the London meeting, we are starting a second >> working group last call (WGLC) for the DOTS Requirements draft: >> >> Distributed Denial of Service (DDoS) Open Threat Signaling Requirements >> draft-ietf-dots-requirements-14 >> https://tools.ietf.org/html/draft-ietf-dots-requirements-14 >> >> Please send comments to the DOTS mailing list. The WG welcomes feedback >> on needed changes as well as endorsements that this draft is ready. >> >> This second WGLC will end on April 4, 2018. >> >> Thanks, >> Roman >> >> _______________________________________________ >> Dots mailing list >> Dots@ietf.org >> https://www.ietf.org/mailman/listinfo/dots > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Tue Apr 3 17:27:18 2018 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 9DBB712704A for ; Tue, 3 Apr 2018 17:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bI-fDo0LY1cE for ; Tue, 3 Apr 2018 17:27:14 -0700 (PDT) Received: from guri.nttv6.jp (guri.nttv6.jp [115.69.228.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5EAA51205F0 for ; Tue, 3 Apr 2018 17:27:14 -0700 (PDT) Received: from z.nttv6.jp (z.nttv6.jp [192.168.8.15]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id 603EC25F68C for ; Wed, 4 Apr 2018 09:27:13 +0900 (JST) Received: from MacBook-Pro-17.lv4.nttv6.jp (fujiko.nttv6.jp [115.69.228.141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 596EF7634E6 for ; Wed, 4 Apr 2018 09:27:13 +0900 (JST) To: "dots@ietf.org" References: <359EC4B99E040048A7131E0F4E113AFC014C36B932@marathon> From: kaname nishizuka Message-ID: <68904f77-3cef-4c77-4cfa-3aeaacf95133@nttv6.jp> Date: Wed, 4 Apr 2018 09:27:13 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC014C36B932@marathon> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Dots] WGLC on DOTS Signal Channel 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: Wed, 04 Apr 2018 00:27:17 -0000 Hi, I have one clarification questions about sid in signal channel session configuration. The draft says:  At least one of the attributes ’heartbeat-interval’, ’missing-hb allowed’, ’max-retransmit’, ’ack-timeout’, ’ack-random-factor’, and  ’trigger-mitigation’ MUST be present in the PUT request.  (snip)  The PUT request with a higher numeric ’sid’ value overrides the DOTS  signal channel session configuration data installed by a PUT request  with a lower numeric ’sid’ value. assuming these are default values of a DOTS server:  'heartbeat-interval'=30  ’max-retransmit’=3 if these messages came to the DOTS server consecutively,  1. sid=123, "heartbeat-interval"=10  2. sid=456, ’max-retransmit’=5 in the final state, the first change should be discarded?:  'heartbeat-interval'=30  ’max-retransmit’=5 or accumulated?:  'heartbeat-interval'=10  ’max-retransmit’=5 so, the question is: should they be overridden by default values even if it is not specified? I think the former is ideal behavior. However, if so, the DOTS server is only required to keep the latest resource of the highest sid, then there should be no difference between DELETE message with and without sid. regards, Kaname On 2018/03/21 19:32, Roman Danyliw wrote: > Hello! > > Consistent with our discussion at the London meeting, we are starting a working group last call (WGLC) for the DOTS Signal Channel draft: > > DOTS Signal Channel Specification > draft-ietf-dots-signal-channel-18 > https://tools.ietf.org/html/draft-ietf-dots-signal-channel-18 > > Please send comments to the DOTS mailing list -- feedback on remaining issues or needed changes; as well as endorsements that this draft is ready. > > This WGLC will end on April 6, 2018. > > Thanks, > Roman > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Tue Apr 3 23:22:40 2018 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 2A454126CF6 for ; Tue, 3 Apr 2018 23:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJG9tsM35oxt for ; Tue, 3 Apr 2018 23:22:37 -0700 (PDT) Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05891124B17 for ; Tue, 3 Apr 2018 23:22:37 -0700 (PDT) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 505C640961; Wed, 4 Apr 2018 08:22:35 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.18]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 3165920066; Wed, 4 Apr 2018 08:22:35 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM34.corporate.adroot.infra.ftgroup ([fe80::cba:56d0:a732:ef5a%19]) with mapi id 14.03.0382.000; Wed, 4 Apr 2018 08:22:35 +0200 From: To: kaname nishizuka , "dots@ietf.org" Thread-Topic: [Dots] WGLC on DOTS Signal Channel Thread-Index: AQHTy6uz36xkC/jHUEieIPmZ5cnFoKPwIEWQ Date: Wed, 4 Apr 2018 06:22:34 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DEF7927@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <359EC4B99E040048A7131E0F4E113AFC014C36B932@marathon> <68904f77-3cef-4c77-4cfa-3aeaacf95133@nttv6.jp> In-Reply-To: <68904f77-3cef-4c77-4cfa-3aeaacf95133@nttv6.jp> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] WGLC on DOTS Signal Channel 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: Wed, 04 Apr 2018 06:22:39 -0000 SGkgS2FuYW1lLCANCg0KUGxlYXNlIHNlZSBpbmxpbmUuIA0KDQpDaGVlcnMsDQpNZWQNCg0KPiAt LS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDogRG90cyBbbWFpbHRvOmRvdHMtYm91 bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBrYW5hbWUgbmlzaGl6dWthDQo+IEVudm95w6nC oDogbWVyY3JlZGkgNCBhdnJpbCAyMDE4IDAyOjI3DQo+IMOAwqA6IGRvdHNAaWV0Zi5vcmcNCj4g T2JqZXTCoDogUmU6IFtEb3RzXSBXR0xDIG9uIERPVFMgU2lnbmFsIENoYW5uZWwNCj4gDQo+IEhp LA0KPiANCj4gSSBoYXZlIG9uZSBjbGFyaWZpY2F0aW9uIHF1ZXN0aW9ucyBhYm91dCBzaWQgaW4g c2lnbmFsIGNoYW5uZWwgc2Vzc2lvbg0KPiBjb25maWd1cmF0aW9uLg0KPiANCj4gVGhlIGRyYWZ0 IHNheXM6DQo+ICDCoEF0IGxlYXN0IG9uZSBvZiB0aGUgYXR0cmlidXRlcyDigJloZWFydGJlYXQt aW50ZXJ2YWzigJksIOKAmW1pc3NpbmctaGINCj4gYWxsb3dlZOKAmSwg4oCZbWF4LXJldHJhbnNt aXTigJksIOKAmWFjay10aW1lb3V04oCZLCDigJlhY2stcmFuZG9tLWZhY3RvcuKAmSwgYW5kDQo+ ICDCoOKAmXRyaWdnZXItbWl0aWdhdGlvbuKAmSBNVVNUIGJlIHByZXNlbnQgaW4gdGhlIFBVVCBy ZXF1ZXN0Lg0KPiAgwqAoc25pcCkNCj4gIMKgVGhlIFBVVCByZXF1ZXN0IHdpdGggYSBoaWdoZXIg bnVtZXJpYyDigJlzaWTigJkgdmFsdWUgb3ZlcnJpZGVzIHRoZSBET1RTDQo+ICDCoHNpZ25hbCBj aGFubmVsIHNlc3Npb24gY29uZmlndXJhdGlvbiBkYXRhIGluc3RhbGxlZCBieSBhIFBVVCByZXF1 ZXN0DQo+ICDCoHdpdGggYSBsb3dlciBudW1lcmljIOKAmXNpZOKAmSB2YWx1ZS4NCj4gDQo+IGFz c3VtaW5nIHRoZXNlIGFyZSBkZWZhdWx0IHZhbHVlcyBvZiBhIERPVFMgc2VydmVyOg0KPiAgwqAn aGVhcnRiZWF0LWludGVydmFsJz0zMA0KPiAgwqDigJltYXgtcmV0cmFuc21pdOKAmT0zDQo+IA0K PiBpZiB0aGVzZSBtZXNzYWdlcyBjYW1lIHRvIHRoZSBET1RTIHNlcnZlciBjb25zZWN1dGl2ZWx5 LA0KPiAgwqAxLiBzaWQ9MTIzLCAiaGVhcnRiZWF0LWludGVydmFsIj0xMA0KPiAgwqAyLiBzaWQ9 NDU2LCDigJltYXgtcmV0cmFuc21pdOKAmT01DQo+IGluIHRoZSBmaW5hbCBzdGF0ZSwgdGhlIGZp cnN0IGNoYW5nZSBzaG91bGQgYmUgZGlzY2FyZGVkPzoNCj4gIMKgJ2hlYXJ0YmVhdC1pbnRlcnZh bCc9MzANCj4gIMKg4oCZbWF4LXJldHJhbnNtaXTigJk9NQ0KPiBvciBhY2N1bXVsYXRlZD86DQo+ ICDCoCdoZWFydGJlYXQtaW50ZXJ2YWwnPTEwDQo+ICDCoOKAmW1heC1yZXRyYW5zbWl04oCZPTUN Cj4gDQo+IHNvLCB0aGUgcXVlc3Rpb24gaXM6IHNob3VsZCB0aGV5IGJlIG92ZXJyaWRkZW4gYnkg ZGVmYXVsdCB2YWx1ZXMgZXZlbiBpZiBpdA0KPiBpcyBub3Qgc3BlY2lmaWVkPw0KDQpbTWVkXSBU aGUgYmVoYXZpb3IgdG8gZm9sbG93IGlzIGNvdmVyZWQgYnkgdGhpcyB0ZXh0OiANCg0KICAgVGhl IFBVVCByZXF1ZXN0IHdpdGggYSBoaWdoZXIgbnVtZXJpYyAnc2lkJyB2YWx1ZSBvdmVycmlkZXMg dGhlIERPVFMNCiAgIHNpZ25hbCBjaGFubmVsIHNlc3Npb24gY29uZmlndXJhdGlvbiBkYXRhIGlu c3RhbGxlZCBieSBhIFBVVCByZXF1ZXN0DQogICB3aXRoIGEgbG93ZXIgbnVtZXJpYyAnc2lkJyB2 YWx1ZS4gIFRvIGF2b2lkIG1haW50YWluaW5nIGEgbG9uZyBsaXN0DQogICBvZiAnc2lkJyByZXF1 ZXN0cyBmcm9tIGEgRE9UUyBjbGllbnQsIHRoZSBsb3dlciBudW1lcmljICdzaWQnIE1VU1QgYmUN CiAgIGF1dG9tYXRpY2FsbHkgZGVsZXRlZCBhbmQgbm8gbG9uZ2VyIGF2YWlsYWJsZSBhdCB0aGUg RE9UUyBzZXJ2ZXIuDQoNCkFuZCANCg0KICAgVGhlIERPVFMgYWdlbnRzIE1VU1QgdXNlIHRoZSBu ZWdvdGlhdGVkDQogICB2YWx1ZXMgZm9yIG1lc3NhZ2UgdHJhbnNtaXNzaW9uIHBhcmFtZXRlcnMg YW5kIGRlZmF1bHQgdmFsdWVzIGZvcg0KICAgbm9uLW5lZ290aWF0ZWQgbWVzc2FnZSB0cmFuc21p c3Npb24gcGFyYW1ldGVycy4NCg0KPiBJIHRoaW5rIHRoZSBmb3JtZXIgaXMgaWRlYWwgYmVoYXZp b3IuDQo+IEhvd2V2ZXIsIGlmIHNvLCB0aGUgRE9UUyBzZXJ2ZXIgaXMgb25seSByZXF1aXJlZCB0 byBrZWVwIHRoZSBsYXRlc3QgcmVzb3VyY2UNCj4gb2YgdGhlIGhpZ2hlc3Qgc2lkLA0KPiB0aGVu IHRoZXJlIHNob3VsZCBiZSBubyBkaWZmZXJlbmNlIGJldHdlZW4gREVMRVRFIG1lc3NhZ2Ugd2l0 aCBhbmQgd2l0aG91dA0KPiBzaWQuDQo+IA0KDQpbTWVkXSBUbyBkZWxldGUgYSBjb25maWd1cmF0 aW9uLCBhIGNsaWVudCBtYXkgc2VuZCBhIERFTEVURSB3aXRoIGEgdmFsaWQgJ3NpZCcgb3IgYSBE RUxFVEUgd2l0aG91dCBzdXBwbHlpbmcgYSAnc2lkJy4gDQpCb3RoIGFyZSBjb25zaWRlcmVkIGFz IHZhbGlkIGluIFNlY3Rpb24gNC41LjQuDQoNCj4gcmVnYXJkcywNCj4gS2FuYW1lDQo+IA0KPiAN Cj4gT24gMjAxOC8wMy8yMSAxOTozMiwgUm9tYW4gRGFueWxpdyB3cm90ZToNCj4gPiBIZWxsbyEN Cj4gPg0KPiA+IENvbnNpc3RlbnQgd2l0aCBvdXIgZGlzY3Vzc2lvbiBhdCB0aGUgTG9uZG9uIG1l ZXRpbmcsIHdlIGFyZSBzdGFydGluZyBhDQo+IHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIChXR0xD KSBmb3IgdGhlIERPVFMgU2lnbmFsIENoYW5uZWwgZHJhZnQ6DQo+ID4NCj4gPiBET1RTIFNpZ25h bCBDaGFubmVsIFNwZWNpZmljYXRpb24NCj4gPiBkcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNoYW5u ZWwtMTgNCj4gPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1kb3RzLXNp Z25hbC1jaGFubmVsLTE4DQo+ID4NCj4gPiBQbGVhc2Ugc2VuZCBjb21tZW50cyB0byB0aGUgRE9U UyBtYWlsaW5nIGxpc3QgLS0gZmVlZGJhY2sgb24gcmVtYWluaW5nDQo+IGlzc3VlcyBvciBuZWVk ZWQgY2hhbmdlczsgYXMgd2VsbCBhcyBlbmRvcnNlbWVudHMgdGhhdCB0aGlzIGRyYWZ0IGlzIHJl YWR5Lg0KPiA+DQo+ID4gVGhpcyBXR0xDIHdpbGwgZW5kIG9uIEFwcmlsIDYsIDIwMTguDQo+ID4N Cj4gPiBUaGFua3MsDQo+ID4gUm9tYW4NCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gRG90cyBtYWlsaW5nIGxpc3QNCj4gPiBEb3Rz QGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3Rz DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiBEb3RzIG1haWxpbmcgbGlzdA0KPiBEb3RzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vZG90cw0K From nobody Tue Apr 3 23:56:43 2018 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 E34F9124B17 for ; Tue, 3 Apr 2018 23:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1HvLoHyVNooE for ; Tue, 3 Apr 2018 23:56:39 -0700 (PDT) Received: from guri.nttv6.jp (guri.nttv6.jp [IPv6:2402:c800:ff06:136::140]) by ietfa.amsl.com (Postfix) with ESMTP id 09CE212708C for ; Tue, 3 Apr 2018 23:56:38 -0700 (PDT) Received: from z.nttv6.jp (z.nttv6.jp [192.168.8.15]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id 9E77625F6D2; Wed, 4 Apr 2018 15:56:37 +0900 (JST) Received: from MacBook-Pro-17.lv4.nttv6.jp (fujiko.nttv6.jp [115.69.228.141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 966997634FC; Wed, 4 Apr 2018 15:56:37 +0900 (JST) To: mohamed.boucadair@orange.com, "dots@ietf.org" References: <359EC4B99E040048A7131E0F4E113AFC014C36B932@marathon> <68904f77-3cef-4c77-4cfa-3aeaacf95133@nttv6.jp> <787AE7BB302AE849A7480A190F8B93302DEF7927@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: kaname nishizuka Message-ID: <7277ba5c-436b-9027-8be0-49c8a53dbde2@nttv6.jp> Date: Wed, 4 Apr 2018 15:56:37 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DEF7927@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Dots] WGLC on DOTS Signal Channel 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: Wed, 04 Apr 2018 06:56:42 -0000 Hi Med, On 2018/04/04 15:22, mohamed.boucadair@orange.com wrote: > Hi Kaname, > > Please see inline. > > Cheers, > Med > >> -----Message d'origine----- >> De : Dots [mailto:dots-bounces@ietf.org] De la part de kaname nishizuka >> Envoyé : mercredi 4 avril 2018 02:27 >> À : dots@ietf.org >> Objet : Re: [Dots] WGLC on DOTS Signal Channel >> >> Hi, >> >> I have one clarification questions about sid in signal channel session >> configuration. >> >> The draft says: >>  At least one of the attributes ’heartbeat-interval’, ’missing-hb >> allowed’, ’max-retransmit’, ’ack-timeout’, ’ack-random-factor’, and >>  ’trigger-mitigation’ MUST be present in the PUT request. >>  (snip) >>  The PUT request with a higher numeric ’sid’ value overrides the DOTS >>  signal channel session configuration data installed by a PUT request >>  with a lower numeric ’sid’ value. >> >> assuming these are default values of a DOTS server: >>  'heartbeat-interval'=30 >>  ’max-retransmit’=3 >> >> if these messages came to the DOTS server consecutively, >>  1. sid=123, "heartbeat-interval"=10 >>  2. sid=456, ’max-retransmit’=5 >> in the final state, the first change should be discarded?: >>  'heartbeat-interval'=30 >>  ’max-retransmit’=5 >> or accumulated?: >>  'heartbeat-interval'=10 >>  ’max-retransmit’=5 >> >> so, the question is: should they be overridden by default values even if it >> is not specified? > [Med] The behavior to follow is covered by this text: > > The PUT request with a higher numeric 'sid' value overrides the DOTS > signal channel session configuration data installed by a PUT request > with a lower numeric 'sid' value. To avoid maintaining a long list > of 'sid' requests from a DOTS client, the lower numeric 'sid' MUST be > automatically deleted and no longer available at the DOTS server. > > And > > The DOTS agents MUST use the negotiated > values for message transmission parameters and default values for > non-negotiated message transmission parameters. Thanks, so, in my example, final state is   'heartbeat-interval'=30 (reverted to default value)   ’max-retransmit’=5 and the lower numeric 'sid' no longer exist in the DOTS server, right? >> I think the former is ideal behavior. >> However, if so, the DOTS server is only required to keep the latest resource >> of the highest sid, >> then there should be no difference between DELETE message with and without >> sid. >> > [Med] To delete a configuration, a client may send a DELETE with a valid 'sid' or a DELETE without supplying a 'sid'. > Both are considered as valid in Section 4.5.4. > both are OK and have the same effect on DOTS server, right? A DOTS server always keeps the latest sid only. A DOTS client always attempt to update it. So there is no reason to use PUT, GET, DELETE with sid. Why sid does exist is confusing me. I'm afraid it was discussed on the ML but I'd like to know the rational of existence of sid. ```  sid: Session Identifier is an identifier for the DOTS signal channel  session configuration data represented as an integer. This  identifier MUST be generated by DOTS clients. ’sid’ values MUST  increase monotonically. ``` this is not convincing because always only one configuration is registered on DOTS server. it will completely work without sid. thanks, Kaname >> regards, >> Kaname >> >> >> On 2018/03/21 19:32, Roman Danyliw wrote: >>> Hello! >>> >>> Consistent with our discussion at the London meeting, we are starting a >> working group last call (WGLC) for the DOTS Signal Channel draft: >>> DOTS Signal Channel Specification >>> draft-ietf-dots-signal-channel-18 >>> https://tools.ietf.org/html/draft-ietf-dots-signal-channel-18 >>> >>> Please send comments to the DOTS mailing list -- feedback on remaining >> issues or needed changes; as well as endorsements that this draft is ready. >>> This WGLC will end on April 6, 2018. >>> >>> Thanks, >>> Roman >>> >>> _______________________________________________ >>> Dots mailing list >>> Dots@ietf.org >>> https://www.ietf.org/mailman/listinfo/dots >> _______________________________________________ >> Dots mailing list >> Dots@ietf.org >> https://www.ietf.org/mailman/listinfo/dots > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Wed Apr 4 00:32:03 2018 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 C0E8812708C for ; Wed, 4 Apr 2018 00:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Terp70ymcCBB for ; Wed, 4 Apr 2018 00:31:59 -0700 (PDT) Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4306B1200F1 for ; Wed, 4 Apr 2018 00:31:59 -0700 (PDT) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 05FF5C0A72; Wed, 4 Apr 2018 09:31:58 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.31]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id DABCE1A00A1; Wed, 4 Apr 2018 09:31:57 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1%19]) with mapi id 14.03.0382.000; Wed, 4 Apr 2018 09:31:57 +0200 From: To: kaname nishizuka , "dots@ietf.org" Thread-Topic: [Dots] WGLC on DOTS Signal Channel Thread-Index: AQHTy+IWnLVMpcgybkKvpSRH4nUkmaPwM0mw Date: Wed, 4 Apr 2018 07:31:56 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DEF79C9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <359EC4B99E040048A7131E0F4E113AFC014C36B932@marathon> <68904f77-3cef-4c77-4cfa-3aeaacf95133@nttv6.jp> <787AE7BB302AE849A7480A190F8B93302DEF7927@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7277ba5c-436b-9027-8be0-49c8a53dbde2@nttv6.jp> In-Reply-To: <7277ba5c-436b-9027-8be0-49c8a53dbde2@nttv6.jp> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] WGLC on DOTS Signal Channel 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: Wed, 04 Apr 2018 07:32:02 -0000 UmUtLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4gDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVz c2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBrYW5hbWUgbmlzaGl6dWthIFttYWlsdG86a2Fu YW1lQG50dHY2LmpwXQ0KPiBFbnZvecOpwqA6IG1lcmNyZWRpIDQgYXZyaWwgMjAxOCAwODo1Nw0K PiDDgMKgOiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xOOyBkb3RzQGlldGYub3JnDQo+IE9iamV0 wqA6IFJlOiBbRG90c10gV0dMQyBvbiBET1RTIFNpZ25hbCBDaGFubmVsDQo+IA0KPiBIaSBNZWQs DQo+IA0KPiANCj4gT24gMjAxOC8wNC8wNCAxNToyMiwgbW9oYW1lZC5ib3VjYWRhaXJAb3Jhbmdl LmNvbSB3cm90ZToNCj4gPiBIaSBLYW5hbWUsDQo+ID4NCj4gPiBQbGVhc2Ugc2VlIGlubGluZS4N Cj4gPg0KPiA+IENoZWVycywNCj4gPiBNZWQNCj4gPg0KPiA+PiAtLS0tLU1lc3NhZ2UgZCdvcmln aW5lLS0tLS0NCj4gPj4gRGXCoDogRG90cyBbbWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZ10g RGUgbGEgcGFydCBkZSBrYW5hbWUgbmlzaGl6dWthDQo+ID4+IEVudm95w6nCoDogbWVyY3JlZGkg NCBhdnJpbCAyMDE4IDAyOjI3DQo+ID4+IMOAwqA6IGRvdHNAaWV0Zi5vcmcNCj4gPj4gT2JqZXTC oDogUmU6IFtEb3RzXSBXR0xDIG9uIERPVFMgU2lnbmFsIENoYW5uZWwNCj4gPj4NCj4gPj4gSGks DQo+ID4+DQo+ID4+IEkgaGF2ZSBvbmUgY2xhcmlmaWNhdGlvbiBxdWVzdGlvbnMgYWJvdXQgc2lk IGluIHNpZ25hbCBjaGFubmVsIHNlc3Npb24NCj4gPj4gY29uZmlndXJhdGlvbi4NCj4gPj4NCj4g Pj4gVGhlIGRyYWZ0IHNheXM6DQo+ID4+ICAgwqBBdCBsZWFzdCBvbmUgb2YgdGhlIGF0dHJpYnV0 ZXMg4oCZaGVhcnRiZWF0LWludGVydmFs4oCZLCDigJltaXNzaW5nLWhiDQo+ID4+IGFsbG93ZWTi gJksIOKAmW1heC1yZXRyYW5zbWl04oCZLCDigJlhY2stdGltZW91dOKAmSwg4oCZYWNrLXJhbmRv bS1mYWN0b3LigJksIGFuZA0KPiA+PiAgIMKg4oCZdHJpZ2dlci1taXRpZ2F0aW9u4oCZIE1VU1Qg YmUgcHJlc2VudCBpbiB0aGUgUFVUIHJlcXVlc3QuDQo+ID4+ICAgwqAoc25pcCkNCj4gPj4gICDC oFRoZSBQVVQgcmVxdWVzdCB3aXRoIGEgaGlnaGVyIG51bWVyaWMg4oCZc2lk4oCZIHZhbHVlIG92 ZXJyaWRlcyB0aGUgRE9UUw0KPiA+PiAgIMKgc2lnbmFsIGNoYW5uZWwgc2Vzc2lvbiBjb25maWd1 cmF0aW9uIGRhdGEgaW5zdGFsbGVkIGJ5IGEgUFVUIHJlcXVlc3QNCj4gPj4gICDCoHdpdGggYSBs b3dlciBudW1lcmljIOKAmXNpZOKAmSB2YWx1ZS4NCj4gPj4NCj4gPj4gYXNzdW1pbmcgdGhlc2Ug YXJlIGRlZmF1bHQgdmFsdWVzIG9mIGEgRE9UUyBzZXJ2ZXI6DQo+ID4+ICAgwqAnaGVhcnRiZWF0 LWludGVydmFsJz0zMA0KPiA+PiAgIMKg4oCZbWF4LXJldHJhbnNtaXTigJk9Mw0KPiA+Pg0KPiA+ PiBpZiB0aGVzZSBtZXNzYWdlcyBjYW1lIHRvIHRoZSBET1RTIHNlcnZlciBjb25zZWN1dGl2ZWx5 LA0KPiA+PiAgIMKgMS4gc2lkPTEyMywgImhlYXJ0YmVhdC1pbnRlcnZhbCI9MTANCj4gPj4gICDC oDIuIHNpZD00NTYsIOKAmW1heC1yZXRyYW5zbWl04oCZPTUNCj4gPj4gaW4gdGhlIGZpbmFsIHN0 YXRlLCB0aGUgZmlyc3QgY2hhbmdlIHNob3VsZCBiZSBkaXNjYXJkZWQ/Og0KPiA+PiAgIMKgJ2hl YXJ0YmVhdC1pbnRlcnZhbCc9MzANCj4gPj4gICDCoOKAmW1heC1yZXRyYW5zbWl04oCZPTUNCj4g Pj4gb3IgYWNjdW11bGF0ZWQ/Og0KPiA+PiAgIMKgJ2hlYXJ0YmVhdC1pbnRlcnZhbCc9MTANCj4g Pj4gICDCoOKAmW1heC1yZXRyYW5zbWl04oCZPTUNCj4gPj4NCj4gPj4gc28sIHRoZSBxdWVzdGlv biBpczogc2hvdWxkIHRoZXkgYmUgb3ZlcnJpZGRlbiBieSBkZWZhdWx0IHZhbHVlcyBldmVuIGlm DQo+IGl0DQo+ID4+IGlzIG5vdCBzcGVjaWZpZWQ/DQo+ID4gW01lZF0gVGhlIGJlaGF2aW9yIHRv IGZvbGxvdyBpcyBjb3ZlcmVkIGJ5IHRoaXMgdGV4dDoNCj4gPg0KPiA+ICAgICBUaGUgUFVUIHJl cXVlc3Qgd2l0aCBhIGhpZ2hlciBudW1lcmljICdzaWQnIHZhbHVlIG92ZXJyaWRlcyB0aGUgRE9U Uw0KPiA+ICAgICBzaWduYWwgY2hhbm5lbCBzZXNzaW9uIGNvbmZpZ3VyYXRpb24gZGF0YSBpbnN0 YWxsZWQgYnkgYSBQVVQgcmVxdWVzdA0KPiA+ICAgICB3aXRoIGEgbG93ZXIgbnVtZXJpYyAnc2lk JyB2YWx1ZS4gIFRvIGF2b2lkIG1haW50YWluaW5nIGEgbG9uZyBsaXN0DQo+ID4gICAgIG9mICdz aWQnIHJlcXVlc3RzIGZyb20gYSBET1RTIGNsaWVudCwgdGhlIGxvd2VyIG51bWVyaWMgJ3NpZCcg TVVTVCBiZQ0KPiA+ICAgICBhdXRvbWF0aWNhbGx5IGRlbGV0ZWQgYW5kIG5vIGxvbmdlciBhdmFp bGFibGUgYXQgdGhlIERPVFMgc2VydmVyLg0KPiA+DQo+ID4gQW5kDQo+ID4NCj4gPiAgICAgVGhl IERPVFMgYWdlbnRzIE1VU1QgdXNlIHRoZSBuZWdvdGlhdGVkDQo+ID4gICAgIHZhbHVlcyBmb3Ig bWVzc2FnZSB0cmFuc21pc3Npb24gcGFyYW1ldGVycyBhbmQgZGVmYXVsdCB2YWx1ZXMgZm9yDQo+ ID4gICAgIG5vbi1uZWdvdGlhdGVkIG1lc3NhZ2UgdHJhbnNtaXNzaW9uIHBhcmFtZXRlcnMuDQo+ IA0KPiBUaGFua3MsIHNvLCBpbiBteSBleGFtcGxlLCBmaW5hbCBzdGF0ZSBpcw0KPiAgwqAgJ2hl YXJ0YmVhdC1pbnRlcnZhbCc9MzAgKHJldmVydGVkIHRvIGRlZmF1bHQgdmFsdWUpDQo+ICDCoCDi gJltYXgtcmV0cmFuc21pdOKAmT01DQo+IGFuZCB0aGUgbG93ZXIgbnVtZXJpYyAnc2lkJyBubyBs b25nZXIgZXhpc3QgaW4gdGhlIERPVFMgc2VydmVyLCByaWdodD8NCj4gDQoNCltNZWRdIEV4YWN0 bHkuIA0KDQo+ID4+IEkgdGhpbmsgdGhlIGZvcm1lciBpcyBpZGVhbCBiZWhhdmlvci4NCj4gPj4g SG93ZXZlciwgaWYgc28sIHRoZSBET1RTIHNlcnZlciBpcyBvbmx5IHJlcXVpcmVkIHRvIGtlZXAg dGhlIGxhdGVzdA0KPiByZXNvdXJjZQ0KPiA+PiBvZiB0aGUgaGlnaGVzdCBzaWQsDQo+ID4+IHRo ZW4gdGhlcmUgc2hvdWxkIGJlIG5vIGRpZmZlcmVuY2UgYmV0d2VlbiBERUxFVEUgbWVzc2FnZSB3 aXRoIGFuZCB3aXRob3V0DQo+ID4+IHNpZC4NCj4gPj4NCj4gPiBbTWVkXSBUbyBkZWxldGUgYSBj b25maWd1cmF0aW9uLCBhIGNsaWVudCBtYXkgc2VuZCBhIERFTEVURSB3aXRoIGEgdmFsaWQNCj4g J3NpZCcgb3IgYSBERUxFVEUgd2l0aG91dCBzdXBwbHlpbmcgYSAnc2lkJy4NCj4gPiBCb3RoIGFy ZSBjb25zaWRlcmVkIGFzIHZhbGlkIGluIFNlY3Rpb24gNC41LjQuDQo+ID4NCj4gYm90aCBhcmUg T0sgYW5kIGhhdmUgdGhlIHNhbWUgZWZmZWN0IG9uIERPVFMgc2VydmVyLCByaWdodD8NCg0KW01l ZF0gWWVzLiANCg0KPiANCj4gQSBET1RTIHNlcnZlciBhbHdheXMga2VlcHMgdGhlIGxhdGVzdCBz aWQgb25seS4NCg0KW01lZF0gTm90IHRoZSAibGF0ZXN0IiByZWNlaXZlZCBzaWQuLi5idXQgdGhl IHJlcXVlc3Qgd2l0aCB0aGUgaGlnaGVyIHNpZC4gDQoNCiBBIERPVFMgY2xpZW50IGFsd2F5cyBh dHRlbXB0DQo+IHRvIHVwZGF0ZSBpdC4NCj4gU28gdGhlcmUgaXMgbm8gcmVhc29uIHRvIHVzZSBQ VVQsIEdFVCwgREVMRVRFIHdpdGggc2lkLg0KPiBXaHkgc2lkIGRvZXMgZXhpc3QgaXMgY29uZnVz aW5nIG1lLg0KDQpbTWVkXSAnc2lkJyBpcyB0aGVyZSB0byBzb2x2ZSBvdXQgb2Ygb3JkZXIgY29u ZmlndXJhdGlvbiByZXF1ZXN0cy4gVGhlIHJhdGlvbmFsZSBpcyBleHBsYWluZWQgaW4gc2xpZGUg MTIgb2YgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nL2ludGVyaW0tMjAxOC1k b3RzLTAxL21hdGVyaWFscy9zbGlkZXMtaW50ZXJpbS0yMDE4LWRvdHMtMDEtc2Vzc2Etc2lnbmFs LWNoYW5uZWwtMDAucGRmICANCg0KPiANCj4gSSdtIGFmcmFpZCBpdCB3YXMgZGlzY3Vzc2VkIG9u IHRoZSBNTCBidXQgSSdkIGxpa2UgdG8ga25vdyB0aGUgcmF0aW9uYWwgb2YNCj4gZXhpc3RlbmNl IG9mIHNpZC4NCj4gYGBgDQo+ICDCoHNpZDogU2Vzc2lvbiBJZGVudGlmaWVyIGlzIGFuIGlkZW50 aWZpZXIgZm9yIHRoZSBET1RTIHNpZ25hbCBjaGFubmVsDQo+ICDCoHNlc3Npb24gY29uZmlndXJh dGlvbiBkYXRhIHJlcHJlc2VudGVkIGFzIGFuIGludGVnZXIuIFRoaXMNCj4gIMKgaWRlbnRpZmll ciBNVVNUIGJlIGdlbmVyYXRlZCBieSBET1RTIGNsaWVudHMuIOKAmXNpZOKAmSB2YWx1ZXMgTVVT VA0KPiAgwqBpbmNyZWFzZSBtb25vdG9uaWNhbGx5Lg0KPiBgYGANCj4gdGhpcyBpcyBub3QgY29u dmluY2luZyBiZWNhdXNlIGFsd2F5cyBvbmx5IG9uZSBjb25maWd1cmF0aW9uIGlzIHJlZ2lzdGVy ZWQgb24NCj4gRE9UUyBzZXJ2ZXIuDQo+IGl0IHdpbGwgY29tcGxldGVseSB3b3JrIHdpdGhvdXQg c2lkLg0KPiANCj4gdGhhbmtzLA0KPiBLYW5hbWUNCj4gDQo+IA0KPiA+PiByZWdhcmRzLA0KPiA+ PiBLYW5hbWUNCj4gPj4NCj4gPj4NCj4gPj4gT24gMjAxOC8wMy8yMSAxOTozMiwgUm9tYW4gRGFu eWxpdyB3cm90ZToNCj4gPj4+IEhlbGxvIQ0KPiA+Pj4NCj4gPj4+IENvbnNpc3RlbnQgd2l0aCBv dXIgZGlzY3Vzc2lvbiBhdCB0aGUgTG9uZG9uIG1lZXRpbmcsIHdlIGFyZSBzdGFydGluZyBhDQo+ ID4+IHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIChXR0xDKSBmb3IgdGhlIERPVFMgU2lnbmFsIENo YW5uZWwgZHJhZnQ6DQo+ID4+PiBET1RTIFNpZ25hbCBDaGFubmVsIFNwZWNpZmljYXRpb24NCj4g Pj4+IGRyYWZ0LWlldGYtZG90cy1zaWduYWwtY2hhbm5lbC0xOA0KPiA+Pj4gaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZG90cy1zaWduYWwtY2hhbm5lbC0xOA0KPiA+Pj4N Cj4gPj4+IFBsZWFzZSBzZW5kIGNvbW1lbnRzIHRvIHRoZSBET1RTIG1haWxpbmcgbGlzdCAtLSBm ZWVkYmFjayBvbiByZW1haW5pbmcNCj4gPj4gaXNzdWVzIG9yIG5lZWRlZCBjaGFuZ2VzOyBhcyB3 ZWxsIGFzIGVuZG9yc2VtZW50cyB0aGF0IHRoaXMgZHJhZnQgaXMNCj4gcmVhZHkuDQo+ID4+PiBU aGlzIFdHTEMgd2lsbCBlbmQgb24gQXByaWwgNiwgMjAxOC4NCj4gPj4+DQo+ID4+PiBUaGFua3Ms DQo+ID4+PiBSb21hbg0KPiA+Pj4NCj4gPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+ID4+PiBEb3RzIG1haWxpbmcgbGlzdA0KPiA+Pj4gRG90c0Bp ZXRmLm9yZw0KPiA+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3Rz DQo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4+IERvdHMgbWFpbGluZyBsaXN0DQo+ID4+IERvdHNAaWV0Zi5vcmcNCj4gPj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3RzDQo+ID4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBEb3RzIG1haWxpbmcgbGlzdA0KPiA+ IERvdHNAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2RvdHMNCg0K From nobody Wed Apr 4 00:46:39 2018 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 CA5A81270A0 for ; Wed, 4 Apr 2018 00:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 LbzhA_CMOxKP for ; Wed, 4 Apr 2018 00:46:35 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.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 0B59112708C for ; Wed, 4 Apr 2018 00:46:35 -0700 (PDT) Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id E888F2E2CE52A; Wed, 4 Apr 2018 08:46:30 +0100 (IST) Received: from DGGEML422-HUB.china.huawei.com (10.1.199.39) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.382.0; Wed, 4 Apr 2018 08:46:32 +0100 Received: from DGGEML502-MBS.china.huawei.com ([169.254.3.252]) by dggeml422-hub.china.huawei.com ([10.1.199.39]) with mapi id 14.03.0361.001; Wed, 4 Apr 2018 15:46:25 +0800 From: "Xialiang (Frank, Network Integration Technology Research Dept)" To: Daniel Migault CC: "dots@ietf.org" Thread-Topic: =?gb2312?B?Y29tbWVudHMgZm9yIHRoaXMgZG9jdW1lbnQ6Ly+08Li0OiBOZXcgVmVyc2lv?= =?gb2312?B?biBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtZG90cy11c2UtY2FzZXMt?= =?gb2312?Q?11.txt?= Thread-Index: AQHTxp2faLCf/ZbrX0yXqD9vq+HlB6PlLZIAgAsMq/A= Date: Wed, 4 Apr 2018 07:46:25 +0000 Message-ID: References: <152224582267.29792.2214827071198414612.idtracker@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C118E01184@eusaamb107.ericsson.se> In-Reply-To: <2DD56D786E600F45AC6BDE7DA4E8A8C118E01184@eusaamb107.ericsson.se> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.159.76] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Dots] =?gb2312?b?Y29tbWVudHMgZm9yIHRoaXMgZG9jdW1lbnQ6Ly+08Li0?= =?gb2312?b?OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtZG90?= =?gb2312?b?cy11c2UtY2FzZXMtMTEudHh0?= 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: Wed, 04 Apr 2018 07:46:38 -0000 SGkgRGFuaWVsLA0KVGhhbmtzIGZvciBwdXNoaW5nIGZvcndhcmQgdGhpcyBkb2N1bWVudC4gSW4g Z2VuZXJhbCwgdGhpcyBkb2N1bWVudCBpcyBpbiBhIHZlcnkgZ29vZCBzaGFwZSBub3csIHdoaWNo IEkgaGFyZGx5IGZpbmQgYW55IHRlY2huaWNhbCBpc3N1ZXMsIGluIGFkZGl0aW9uIHRvIHNvbWUg bml0cyBhcyBiZWxvdzoNCg0KU2VjdGlvbiAxOg0KLyBhcyB3ZWxsIGFzIHRvIGlsbHVzdHJhdGUg dGhlIHB1cnBvc2Ugb2YgZ29hbHMgLyBhcyB3ZWxsIGFzIHRvIGlsbHVzdHJhdGUgdGhlIGdvYWxz IC8NCg0KU2VjdGlvbiAyLjI6DQovIEREb1MgTWl0aWdhdGlvbiBTZXJ2aWNlOiBkZXNpZ25hdGVz IGEgc2VydmljZSBwcm92aWRlcyB0byBhIGN1c3RvbWVyLiAgU2VydmljZXMgdXN1YWxseSBpbnZv bHZlcyBTZXJ2aWNlIExldmVsIEFncmVlbWVudCAoU0xBKSB0aGF0IGhhdmUgdG8gYmUgbWV0LiAv IEREb1MgTWl0aWdhdGlvbiBTZXJ2aWNlOiBkZXNpZ25hdGVzIGEgc2VydmljZSBwcm92aWRlZCB0 byBhIGN1c3RvbWVyLiAgU2VydmljZXMgdXN1YWxseSBpbnZvbHZlIFNlcnZpY2UgTGV2ZWwgQWdy ZWVtZW50IChTTEEpIHRoYXQgaGFzIHRvIGJlIG1ldC4gLw0KDQpTZWN0aW9uIDMuMToNCi8gd2hp Y2ggdGhyZWF0ZW4gdG8gb3ZlcndoZWxtIHRoZWlyIHRyYW5zaXQgbGluayBiYW5kd2lkdGggLyB0 byBtaXRpZ2F0ZSB0aGUgYXR0YWNrIHdoaWNoIHRocmVhdGVuIHRvIG92ZXJ3aGVsbSB0aGVpciB0 cmFuc2l0IGxpbmsgYmFuZHdpZHRoIC8NCg0KLyBOb3RlIGFsc28gdGhhdCB0aGUgRE9UUyBDbGll bnRzIHRoYXQgc2VuZHMgLyBOb3RlIGFsc28gdGhhdCB0aGUgRE9UUyBDbGllbnRzIHRoYXQgc2Vu ZCAvDQoNCg0KU2VjdGlvbiAzLjI6DQovIGluIGZpZ3VyZSAyLCB0aGUgdHJhZmZpYyBkb2VzIG5v dCBub3QgLyBpbiBGaWd1cmUgMiwgdGhlIHRyYWZmaWMgZG9lcyBub3QgLw0KDQovIGluIG9yZGVy IHRvIGVuc3VyZSB0aGF0IHN1ZmZpY2llbnQgRERvUyBtaXRpZ2F0aW9uIGNhcGFjaXR5IGFuZC9v ciBjYXBhYmlsaXRpZXMgLyBpbiBvcmRlciB0byBlbnN1cmUgdGhhdCBzdWZmaWNpZW50IEREb1Mg bWl0aWdhdGlvbiBjYXBhYmlsaXRpZXMNCg0KT25lIG1vcmUgY29tbWVudCBmb3IgRmlndXJlIDM6 DQpTaG91bGQgaXQgYWRkIG9uZSBtb3JlIGxpbmsgdG8gcmVwcmVzZW50IHRoZSByZS1pbmplY3Rp bmcgdHJhZmZpYyBmcm9tIEREb1MgbWl0aWdhdGlvbiBzZXJ2aWNlIHByb3ZpZGVyIHRvIGVudGVy cHJpc2UgbmV0d29yaz8NCg0KDQpUaGFua3MhDQoNCkIuUi4NCkZyYW5rDQoNCg0KDQoNCg0KLS0t LS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IERvdHMgW21haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5v cmddILT6se0gRGFuaWVsIE1pZ2F1bHQNCreiy83KsbzkOiAyMDE4xOoz1MIyOMjVIDIyOjI0DQrK 1bz+yMs6IGRvdHNAaWV0Zi5vcmcNCtb3zOI6IFtEb3RzXSBGVzogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciBkcmFmdC1pZXRmLWRvdHMtdXNlLWNhc2VzLTExLnR4dA0KDQpIaSBldmVyeW9u ZSENCg0KUGxlYXNlIGZpbmQgdGhlIGRyYWZ0LWlldGYtZG90cy11c2UtY2FzZXMtMTEgWzFdLiBJ biBvcmRlciB0byBtZWV0IHRoZSBhZ2dyZXNzaXZlIHNjaGVkdWxlIGFncmVlZCBkdXJpbmcgdGhl IHNlc3Npb24gaW4gTG9uZG9uLCB3ZSB3b3VsZCBncmVhdGx5IGFwcHJlY2lhdGUgeW91ciBmZWVk IGJhY2tzIGJ5IHRoZSBlbmQgb2YgdGhlIHdlZWsgISANCg0KVGhlIGN1cnJlbnQgZG9jdW1lbnQg aXMgbGltaXRlZCB0byAzIHVzZSBjYXNlcyBkZXNjcmliZWQgb3ZlciAxMGlzaCBwYWdlcy4gV2Ug YmVsaWV2ZSB0aGUgY3VycmVudCBkb2N1bWVudCBhZGRyZXNzZXMgdGhlIGZlZWQgYmFja3MgYW5k IGNvbW1lbnRzIHdlIHJlY2VpdmVkIGZyb20gdGhlIExvbmRvbiBzZXNzaW9uLiBJZiB5b3UgYmVs aWV2ZSBvdGhlcndpc2UsIGZlZWwgZnJlZSB0byBicmluZyB0aGlzIG9uIHRoZSBtYWlsaW5nIGxp c3QuDQoNCldlIGV4cGVjdCB0byBwdWJsaXNoIHZlcnNpb24gMTIgb24gVHVlc2RheSBBcHJpbCAz LiBUaGlzIHZlcnNpb24gaXMgZXhwZWN0ZWQgdG8gYWRkcmVzcyB0aGUgcmVjZWl2ZWQgY29tbWVu dHMgYW5kIGJlIHJlYWR5IHRvIFdHTEMuIA0KDQpDb21tZW50cyBjYW4gYmUgYWRkcmVzc2VkIGRp cmVjdGx5IHRvIHRoZSBtYWlsaW5nIGxpc3Qgb3IgdXNpbmcgZ2l0aHViIHB1bGwgcmVxdWVzdHMg b24gdGhlIG1rZCB2ZXJzaW9uIFsyXS4gSWYgeW91IGJlbGlldmUgc29tZSBkaXNjdXNzaW9ucyBh cmUgbmVlZGVkLCBwbGVhc2UgY29uc2lkZXIgZGlzY3Vzc2luZyB0aG9zZSBvbiB0aGUgbWFpbGlu ZyBsaXN0LiANCg0KWW91cnMsIA0KRGFuaWVsDQpbMV0gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtaWV0Zi1kb3RzLXVzZS1jYXNlcy8NClsyXSAgaHR0cHM6Ly9naXRodWIu Y29tL2RvdHN3Zy9kb3RzLXVzZS1jYXNlcy9ibG9iL21hc3Rlci9kcmFmdC1pZXRmLWRvdHMtdXNl LWNhc2VzLm1rZA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6 IFdlZG5lc2RheSwgTWFyY2ggMjgsIDIwMTggMTA6MDQgQU0NClRvOiBLYW5hbWUgTmlzaGl6dWth IDxrYW5hbWVAbnR0djYuanA+OyBOaWsgVGVhZ3VlIDxudGVhZ3VlQHZlcmlzaWduLmNvbT47IERh bmllbCBNaWdhdWx0IDxkYW5pZWwubWlnYXVsdEBlcmljc3Nvbi5jb20+OyBSb2JlcnQgTW9za293 aXR6IDxyZ21AbGFicy5odHQtY29uc3VsdC5jb20+OyBTdGVmYW4gRm91YW50IDxzdGVmYW4uZm91 YW50QGNvcHBlcnJpdmVyaXQuY29tPjsgZG90cy1jaGFpcnNAaWV0Zi5vcmc7IFJvbGFuZCBEb2Ji aW5zIDxyZG9iYmluc0BhcmJvci5uZXQ+OyBMaWFuZyBYaWEgPGZyYW5rLnhpYWxpYW5nQGh1YXdl aS5jb20+OyBMaWFuZyBYaWEgPEZyYW5rLnhpYWxpYW5nQGh1YXdlaS5jb20+DQpTdWJqZWN0OiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtZG90cy11c2UtY2FzZXMtMTEu dHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWlldGYtZG90cy11c2UtY2FzZXMt MTEudHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgRGFuaWVsIE1pZ2F1bHQg YW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtaWV0Zi1k b3RzLXVzZS1jYXNlcw0KUmV2aXNpb246CTExDQpUaXRsZToJCVVzZSBjYXNlcyBmb3IgRERvUyBP cGVuIFRocmVhdCBTaWduYWxpbmcNCkRvY3VtZW50IGRhdGU6CTIwMTgtMDMtMjgNCkdyb3VwOgkJ ZG90cw0KUGFnZXM6CQkxNA0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWRvdHMtdXNlLWNhc2VzLTExLnR4dA0KU3RhdHVzOiAg ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtZG90cy11 c2UtY2FzZXMvDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtZG90cy11c2UtY2FzZXMtMTENCkh0bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtZG90cy11c2UtY2FzZXMNCkRpZmY6 ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1k b3RzLXVzZS1jYXNlcy0xMQ0KDQpBYnN0cmFjdDoNCiAgIFRoZSBERG9TIE9wZW4gVGhyZWF0IFNp Z25hbGluZyAoRE9UUykgZWZmb3J0IGlzIGludGVuZGVkIHRvIHByb3ZpZGUgYQ0KICAgcHJvdG9j b2wgdG8gZmFjaWxpdGF0ZSBpbnRlcm9wZXJhYmlsaXR5IGFjcm9zcyBkaXNwYXJhdGUgRERvUw0K ICAgbWl0aWdhdGlvbiBzb2x1dGlvbnMgYW5kIHNlcnZpY2VzLiAgVGhpcyBkb2N1bWVudCBwcmVz ZW50cyB1c2UgY2FzZXMNCiAgIHdoaWNoIGRlc2NyaWJlIHRoZSBpbnRlcmFjdGlvbnMgZXhwZWN0 ZWQgYmV0d2VlbiB0aGUgRE9UUyBjb21wb25lbnRzDQogICBhcyB3ZWxsIGFzIERPVFMgbWVzc2Fn aW5nIGV4Y2hhbmdlcy4gIFRoZSBwdXJwb3NlIG9mIGRlc2NyaWJpbmcgdXNlDQogICBjYXNlcyBp cyB0byBpZGVudGlmeSB0aGUgaW50ZXJhY3RpbmcgRE9UUyBjb21wb25lbnRzLCBob3cgdGhleQ0K ICAgY29sbGFib3JhdGUgYW5kIHdoYXQgYXJlIHRoZSB0eXBlcyBvZiBpbmZvcm1hdGlvbiB0byBi ZSBleGNoYW5nZWQuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90 ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBz dWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFi bGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpEb3RzIG1haWxpbmcgbGlz dA0KRG90c0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9k b3RzDQo= From nobody Wed Apr 4 01:20:09 2018 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 C3A06126BF3 for ; Wed, 4 Apr 2018 01:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wA0dAUG5n6vu for ; Wed, 4 Apr 2018 01:20:04 -0700 (PDT) Received: from guri.nttv6.jp (guri.nttv6.jp [IPv6:2402:c800:ff06:136::140]) by ietfa.amsl.com (Postfix) with ESMTP id 683DD124205 for ; Wed, 4 Apr 2018 01:20:03 -0700 (PDT) Received: from z.nttv6.jp (z.nttv6.jp [192.168.8.15]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id B204225F68C; Wed, 4 Apr 2018 17:20:02 +0900 (JST) Received: from MacBook-Pro-17.lv4.nttv6.jp (fujiko.nttv6.jp [115.69.228.141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id A76A77634E6; Wed, 4 Apr 2018 17:20:02 +0900 (JST) To: mohamed.boucadair@orange.com, "dots@ietf.org" References: <359EC4B99E040048A7131E0F4E113AFC014C36B932@marathon> <68904f77-3cef-4c77-4cfa-3aeaacf95133@nttv6.jp> <787AE7BB302AE849A7480A190F8B93302DEF7927@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7277ba5c-436b-9027-8be0-49c8a53dbde2@nttv6.jp> <787AE7BB302AE849A7480A190F8B93302DEF79C9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: kaname nishizuka Message-ID: Date: Wed, 4 Apr 2018 17:20:03 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DEF79C9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Dots] WGLC on DOTS Signal Channel 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: Wed, 04 Apr 2018 08:20:08 -0000 Hi Med, Thank you for the clarification and the proper reference. I can not assume that my DOTS client will do Out-of-Order Configuration Requests, but... I got understand that 'sid' is the solution to out of order configuration requests. 2 more questions: 1. GET with sid On the slide 12, it is written in the table that 'sid' URI Parameter MUST NOT exist in GET. However, In RFC7252: 5.8.1. GET  The GET method retrieves a representation for the information that  currently corresponds to the resource identified by the request URI. So, I think the resource made by PUT in the exact URI path may be retrieved by GET. I and Jon got consensus that the expected response of GET with sid is a "Figure 18: GET Configuration Response Body" like response with current value of that sid at the interop testing. The current draft is not clear about this behavior. 2. how to get default values after several negotiations GET without sid returns the current values. The default values can be retrieved only just after bootsrapping or sending DELETE request. (a DOTS client MAY send a DELETE request to set the configuration parameters to default values.) I'd like to get the default values even after negotiations. Is there any way to get them? thanks, Kaname On 2018/04/04 16:31, mohamed.boucadair@orange.com wrote: > Re-, > > Please see inline. > > Cheers, > Med > >> -----Message d'origine----- >> De : kaname nishizuka [mailto:kaname@nttv6.jp] >> Envoyé : mercredi 4 avril 2018 08:57 >> À : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org >> Objet : Re: [Dots] WGLC on DOTS Signal Channel >> >> Hi Med, >> >> >> On 2018/04/04 15:22, mohamed.boucadair@orange.com wrote: >>> Hi Kaname, >>> >>> Please see inline. >>> >>> Cheers, >>> Med >>> >>>> -----Message d'origine----- >>>> De : Dots [mailto:dots-bounces@ietf.org] De la part de kaname nishizuka >>>> Envoyé : mercredi 4 avril 2018 02:27 >>>> À : dots@ietf.org >>>> Objet : Re: [Dots] WGLC on DOTS Signal Channel >>>> >>>> Hi, >>>> >>>> I have one clarification questions about sid in signal channel session >>>> configuration. >>>> >>>> The draft says: >>>>  At least one of the attributes ’heartbeat-interval’, ’missing-hb >>>> allowed’, ’max-retransmit’, ’ack-timeout’, ’ack-random-factor’, and >>>>  ’trigger-mitigation’ MUST be present in the PUT request. >>>>  (snip) >>>>  The PUT request with a higher numeric ’sid’ value overrides the DOTS >>>>  signal channel session configuration data installed by a PUT request >>>>  with a lower numeric ’sid’ value. >>>> >>>> assuming these are default values of a DOTS server: >>>>  'heartbeat-interval'=30 >>>>  ’max-retransmit’=3 >>>> >>>> if these messages came to the DOTS server consecutively, >>>>  1. sid=123, "heartbeat-interval"=10 >>>>  2. sid=456, ’max-retransmit’=5 >>>> in the final state, the first change should be discarded?: >>>>  'heartbeat-interval'=30 >>>>  ’max-retransmit’=5 >>>> or accumulated?: >>>>  'heartbeat-interval'=10 >>>>  ’max-retransmit’=5 >>>> >>>> so, the question is: should they be overridden by default values even if >> it >>>> is not specified? >>> [Med] The behavior to follow is covered by this text: >>> >>> The PUT request with a higher numeric 'sid' value overrides the DOTS >>> signal channel session configuration data installed by a PUT request >>> with a lower numeric 'sid' value. To avoid maintaining a long list >>> of 'sid' requests from a DOTS client, the lower numeric 'sid' MUST be >>> automatically deleted and no longer available at the DOTS server. >>> >>> And >>> >>> The DOTS agents MUST use the negotiated >>> values for message transmission parameters and default values for >>> non-negotiated message transmission parameters. >> Thanks, so, in my example, final state is >>   'heartbeat-interval'=30 (reverted to default value) >>   ’max-retransmit’=5 >> and the lower numeric 'sid' no longer exist in the DOTS server, right? >> > [Med] Exactly. > >>>> I think the former is ideal behavior. >>>> However, if so, the DOTS server is only required to keep the latest >> resource >>>> of the highest sid, >>>> then there should be no difference between DELETE message with and without >>>> sid. >>>> >>> [Med] To delete a configuration, a client may send a DELETE with a valid >> 'sid' or a DELETE without supplying a 'sid'. >>> Both are considered as valid in Section 4.5.4. >>> >> both are OK and have the same effect on DOTS server, right? > [Med] Yes. > >> A DOTS server always keeps the latest sid only. > [Med] Not the "latest" received sid...but the request with the higher sid. > > A DOTS client always attempt >> to update it. >> So there is no reason to use PUT, GET, DELETE with sid. >> Why sid does exist is confusing me. > [Med] 'sid' is there to solve out of order configuration requests. The rationale is explained in slide 12 of https://datatracker.ietf.org/meeting/interim-2018-dots-01/materials/slides-interim-2018-dots-01-sessa-signal-channel-00.pdf > >> I'm afraid it was discussed on the ML but I'd like to know the rational of >> existence of sid. >> ``` >>  sid: Session Identifier is an identifier for the DOTS signal channel >>  session configuration data represented as an integer. This >>  identifier MUST be generated by DOTS clients. ’sid’ values MUST >>  increase monotonically. >> ``` >> this is not convincing because always only one configuration is registered on >> DOTS server. >> it will completely work without sid. >> >> thanks, >> Kaname >> >> >>>> regards, >>>> Kaname >>>> >>>> >>>> On 2018/03/21 19:32, Roman Danyliw wrote: >>>>> Hello! >>>>> >>>>> Consistent with our discussion at the London meeting, we are starting a >>>> working group last call (WGLC) for the DOTS Signal Channel draft: >>>>> DOTS Signal Channel Specification >>>>> draft-ietf-dots-signal-channel-18 >>>>> https://tools.ietf.org/html/draft-ietf-dots-signal-channel-18 >>>>> >>>>> Please send comments to the DOTS mailing list -- feedback on remaining >>>> issues or needed changes; as well as endorsements that this draft is >> ready. >>>>> This WGLC will end on April 6, 2018. >>>>> >>>>> Thanks, >>>>> Roman >>>>> >>>>> _______________________________________________ >>>>> Dots mailing list >>>>> Dots@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dots >>>> _______________________________________________ >>>> Dots mailing list >>>> Dots@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dots >>> _______________________________________________ >>> Dots mailing list >>> Dots@ietf.org >>> https://www.ietf.org/mailman/listinfo/dots > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Wed Apr 4 01:42:47 2018 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 06D8D1270A0 for ; Wed, 4 Apr 2018 01:42:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eSXQO0YfaMBC for ; Wed, 4 Apr 2018 01:42:44 -0700 (PDT) Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F058D126C25 for ; Wed, 4 Apr 2018 01:42:43 -0700 (PDT) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id CB408C08CD; Wed, 4 Apr 2018 10:42:42 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.75]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id AF95812007D; Wed, 4 Apr 2018 10:42:42 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe%18]) with mapi id 14.03.0382.000; Wed, 4 Apr 2018 10:42:42 +0200 From: To: Daniel Migault , "dots@ietf.org" Thread-Topic: New Version Notification for draft-ietf-dots-use-cases-11.txt Thread-Index: AQHTxp2XA/TKD8ITgUKM0ho3ak8psKPlrgKggAqmC/A= Date: Wed, 4 Apr 2018 08:42:41 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DEF7ADE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <152224582267.29792.2214827071198414612.idtracker@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C118E01184@eusaamb107.ericsson.se> In-Reply-To: <2DD56D786E600F45AC6BDE7DA4E8A8C118E01184@eusaamb107.ericsson.se> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] New Version Notification for draft-ietf-dots-use-cases-11.txt 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: Wed, 04 Apr 2018 08:42:47 -0000 Hi Daniel, all,=20 FWIW, you may find some comments to the -11 at:=20 PDF: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-iet= f-dots-use-cases-11-rev%20Med.pdf=20 DOC: https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-ietf= -dots-use-cases-11-rev%20Med.doc=20 Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Daniel Migault > Envoy=E9=A0: mercredi 28 mars 2018 16:24 > =C0=A0: dots@ietf.org > Objet=A0: [Dots] FW: New Version Notification for draft-ietf-dots-use-cas= es- > 11.txt >=20 > Hi everyone! >=20 > Please find the draft-ietf-dots-use-cases-11 [1]. In order to meet the > aggressive schedule agreed during the session in London, we would greatly > appreciate your feed backs by the end of the week ! >=20 > The current document is limited to 3 use cases described over 10ish pages= . We > believe the current document addresses the feed backs and comments we > received from the London session. If you believe otherwise, feel free to > bring this on the mailing list. >=20 > We expect to publish version 12 on Tuesday April 3. This version is expec= ted > to address the received comments and be ready to WGLC. >=20 > Comments can be addressed directly to the mailing list or using github pu= ll > requests on the mkd version [2]. If you believe some discussions are need= ed, > please consider discussing those on the mailing list. >=20 > Yours, > Daniel > [1] https://datatracker.ietf.org/doc/draft-ietf-dots-use-cases/ > [2] https://github.com/dotswg/dots-use-cases/blob/master/draft-ietf-dots= - > use-cases.mkd >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Wednesday, March 28, 2018 10:04 AM > To: Kaname Nishizuka ; Nik Teague = ; > Daniel Migault ; Robert Moskowitz consult.com>; Stefan Fouant ; dots- > chairs@ietf.org; Roland Dobbins ; Liang Xia > ; Liang Xia > Subject: New Version Notification for draft-ietf-dots-use-cases-11.txt >=20 >=20 > A new version of I-D, draft-ietf-dots-use-cases-11.txt has been successfu= lly > submitted by Daniel Migault and posted to the IETF repository. >=20 > Name: draft-ietf-dots-use-cases > Revision: 11 > Title: Use cases for DDoS Open Threat Signaling > Document date: 2018-03-28 > Group: dots > Pages: 14 > URL: https://www.ietf.org/internet-drafts/draft-ietf-dots-use- > cases-11.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-dots-use-case= s/ > Htmlized: https://tools.ietf.org/html/draft-ietf-dots-use-cases-11 > Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-dots-use= - > cases > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-use-c= ases- > 11 >=20 > Abstract: > The DDoS Open Threat Signaling (DOTS) effort is intended to provide a > protocol to facilitate interoperability across disparate DDoS > mitigation solutions and services. This document presents use cases > which describe the interactions expected between the DOTS components > as well as DOTS messaging exchanges. The purpose of describing use > cases is to identify the interacting DOTS components, how they > collaborate and what are the types of information to be exchanged. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Wed Apr 4 02:28:55 2018 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 7253712711E for ; Wed, 4 Apr 2018 02:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTTMiCwqevwX for ; Wed, 4 Apr 2018 02:28:50 -0700 (PDT) Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6F72127137 for ; Wed, 4 Apr 2018 02:28:45 -0700 (PDT) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 2D1A81605E7; Wed, 4 Apr 2018 11:28:44 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.3]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id 08C52180040; Wed, 4 Apr 2018 11:28:44 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5D.corporate.adroot.infra.ftgroup ([fe80::9898:741c:bc1d:258d%19]) with mapi id 14.03.0382.000; Wed, 4 Apr 2018 11:28:43 +0200 From: To: kaname nishizuka , "dots@ietf.org" Thread-Topic: [Dots] WGLC on DOTS Signal Channel Thread-Index: AQHTy+29427zaWmK9EWqKy/wwFv6N6PwSj5A Date: Wed, 4 Apr 2018 09:28:43 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DEF7B45@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <359EC4B99E040048A7131E0F4E113AFC014C36B932@marathon> <68904f77-3cef-4c77-4cfa-3aeaacf95133@nttv6.jp> <787AE7BB302AE849A7480A190F8B93302DEF7927@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7277ba5c-436b-9027-8be0-49c8a53dbde2@nttv6.jp> <787AE7BB302AE849A7480A190F8B93302DEF79C9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] WGLC on DOTS Signal Channel 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: Wed, 04 Apr 2018 09:28:53 -0000 UmUtLA0KDQpUaGFuayB5b3UgZm9yICB0aGUgY29tbWVudHMuIA0KDQpQbGVhc2Ugc2VlIGlubGlu ZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERl wqA6IGthbmFtZSBuaXNoaXp1a2EgW21haWx0bzprYW5hbWVAbnR0djYuanBdDQo+IEVudm95w6nC oDogbWVyY3JlZGkgNCBhdnJpbCAyMDE4IDEwOjIwDQo+IMOAwqA6IEJPVUNBREFJUiBNb2hhbWVk IElNVC9PTE47IGRvdHNAaWV0Zi5vcmcNCj4gT2JqZXTCoDogUmU6IFtEb3RzXSBXR0xDIG9uIERP VFMgU2lnbmFsIENoYW5uZWwNCj4gDQo+IEhpIE1lZCwNCj4gDQo+IFRoYW5rIHlvdSBmb3IgdGhl IGNsYXJpZmljYXRpb24gYW5kIHRoZSBwcm9wZXIgcmVmZXJlbmNlLg0KPiBJIGNhbiBub3QgYXNz dW1lIHRoYXQgbXkgRE9UUyBjbGllbnQgd2lsbCBkbyBPdXQtb2YtT3JkZXIgQ29uZmlndXJhdGlv bg0KPiBSZXF1ZXN0cywgYnV0Li4uIEkgZ290IHVuZGVyc3RhbmQgdGhhdCAnc2lkJyBpcyB0aGUg c29sdXRpb24gdG8gb3V0IG9mIG9yZGVyDQo+IGNvbmZpZ3VyYXRpb24gcmVxdWVzdHMuDQo+IA0K PiAyIG1vcmUgcXVlc3Rpb25zOg0KPiANCj4gMS4gR0VUIHdpdGggc2lkDQo+IE9uIHRoZSBzbGlk ZSAxMiwgaXQgaXMgd3JpdHRlbiBpbiB0aGUgdGFibGUgdGhhdCAnc2lkJyBVUkkgUGFyYW1ldGVy IE1VU1QgTk9UDQo+IGV4aXN0IGluIEdFVC4NCg0KW01lZF0gQWN0dWFsbHksIHRoZSBHRVQgaW4g dGhhdCBzbGlkZSByZWZlcnMgdG8gdGhlIGNhc2UgdG8gZGlzY292ZXIgY29uZmlndXJhdGlvbiBw YXJhbWV0ZXJzIHdoZW4sIGZvciBleGFtcGxlLCBhIGNsaWVudCBib290c3RyYXBzLiBJbiBzdWNo IGNhc2UsIHRoZXJlIGlzIG5vICdzaWQnIHRvIHBsYXkgd2l0aC4NCg0KPiBIb3dldmVyLCBJbiBS RkM3MjUyOg0KPiA1LjguMS4gR0VUDQo+ICDCoFRoZSBHRVQgbWV0aG9kIHJldHJpZXZlcyBhIHJl cHJlc2VudGF0aW9uIGZvciB0aGUgaW5mb3JtYXRpb24gdGhhdA0KPiAgwqBjdXJyZW50bHkgY29y cmVzcG9uZHMgdG8gdGhlIHJlc291cmNlIGlkZW50aWZpZWQgYnkgdGhlIHJlcXVlc3QgVVJJLg0K PiANCj4gU28sIEkgdGhpbmsgdGhlIHJlc291cmNlIG1hZGUgYnkgUFVUIGluIHRoZSBleGFjdCBV UkkgcGF0aCBtYXkgYmUgcmV0cmlldmVkDQo+IGJ5IEdFVC4NCg0KW01lZF0gQWdyZWUuIFRoZSBz aWduYWwgY2hhbm5lbCBzcGVjaWZpY2F0aW9uIGRvZXMgbm90IGNoYW5nZSB0aGUgUkZDNzI1MiBi ZWhhdmlvci4NCg0KPiBJIGFuZCBKb24gZ290IGNvbnNlbnN1cyB0aGF0IHRoZSBleHBlY3RlZCBy ZXNwb25zZSBvZiBHRVQgd2l0aCBzaWQgaXMgYQ0KPiAiRmlndXJlIDE4OiBHRVQgQ29uZmlndXJh dGlvbiBSZXNwb25zZSBCb2R5IiBsaWtlIHJlc3BvbnNlIHdpdGggY3VycmVudCB2YWx1ZQ0KPiBv ZiB0aGF0IHNpZCBhdCB0aGUgaW50ZXJvcCB0ZXN0aW5nLg0KPiBUaGUgY3VycmVudCBkcmFmdCBp cyBub3QgY2xlYXIgYWJvdXQgdGhpcyBiZWhhdmlvci4NCg0KW01lZF0gQXMgSSBtZW50aW9uZWQg YWJvdmUsIHdlIGFyZSBub3QgY2hhbmdpbmcgdGhlIDcyNTIgYmVoYXZpb3IuIEkgY2FuIGFkZCB0 aGlzIE5FVyB0ZXh0IGlmIGl0IGhlbHBzOiANCg0KICAgQSBET1RTIGNsaWVudCBtYXkgaXNzdWUg YSBHRVQgbWVzc2FnZSB3aXRoIG9yIHdpdGhvdXQgJ3NpZCcgcGFyYW1ldGVyDQogICB0byByZXRy aWV2ZSB0aGUgY29uZmlndXJhdGlvbiBwYXJhbWV0ZXJzLiAgVGhlIHJlc3BvbnNlIG1lc3NhZ2Ug Ym9keQ0KICAgaXMgdGhlIHNhbWUgYXMgdGhlIG9uZSBkZXBpY3RlZCBpbiBGaWd1cmUgMTguDQog DQo+IA0KPiAyLiBob3cgdG8gZ2V0IGRlZmF1bHQgdmFsdWVzIGFmdGVyIHNldmVyYWwgbmVnb3Rp YXRpb25zDQo+IEdFVCB3aXRob3V0IHNpZCByZXR1cm5zIHRoZSBjdXJyZW50IHZhbHVlcy4NCj4g VGhlIGRlZmF1bHQgdmFsdWVzIGNhbiBiZSByZXRyaWV2ZWQgb25seSBqdXN0IGFmdGVyIGJvb3Rz cmFwcGluZyBvciBzZW5kaW5nDQo+IERFTEVURSByZXF1ZXN0Lg0KPiAoYSBET1RTIGNsaWVudCBN QVkgc2VuZCBhIERFTEVURSByZXF1ZXN0IHRvIHNldCB0aGUgY29uZmlndXJhdGlvbiBwYXJhbWV0 ZXJzDQo+IHRvIGRlZmF1bHQgdmFsdWVzLikNCj4gSSdkIGxpa2UgdG8gZ2V0IHRoZSBkZWZhdWx0 IHZhbHVlcyBldmVuIGFmdGVyIG5lZ290aWF0aW9ucy4gSXMgdGhlcmUgYW55IHdheQ0KPiB0byBn ZXQgdGhlbT8NCg0KW01lZF0gRGVmYXVsdCB2YWx1ZXMgYXJlIGtub3duIHRvIERPVFMgYWdlbnRz IGJ5IGRlc2lnbi4gVGhhdCBpcyBhIERPVFMgYWdlbnQgYXNzdW1lcyB0aGUgZm9sbG93aW5nIGRl ZmF1bHQgdmFsdWVzOiANCg0KVGhlIFJFQ09NTUVOREVEIHZhbHVlcyBvZiB0cmFuc21pc3Npb24g cGFyYW1ldGVyDQogICB2YWx1ZXMgYXJlIGFjay10aW1lb3V0ICgyIHNlY29uZHMpLCBtYXgtcmV0 cmFuc21pdCAoMyksIGFjay1yYW5kb20tDQogICBmYWN0b3IgKDEuNSkuICBJbiBhZGRpdGlvbiB0 byB0aG9zZSBwYXJhbWV0ZXJzLCB0aGUgUkVDT01NRU5ERUQNCiAgIHNwZWNpZmljIERPVFMgdHJh bnNtaXNzaW9uIHBhcmFtZXRlciB2YWx1ZXMgYXJlICdoZWFydGJlYXQtaW50ZXJ2YWwnDQogICAo MzAgc2Vjb25kcykgYW5kICdtaXNzaW5nLWhiLWFsbG93ZWQnICg1KS4NCg0KV2hlbiBET1RTIGFn ZW50cyBuZWdvdGlhdGUgYSBnaXZlbiBwYXJhbWV0ZXIsIHRoZSBuZWdvdGlhdGVkIHZhbHVlIGlz IHVzZWQgdG8gb3ZlcnJpZGUgdGhlIGRlZmF1bHQgb25lLiBPdGhlcndpc2UsIHRoZSBkZWZhdWx0 IHZhbHVlIGlzIHVzZWQuIA0KDQpBIERPVFMgY2xpZW50IG1haW50YWlucyBhIHN0YXRlIHdoZXRo ZXIgYSB2YWx1ZSB3YXMgbmVnb3RpYXRlZC4gQXMgc3VjaCwgYSBET1RTIGNsaWVudCBkb2VzIG5v dCBuZWVkIHRvIGRpc2NvdmVyIGRlZmF1bHQgdmFsdWVzLg0KDQpEaWQgSSBtaXNzZWQgc29tZXRo aW5nPw0KDQo+IA0KPiB0aGFua3MsDQo+IEthbmFtZQ0KPiANCj4gDQo+IA0KPiBPbiAyMDE4LzA0 LzA0IDE2OjMxLCBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIHdyb3RlOg0KPiA+IFJlLSwN Cj4gPg0KPiA+IFBsZWFzZSBzZWUgaW5saW5lLg0KPiA+DQo+ID4gQ2hlZXJzLA0KPiA+IE1lZA0K PiA+DQo+ID4+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiA+PiBEZcKgOiBrYW5hbWUg bmlzaGl6dWthIFttYWlsdG86a2FuYW1lQG50dHY2LmpwXQ0KPiA+PiBFbnZvecOpwqA6IG1lcmNy ZWRpIDQgYXZyaWwgMjAxOCAwODo1Nw0KPiA+PiDDgMKgOiBCT1VDQURBSVIgTW9oYW1lZCBJTVQv T0xOOyBkb3RzQGlldGYub3JnDQo+ID4+IE9iamV0wqA6IFJlOiBbRG90c10gV0dMQyBvbiBET1RT IFNpZ25hbCBDaGFubmVsDQo+ID4+DQo+ID4+IEhpIE1lZCwNCj4gPj4NCj4gPj4NCj4gPj4gT24g MjAxOC8wNC8wNCAxNToyMiwgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSB3cm90ZToNCj4g Pj4+IEhpIEthbmFtZSwNCj4gPj4+DQo+ID4+PiBQbGVhc2Ugc2VlIGlubGluZS4NCj4gPj4+DQo+ ID4+PiBDaGVlcnMsDQo+ID4+PiBNZWQNCj4gPj4+DQo+ID4+Pj4gLS0tLS1NZXNzYWdlIGQnb3Jp Z2luZS0tLS0tDQo+ID4+Pj4gRGXCoDogRG90cyBbbWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9y Z10gRGUgbGEgcGFydCBkZSBrYW5hbWUgbmlzaGl6dWthDQo+ID4+Pj4gRW52b3nDqcKgOiBtZXJj cmVkaSA0IGF2cmlsIDIwMTggMDI6MjcNCj4gPj4+PiDDgMKgOiBkb3RzQGlldGYub3JnDQo+ID4+ Pj4gT2JqZXTCoDogUmU6IFtEb3RzXSBXR0xDIG9uIERPVFMgU2lnbmFsIENoYW5uZWwNCj4gPj4+ Pg0KPiA+Pj4+IEhpLA0KPiA+Pj4+DQo+ID4+Pj4gSSBoYXZlIG9uZSBjbGFyaWZpY2F0aW9uIHF1 ZXN0aW9ucyBhYm91dCBzaWQgaW4gc2lnbmFsIGNoYW5uZWwgc2Vzc2lvbg0KPiA+Pj4+IGNvbmZp Z3VyYXRpb24uDQo+ID4+Pj4NCj4gPj4+PiBUaGUgZHJhZnQgc2F5czoNCj4gPj4+PiAgICDCoEF0 IGxlYXN0IG9uZSBvZiB0aGUgYXR0cmlidXRlcyDigJloZWFydGJlYXQtaW50ZXJ2YWzigJksIOKA mW1pc3NpbmctaGINCj4gPj4+PiBhbGxvd2Vk4oCZLCDigJltYXgtcmV0cmFuc21pdOKAmSwg4oCZ YWNrLXRpbWVvdXTigJksIOKAmWFjay1yYW5kb20tZmFjdG9y4oCZLCBhbmQNCj4gPj4+PiAgICDC oOKAmXRyaWdnZXItbWl0aWdhdGlvbuKAmSBNVVNUIGJlIHByZXNlbnQgaW4gdGhlIFBVVCByZXF1 ZXN0Lg0KPiA+Pj4+ICAgIMKgKHNuaXApDQo+ID4+Pj4gICAgwqBUaGUgUFVUIHJlcXVlc3Qgd2l0 aCBhIGhpZ2hlciBudW1lcmljIOKAmXNpZOKAmSB2YWx1ZSBvdmVycmlkZXMgdGhlIERPVFMNCj4g Pj4+PiAgICDCoHNpZ25hbCBjaGFubmVsIHNlc3Npb24gY29uZmlndXJhdGlvbiBkYXRhIGluc3Rh bGxlZCBieSBhIFBVVCByZXF1ZXN0DQo+ID4+Pj4gICAgwqB3aXRoIGEgbG93ZXIgbnVtZXJpYyDi gJlzaWTigJkgdmFsdWUuDQo+ID4+Pj4NCj4gPj4+PiBhc3N1bWluZyB0aGVzZSBhcmUgZGVmYXVs dCB2YWx1ZXMgb2YgYSBET1RTIHNlcnZlcjoNCj4gPj4+PiAgICDCoCdoZWFydGJlYXQtaW50ZXJ2 YWwnPTMwDQo+ID4+Pj4gICAgwqDigJltYXgtcmV0cmFuc21pdOKAmT0zDQo+ID4+Pj4NCj4gPj4+ PiBpZiB0aGVzZSBtZXNzYWdlcyBjYW1lIHRvIHRoZSBET1RTIHNlcnZlciBjb25zZWN1dGl2ZWx5 LA0KPiA+Pj4+ICAgIMKgMS4gc2lkPTEyMywgImhlYXJ0YmVhdC1pbnRlcnZhbCI9MTANCj4gPj4+ PiAgICDCoDIuIHNpZD00NTYsIOKAmW1heC1yZXRyYW5zbWl04oCZPTUNCj4gPj4+PiBpbiB0aGUg ZmluYWwgc3RhdGUsIHRoZSBmaXJzdCBjaGFuZ2Ugc2hvdWxkIGJlIGRpc2NhcmRlZD86DQo+ID4+ Pj4gICAgwqAnaGVhcnRiZWF0LWludGVydmFsJz0zMA0KPiA+Pj4+ICAgIMKg4oCZbWF4LXJldHJh bnNtaXTigJk9NQ0KPiA+Pj4+IG9yIGFjY3VtdWxhdGVkPzoNCj4gPj4+PiAgICDCoCdoZWFydGJl YXQtaW50ZXJ2YWwnPTEwDQo+ID4+Pj4gICAgwqDigJltYXgtcmV0cmFuc21pdOKAmT01DQo+ID4+ Pj4NCj4gPj4+PiBzbywgdGhlIHF1ZXN0aW9uIGlzOiBzaG91bGQgdGhleSBiZSBvdmVycmlkZGVu IGJ5IGRlZmF1bHQgdmFsdWVzIGV2ZW4gaWYNCj4gPj4gaXQNCj4gPj4+PiBpcyBub3Qgc3BlY2lm aWVkPw0KPiA+Pj4gW01lZF0gVGhlIGJlaGF2aW9yIHRvIGZvbGxvdyBpcyBjb3ZlcmVkIGJ5IHRo aXMgdGV4dDoNCj4gPj4+DQo+ID4+PiAgICAgIFRoZSBQVVQgcmVxdWVzdCB3aXRoIGEgaGlnaGVy IG51bWVyaWMgJ3NpZCcgdmFsdWUgb3ZlcnJpZGVzIHRoZSBET1RTDQo+ID4+PiAgICAgIHNpZ25h bCBjaGFubmVsIHNlc3Npb24gY29uZmlndXJhdGlvbiBkYXRhIGluc3RhbGxlZCBieSBhIFBVVCBy ZXF1ZXN0DQo+ID4+PiAgICAgIHdpdGggYSBsb3dlciBudW1lcmljICdzaWQnIHZhbHVlLiAgVG8g YXZvaWQgbWFpbnRhaW5pbmcgYSBsb25nIGxpc3QNCj4gPj4+ICAgICAgb2YgJ3NpZCcgcmVxdWVz dHMgZnJvbSBhIERPVFMgY2xpZW50LCB0aGUgbG93ZXIgbnVtZXJpYyAnc2lkJyBNVVNUDQo+IGJl DQo+ID4+PiAgICAgIGF1dG9tYXRpY2FsbHkgZGVsZXRlZCBhbmQgbm8gbG9uZ2VyIGF2YWlsYWJs ZSBhdCB0aGUgRE9UUyBzZXJ2ZXIuDQo+ID4+Pg0KPiA+Pj4gQW5kDQo+ID4+Pg0KPiA+Pj4gICAg ICBUaGUgRE9UUyBhZ2VudHMgTVVTVCB1c2UgdGhlIG5lZ290aWF0ZWQNCj4gPj4+ICAgICAgdmFs dWVzIGZvciBtZXNzYWdlIHRyYW5zbWlzc2lvbiBwYXJhbWV0ZXJzIGFuZCBkZWZhdWx0IHZhbHVl cyBmb3INCj4gPj4+ICAgICAgbm9uLW5lZ290aWF0ZWQgbWVzc2FnZSB0cmFuc21pc3Npb24gcGFy YW1ldGVycy4NCj4gPj4gVGhhbmtzLCBzbywgaW4gbXkgZXhhbXBsZSwgZmluYWwgc3RhdGUgaXMN Cj4gPj4gICDCoCAnaGVhcnRiZWF0LWludGVydmFsJz0zMCAocmV2ZXJ0ZWQgdG8gZGVmYXVsdCB2 YWx1ZSkNCj4gPj4gICDCoCDigJltYXgtcmV0cmFuc21pdOKAmT01DQo+ID4+IGFuZCB0aGUgbG93 ZXIgbnVtZXJpYyAnc2lkJyBubyBsb25nZXIgZXhpc3QgaW4gdGhlIERPVFMgc2VydmVyLCByaWdo dD8NCj4gPj4NCj4gPiBbTWVkXSBFeGFjdGx5Lg0KPiA+DQo+ID4+Pj4gSSB0aGluayB0aGUgZm9y bWVyIGlzIGlkZWFsIGJlaGF2aW9yLg0KPiA+Pj4+IEhvd2V2ZXIsIGlmIHNvLCB0aGUgRE9UUyBz ZXJ2ZXIgaXMgb25seSByZXF1aXJlZCB0byBrZWVwIHRoZSBsYXRlc3QNCj4gPj4gcmVzb3VyY2UN Cj4gPj4+PiBvZiB0aGUgaGlnaGVzdCBzaWQsDQo+ID4+Pj4gdGhlbiB0aGVyZSBzaG91bGQgYmUg bm8gZGlmZmVyZW5jZSBiZXR3ZWVuIERFTEVURSBtZXNzYWdlIHdpdGggYW5kDQo+IHdpdGhvdXQN Cj4gPj4+PiBzaWQuDQo+ID4+Pj4NCj4gPj4+IFtNZWRdIFRvIGRlbGV0ZSBhIGNvbmZpZ3VyYXRp b24sIGEgY2xpZW50IG1heSBzZW5kIGEgREVMRVRFIHdpdGggYSB2YWxpZA0KPiA+PiAnc2lkJyBv ciBhIERFTEVURSB3aXRob3V0IHN1cHBseWluZyBhICdzaWQnLg0KPiA+Pj4gQm90aCBhcmUgY29u c2lkZXJlZCBhcyB2YWxpZCBpbiBTZWN0aW9uIDQuNS40Lg0KPiA+Pj4NCj4gPj4gYm90aCBhcmUg T0sgYW5kIGhhdmUgdGhlIHNhbWUgZWZmZWN0IG9uIERPVFMgc2VydmVyLCByaWdodD8NCj4gPiBb TWVkXSBZZXMuDQo+ID4NCj4gPj4gQSBET1RTIHNlcnZlciBhbHdheXMga2VlcHMgdGhlIGxhdGVz dCBzaWQgb25seS4NCj4gPiBbTWVkXSBOb3QgdGhlICJsYXRlc3QiIHJlY2VpdmVkIHNpZC4uLmJ1 dCB0aGUgcmVxdWVzdCB3aXRoIHRoZSBoaWdoZXIgc2lkLg0KPiA+DQo+ID4gICBBIERPVFMgY2xp ZW50IGFsd2F5cyBhdHRlbXB0DQo+ID4+IHRvIHVwZGF0ZSBpdC4NCj4gPj4gU28gdGhlcmUgaXMg bm8gcmVhc29uIHRvIHVzZSBQVVQsIEdFVCwgREVMRVRFIHdpdGggc2lkLg0KPiA+PiBXaHkgc2lk IGRvZXMgZXhpc3QgaXMgY29uZnVzaW5nIG1lLg0KPiA+IFtNZWRdICdzaWQnIGlzIHRoZXJlIHRv IHNvbHZlIG91dCBvZiBvcmRlciBjb25maWd1cmF0aW9uIHJlcXVlc3RzLiBUaGUNCj4gcmF0aW9u YWxlIGlzIGV4cGxhaW5lZCBpbiBzbGlkZSAxMiBvZg0KPiBodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL21lZXRpbmcvaW50ZXJpbS0yMDE4LWRvdHMtMDEvbWF0ZXJpYWxzL3NsaWRlcy0NCj4g aW50ZXJpbS0yMDE4LWRvdHMtMDEtc2Vzc2Etc2lnbmFsLWNoYW5uZWwtMDAucGRmDQo+ID4NCj4g Pj4gSSdtIGFmcmFpZCBpdCB3YXMgZGlzY3Vzc2VkIG9uIHRoZSBNTCBidXQgSSdkIGxpa2UgdG8g a25vdyB0aGUgcmF0aW9uYWwgb2YNCj4gPj4gZXhpc3RlbmNlIG9mIHNpZC4NCj4gPj4gYGBgDQo+ ID4+ICAgwqBzaWQ6IFNlc3Npb24gSWRlbnRpZmllciBpcyBhbiBpZGVudGlmaWVyIGZvciB0aGUg RE9UUyBzaWduYWwgY2hhbm5lbA0KPiA+PiAgIMKgc2Vzc2lvbiBjb25maWd1cmF0aW9uIGRhdGEg cmVwcmVzZW50ZWQgYXMgYW4gaW50ZWdlci4gVGhpcw0KPiA+PiAgIMKgaWRlbnRpZmllciBNVVNU IGJlIGdlbmVyYXRlZCBieSBET1RTIGNsaWVudHMuIOKAmXNpZOKAmSB2YWx1ZXMgTVVTVA0KPiA+ PiAgIMKgaW5jcmVhc2UgbW9ub3RvbmljYWxseS4NCj4gPj4gYGBgDQo+ID4+IHRoaXMgaXMgbm90 IGNvbnZpbmNpbmcgYmVjYXVzZSBhbHdheXMgb25seSBvbmUgY29uZmlndXJhdGlvbiBpcyByZWdp c3RlcmVkDQo+IG9uDQo+ID4+IERPVFMgc2VydmVyLg0KPiA+PiBpdCB3aWxsIGNvbXBsZXRlbHkg d29yayB3aXRob3V0IHNpZC4NCj4gPj4NCj4gPj4gdGhhbmtzLA0KPiA+PiBLYW5hbWUNCj4gPj4N Cj4gPj4NCj4gPj4+PiByZWdhcmRzLA0KPiA+Pj4+IEthbmFtZQ0KPiA+Pj4+DQo+ID4+Pj4NCj4g Pj4+PiBPbiAyMDE4LzAzLzIxIDE5OjMyLCBSb21hbiBEYW55bGl3IHdyb3RlOg0KPiA+Pj4+PiBI ZWxsbyENCj4gPj4+Pj4NCj4gPj4+Pj4gQ29uc2lzdGVudCB3aXRoIG91ciBkaXNjdXNzaW9uIGF0 IHRoZSBMb25kb24gbWVldGluZywgd2UgYXJlIHN0YXJ0aW5nIGENCj4gPj4+PiB3b3JraW5nIGdy b3VwIGxhc3QgY2FsbCAoV0dMQykgZm9yIHRoZSBET1RTIFNpZ25hbCBDaGFubmVsIGRyYWZ0Og0K PiA+Pj4+PiBET1RTIFNpZ25hbCBDaGFubmVsIFNwZWNpZmljYXRpb24NCj4gPj4+Pj4gZHJhZnQt aWV0Zi1kb3RzLXNpZ25hbC1jaGFubmVsLTE4DQo+ID4+Pj4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNoYW5uZWwtMTgNCj4gPj4+Pj4NCj4gPj4+ Pj4gUGxlYXNlIHNlbmQgY29tbWVudHMgdG8gdGhlIERPVFMgbWFpbGluZyBsaXN0IC0tIGZlZWRi YWNrIG9uIHJlbWFpbmluZw0KPiA+Pj4+IGlzc3VlcyBvciBuZWVkZWQgY2hhbmdlczsgYXMgd2Vs bCBhcyBlbmRvcnNlbWVudHMgdGhhdCB0aGlzIGRyYWZ0IGlzDQo+ID4+IHJlYWR5Lg0KPiA+Pj4+ PiBUaGlzIFdHTEMgd2lsbCBlbmQgb24gQXByaWwgNiwgMjAxOC4NCj4gPj4+Pj4NCj4gPj4+Pj4g VGhhbmtzLA0KPiA+Pj4+PiBSb21hbg0KPiA+Pj4+Pg0KPiA+Pj4+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4+PiBEb3RzIG1haWxpbmcgbGlz dA0KPiA+Pj4+PiBEb3RzQGlldGYub3JnDQo+ID4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vZG90cw0KPiA+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+ID4+Pj4gRG90cyBtYWlsaW5nIGxpc3QNCj4gPj4+PiBEb3Rz QGlldGYub3JnDQo+ID4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9k b3RzDQo+ID4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiA+Pj4gRG90cyBtYWlsaW5nIGxpc3QNCj4gPj4+IERvdHNAaWV0Zi5vcmcNCj4gPj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90cw0KPiA+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gRG90cyBtYWlsaW5nIGxp c3QNCj4gPiBEb3RzQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9kb3RzDQoNCg== From nobody Wed Apr 4 05:46:30 2018 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 42148124B0A for ; Wed, 4 Apr 2018 05:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWZnS1Zrm-Fu for ; Wed, 4 Apr 2018 05:46:24 -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 341D4127444 for ; Wed, 4 Apr 2018 05:46:24 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.90_1) (envelope-from ) id 1f3hnx-0006SC-Ex; Wed, 04 Apr 2018 13:46:21 +0100 From: "Jon Shallow" To: , References: <05c801d3c2bc$88171290$984537b0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF10B4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <018701d3c5c8$044db950$0ce92bf0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF3579@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <01d001d3c5de$410e3ca0$c32ab5e0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF3B49@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <026a01d3c678$6bb62270$43226750$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF3CE9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <02ed01d3c697$5de338d0$19a9aa70$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF3F98@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DEF3F98@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Wed, 4 Apr 2018 13:46:22 +0100 Message-ID: <00f501d3cc12$ef7de800$ce79b800$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F6_01D3CC1B.51458450" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLZExA96e11tdoJyqOqcaxu1U7VtQIUMridAPIe3SYBQh+XjQFy2griAn3xOeQCNYLpVgIv3jouAUgX1jkB7g8ay6FnWW1w Content-Language: en-gb Archived-At: Subject: Re: [Dots] WGLC signal-18 Draft Hop Limit tidy up 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: Wed, 04 Apr 2018 12:46:28 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00F6_01D3CC1B.51458450 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This can be closed. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 28 March 2018 15:16 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] WGLC signal-18 Draft Hop Limit tidy up =20 Jon,=20 =20 RFC7252 does already mention the following :=20 =20 If the Path MTU is not known for a destination, an IP MTU of 1280 bytes SHOULD be assumed; if nothing is known about the size of the headers, good upper bounds are 1152 bytes for the message size and 1024 bytes for the payload size. =20 We do already refer to that section in the draft. We don=92t need to = call out again for this particular case.=20 =20 Thank you.=20 =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : mercredi 28 mars 2018 15:19 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: [Dots] WGLC signal-18 Draft Hop Limit tidy up =20 Hi Med, =20 One thing that I earlier commented on appears to have slipped through = the net (and I missed spotting it in your update) =20 =93The diagnostic message length would need to be restricted to = something like 1000 bytes to prevent UDP fragmentation.=94 =20 This could be applied to all CoAP diagnostic messages (RFC7252 does not = seem to pick this up) or just to the hop-limit response (which could get = large). =20 Perhaps the text could read something like:- =93Each intermediate DOTS gateway involved in relaying a 5.06 (Hop Limit Reached) error message SHOULD prepend its own information in the diagnostic payload with a space character used as separator, subject to there being sufficient extra space in the diagnostic payload so that the = overall packet does not exceed the IP MTU (RFC7252 4.6. Message Size) .=94 =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 28 March 2018 12:58 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] WGLC signal-18 Draft Hop Limit tidy up =20 Re-, =20 I confirm that I implemented the changes we agreed in my local copy.=20 =20 You may double check at: https://github.com/boucadair/draft-ietf-dots-signal-channel=20 =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : mercredi 28 mars 2018 11:38 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: [Dots] WGLC signal-18 Draft Hop Limit tidy up =20 Hi Med, =20 See inline [Jon3] =20 Regards =20 Jon =20 =20 =20 =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : vendredi 23 mars 2018 16:35 =C0 : dots@ietf.org Objet : [Dots] WGLC signal-18 Draft Hop Limit tidy up =20 Hi there, =20 I believe that there are a couple of changes required for the hop-limit definition =96 see [Jon] inline. =20 hop-limit: This option (see Section 9.4) is used to detect = and prevent infinite loops. This option is typically inserted = by a DOTS gateway. =20 The length of the hop-limit option is 1 byte. =20 The value of the hop-limit option is encoded as an = unsigned integer (see Section 3.2 of [RFC7252]). =20 Each intermediate DOTS agent involved in the handling of a DOTS message MUST decrement the hop-limit option value by 1 = prior to forwarding upstream if this parameter exists. DOTS = messages MUST NOT be forwarded if the hop-limit option is set to '0' = after decrement. Messages that cannot be forwarded because of exhausted hop-limit SHOULD be logged with a 5.06 (Hop Limit Reached) error message sent back to the DOTS peer. It is RECOMMENDED = that DOTS clients and gateways support means to alert administrators about loop errors so that appropriate actions are undertaken. [Jon] We need to add in something like:- Each intermediate DOTS agent SHOULD add in the hop-limit option with the initial default value if it does not exist before forwarding upstream = any information. =20 [Med] I=92m not sure to understand this one. Please note that the text = says =93A DOTS gateway may add the following CoAP option=94. This is typically a = GW which is instructed to insert the option will inject the option and = follows the setting of the initial value. =20 [Jon1] I guess that I am trying to differentiate between updating an existing Hop-Limit and not injecting a new one alongside a previous one. Having multiple Hop-Limit options could get interesting! [Med] OK, I get your point. What about adding :=20 NEW: Only one single instance of the option is allowed in a message. [Jon2] Works for me [Med] OK, thanks. =20 [Jon] We need to define the format of the 5.06 CoAP diagnostic message = so that it is potentially parseable by the DOTS client as well as by any = other potential RFC that make use of this 5.06 code. In addition, it would be good if each intermediate DOTS agent appended its own IP (prefixed by a blank) to the end of the diagnostic message as the 5.06 response gets = passed back through the DOST agents to enable troubleshooting at the DOTS = client. The diagnostic message length would need to be restricted to something = like 1000 bytes to prevent UDP fragmentation. Suggestions welcome here. =20 [Med] I can see a value in recording the list of GWs involved in a loop = for debugging purposes at the DOTS server domain, but I=92m not sure there = is a value to pass that list to the DOTS client. For example, a server domain = may want to hide its internal topology (list of GWs and servers involved in handling a mitigation request). Below a text proposal for discussion: =20 To ease debugging and troubleshooting, the DOTS gateway which detects a loop SHOULD include its information (e.g., server name, alias, IP address) in the diagnostic payload under the conditions detailed in Section 5.5.2 of [RFC7252]. Each intermediate DOTS gateway involved in relaying a 5.06 (Hop Limit Reached) error message SHOULD prepend its own information in the diagnostic payload with a space character used as separator. The ultimate DOTS gateway SHOULD remove the diagnostic payload before forwarding the 5.06 (Hop Limit Reached) error message to a DOTS client domain. [Jon1] I have no issues if a server domain really wants to strip out its internal hops =96 but troubleshooting is more of a challenge and would = not recommend it. [Jon1] However, when setting up a DOTS client, which is failing to work = for whatever reason, it would be good to have a reasonable level of = diagnostics on the Client =96 separately invoking someone to look at a DOTS = server=92s logs may take time=20 to get responded to =96 and you as a novice DOTS client user will have = no idea as to what to tell the DOTS server guy to look for in the server=92s = busy logs. [Med] I hear that you are for: s/DOTS gateway SHOULD remove the = diagnostic payload before/DOTS gateway MAY remove the diagnostic payload before. = Right? [Jon2] I feel a lot happier with MAY [Med] OK. =20 [Jon1] I would also like the structure of the diagnostic message to be = well formatted (e.g., no leading text, only one of server name / alias / IP address, blank separator etc.) so it can easily be documented in user manuals etc. as well as perhaps parsed by a receiver of the 5.06 message (interim hop or final destination). All other responses (albeit in = cbor) are pretty well documented. [Med] Isn=92t this covered in the above text? [Jon2] Dyslexia rules =96 I read =91prepend=92 as =91append=92 - sorry. = Prepending will do what I am looking for in part. [Med] Great!=20 [Jon2] However, adding in more than one of server name / alias / IP = address per hop might be a bit confusing when you =93count=94 the hops. [Med] This is exactly why the provided examples are not plural =93(e.g., server name, alias, IP address)=94. I agree that we can use a more = strict language. I can add this NEW sentence: =20 =93Only one information per DOTS gateway MUST appear in the diagnostic payload.=94 [Jon3] Yes please. ~jon3 ~Jon2 =20 =20 The initial hop-limit value SHOULD be configurable. If no initial value is explicitly provided, the default initial = hop-limit value of 16 MUST be used. =20 Because forwarding errors may occur if inadequate = hop-limit values are used, DOTS agents at the boundaries of an = administrative domain MAY be instructed to rewrite the value of hop-limit carried in received messages (that is, ignore the value of = hop-limit received in a message). =20 This is an optional option. [Jon] This should read =93This is an optional CoAP Option=94. =20 [Med] I can make the change. Please note that the text starts with =93A = DOTS gateway may add the following CoAP option=94 which is clear enough this = is about an optional CoAP option. =20 [Jon1] I guess I am being picky! ~jon1 Regards =20 Jon ------=_NextPart_000_00F6_01D3CC1B.51458450 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

This can be closed.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com
Sent: 28 March 2018 = 15:16
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] WGLC signal-18 Draft Hop Limit tidy = up

 

Jon,

 

RFC7252 does already mention the following : =

 

   If the Path MTU is not known = for a destination, an IP MTU of 1280

   bytes SHOULD be assumed; if = nothing is known about the size of the

   headers, good upper bounds = are 1152 bytes for the message size and

   1024 bytes for the payload = size.

 

We do already refer to that section in the draft. We = don’t need to call out again for this particular case. =

 

Thank you.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Envoy=E9 : mercredi 28 mars 2018 = 15:19
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : = RE: [Dots] WGLC signal-18 Draft Hop Limit tidy = up

 

Hi Med,

 

One thing that I earlier = commented on appears to have slipped through the net (and I missed = spotting it in your update)

 

“The diagnostic message length would need to be = restricted to something like 1000 bytes to prevent UDP = fragmentation.”

 

This could = be applied to all CoAP diagnostic messages (RFC7252 does not seem to = pick this up) or just to the hop-limit response (which could get = large).

 

Perhaps the text could read something = like:-

      = “Each intermediate DOTS

      gateway involved in = relaying a 5.06 (Hop Limit Reached) error

      message SHOULD prepend = its own information in the diagnostic

      payload with a space = character used as separator, subject to there being sufficient extra = space in the diagnostic payload so that the overall packet does not = exceed the IP MTU (RFC7252 4.6. Message Size) .”

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of mohamed.boucadair@orange.com=
Sent: 28 March 2018 12:58
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] WGLC signal-18 Draft Hop Limit tidy = up

 

Re-,

 

I confirm that I implemented the changes we agreed in = my local copy.

 

You may double check at: http= s://github.com/boucadair/draft-ietf-dots-signal-channel =

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Envoy=E9 : mercredi 28 mars 2018 = 11:38
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : = RE: [Dots] WGLC signal-18 Draft Hop Limit tidy = up

 

Hi Med,

 

See inline = [Jon3]

 

Regards

 

Jon

 

 

 

 

De : Dots [mailto:dots-bounces@ietf.org] = De la part de Jon Shallow
Envoy=E9 : vendredi 23 = mars 2018 16:35
=C0 : dots@ietf.org
Objet : = [Dots] WGLC signal-18 Draft Hop Limit tidy = up

 

Hi = there,

 

I believe that there are a couple of changes required = for the hop-limit definition – see [Jon] inline.

 

         &= nbsp; hop-limit:  This option (see Section 9.4) is used to detect = and

         &= nbsp;    prevent infinite loops.  This option is = typically inserted by a

         &= nbsp;    DOTS gateway.

 

         &= nbsp;    The length of the hop-limit option is 1 = byte.

 

         &= nbsp;    The value of the hop-limit option is encoded as = an unsigned

         &= nbsp;    integer (see Section 3.2 of = [RFC7252]).

 

         &= nbsp;    Each intermediate DOTS agent involved in the = handling of a DOTS

         &= nbsp;    message MUST decrement the hop-limit option = value by 1 prior to

         &= nbsp;    forwarding upstream if this parameter = exists.  DOTS messages MUST

         &= nbsp;    NOT be forwarded if the hop-limit option is set = to '0' after

         &= nbsp;    decrement.  Messages that cannot be = forwarded because of exhausted

         &= nbsp;    hop-limit SHOULD be logged with a 5.06 (Hop = Limit Reached) error

         &= nbsp;    message sent back to the DOTS peer.  It is = RECOMMENDED that DOTS

         &= nbsp;    clients and gateways support means to alert = administrators about

         &= nbsp;    loop errors so that appropriate actions are = undertaken.

[Jon] We need to add in = something like:-

Each intermediate = DOTS agent SHOULD add in the hop-limit option with the initial default = value if it does not exist before forwarding upstream any = information.

 

[Med] = I’m not sure to understand this one. Please note that the text = says “A DOTS gateway may add the following CoAP option”. = This is typically a GW which is instructed to insert the option will = inject the option and follows the setting of the initial = value.

 

[Jon1] I guess that I am = trying to differentiate between updating an existing Hop-Limit and not = injecting a new one alongside a previous one.  Having multiple = Hop-Limit options could get interesting!

[Med] OK, I get your point. What about adding : =

NEW:

 Only one single instance of the option is = allowed in a message.

[Jon2] Works for me

[Med] OK, thanks.

 

[Jon] We need to define the format of the 5.06 CoAP = diagnostic message so that it is potentially parseable by the DOTS = client as well as by any other potential RFC that make use of this 5.06 = code.  In addition, it would be good if each intermediate DOTS = agent appended its own IP (prefixed by a blank) to the end of the = diagnostic message as the 5.06 response gets passed back through the = DOST agents to enable troubleshooting at the DOTS client.  The = diagnostic message length would need to be restricted to something like = 1000 bytes to prevent UDP fragmentation.  Suggestions welcome = here.

 

[Med] I = can see a value in recording the list of GWs involved in a loop for = debugging purposes at the DOTS server domain, but I’m not sure = there is a value to pass that list to the DOTS client. For example, a = server domain may want to hide its internal topology (list of GWs and = servers involved in handling a mitigation request). Below a  text = proposal for discussion:

 

      To ease = debugging and troubleshooting, the DOTS gateway = which

      detects a = loop SHOULD include its information (e.g., server = name,

      alias, IP = address) in the diagnostic payload under the = conditions

      detailed in = Section 5.5.2 of [RFC7252].  Each intermediate = DOTS

      gateway = involved in relaying a 5.06 (Hop Limit Reached) = error

      message = SHOULD prepend its own information in the = diagnostic

      payload = with a space character used as separator.  The = ultimate

      DOTS = gateway SHOULD remove the diagnostic payload = before

      forwarding = the 5.06 (Hop Limit Reached) error message to a = DOTS

      = client domain.

[Jon1] I have no issues = if a server domain really wants to strip out its internal hops – = but troubleshooting is more of a challenge and would not recommend = it.

[Jon1] However, when setting up a DOTS client, = which is failing to work for whatever reason, it would be good to have a = reasonable level of diagnostics on the Client – separately = invoking someone to look at a DOTS server’s logs may take time =

to get responded to = – and you as a novice DOTS client user will have no idea as to = what to tell the DOTS server guy to look for in the server’s busy = logs.

[Med] I = hear that you are for: s/DOTS gateway SHOULD remove the diagnostic = payload before/DOTS gateway MAY remove the diagnostic payload before. = Right?

[Jon2] I feel a lot = happier with MAY

[Med] = OK.

 

[Jon1] I would also like the structure of the = diagnostic message to be well formatted (e.g., no leading text, only one = of server name / alias / IP address, blank separator etc.) so it can = easily be documented in user manuals etc. as well as perhaps parsed by a = receiver of the 5.06 message (interim hop or final destination). =  All other responses (albeit in cbor) are pretty well = documented.

[Med] = Isn’t this covered in the above text?

[Jon2] Dyslexia rules – I read = ‘prepend’ as ‘append’ - sorry.  Prepending = will do what I am looking for in part.

[Med] Great!

[Jon2] However, adding = in more than one of  server name / alias / IP address per hop might = be a bit confusing when you “count” the = hops.

[Med] = This is exactly why the provided examples are not plural “(e.g., = server name, alias, IP address)”. I agree that we can use a more strict = language. I can add this NEW sentence:  

“Only one information per DOTS gateway MUST = appear in the diagnostic payload.”

[Jon3] Yes please.

~jon3

~Jon2

 

 

         &= nbsp;    The initial hop-limit value SHOULD be = configurable.  If no initial

         &= nbsp;    value is explicitly provided, the default = initial hop-limit value

         &= nbsp;    of 16 MUST be used.

 

         &= nbsp;    Because forwarding errors may occur if = inadequate hop-limit values

         &= nbsp;    are used, DOTS agents at the boundaries of an = administrative

          =     domain MAY be instructed to rewrite the value of = hop-limit carried

         &= nbsp;    in received messages (that is, ignore the value = of hop-limit

         &= nbsp;    received in a message).

 

         &= nbsp;    This is an optional option.

[Jon] This should read “This is an optional CoAP = Option”.

 

[Med] I can make the change. Please note that the text = starts with “A DOTS gateway may add the following = CoAP option” = which is clear enough this is about an optional CoAP = option.

 

[Jon1] I guess I am = being picky!

~jon1

Regards

 

Jon

<= /body> ------=_NextPart_000_00F6_01D3CC1B.51458450-- From nobody Wed Apr 4 05:56:08 2018 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 57CCC128896 for ; Wed, 4 Apr 2018 05:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BTSbDZ6f8OoQ for ; Wed, 4 Apr 2018 05:56:02 -0700 (PDT) Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 659F812741D for ; Wed, 4 Apr 2018 05:56:02 -0700 (PDT) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 0ECA61609A4; Wed, 4 Apr 2018 14:56:01 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.13]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id E72EE80073; Wed, 4 Apr 2018 14:56:00 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6D.corporate.adroot.infra.ftgroup ([fe80::54f9:a6c3:c013:cbc7%19]) with mapi id 14.03.0382.000; Wed, 4 Apr 2018 14:56:00 +0200 From: To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] WGLC signal-18 Draft Hop Limit tidy up Thread-Index: AQLZExA96e11tdoJyqOqcaxu1U7VtQIUMridAPIe3SYBQh+XjQFy2griAn3xOeQCNYLpVgIv3jouAUgX1jkB7g8ay6FnWW1wgAACq3A= Date: Wed, 4 Apr 2018 12:56:00 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DEF7D8F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <05c801d3c2bc$88171290$984537b0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF10B4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <018701d3c5c8$044db950$0ce92bf0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF3579@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <01d001d3c5de$410e3ca0$c32ab5e0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF3B49@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <026a01d3c678$6bb62270$43226750$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF3CE9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <02ed01d3c697$5de338d0$19a9aa70$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF3F98@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <00f501d3cc12$ef7de800$ce79b800$@jpshallow.com> In-Reply-To: <00f501d3cc12$ef7de800$ce79b800$@jpshallow.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93302DEF7D8FOPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] WGLC signal-18 Draft Hop Limit tidy up 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: Wed, 04 Apr 2018 12:56:06 -0000 --_000_787AE7BB302AE849A7480A190F8B93302DEF7D8FOPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ACked, Jon. Thank you. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mercredi 4 avril 2018 14:46 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: [Dots] WGLC signal-18 Draft Hop Limit tidy up This can be closed. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 28 March 2018 15:16 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] WGLC signal-18 Draft Hop Limit tidy up Jon, RFC7252 does already mention the following : If the Path MTU is not known for a destination, an IP MTU of 1280 bytes SHOULD be assumed; if nothing is known about the size of the headers, good upper bounds are 1152 bytes for the message size and 1024 bytes for the payload size. We do already refer to that section in the draft. We don't need to call out= again for this particular case. Thank you. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mercredi 28 mars 2018 15:19 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: [Dots] WGLC signal-18 Draft Hop Limit tidy up Hi Med, One thing that I earlier commented on appears to have slipped through the n= et (and I missed spotting it in your update) "The diagnostic message length would need to be restricted to something lik= e 1000 bytes to prevent UDP fragmentation." This could be applied to all CoAP diagnostic messages (RFC7252 does not see= m to pick this up) or just to the hop-limit response (which could get large= ). Perhaps the text could read something like:- "Each intermediate DOTS gateway involved in relaying a 5.06 (Hop Limit Reached) error message SHOULD prepend its own information in the diagnostic payload with a space character used as separator, subject to there be= ing sufficient extra space in the diagnostic payload so that the overall pa= cket does not exceed the IP MTU (RFC7252 4.6. Message Size) ." Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 28 March 2018 12:58 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] WGLC signal-18 Draft Hop Limit tidy up Re-, I confirm that I implemented the changes we agreed in my local copy. You may double check at: https://github.com/boucadair/draft-ietf-dots-signa= l-channel Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mercredi 28 mars 2018 11:38 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: [Dots] WGLC signal-18 Draft Hop Limit tidy up Hi Med, See inline [Jon3] Regards Jon De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : vendredi 23 mars 2018 16:35 =C0 : dots@ietf.org Objet : [Dots] WGLC signal-18 Draft Hop Limit tidy up Hi there, I believe that there are a couple of changes required for the hop-limit def= inition - see [Jon] inline. hop-limit: This option (see Section 9.4) is used to detect and prevent infinite loops. This option is typically inserted by= a DOTS gateway. The length of the hop-limit option is 1 byte. The value of the hop-limit option is encoded as an unsigned integer (see Section 3.2 of [RFC7252]). Each intermediate DOTS agent involved in the handling of a DO= TS message MUST decrement the hop-limit option value by 1 prior = to forwarding upstream if this parameter exists. DOTS messages = MUST NOT be forwarded if the hop-limit option is set to '0' after decrement. Messages that cannot be forwarded because of exha= usted hop-limit SHOULD be logged with a 5.06 (Hop Limit Reached) er= ror message sent back to the DOTS peer. It is RECOMMENDED that D= OTS clients and gateways support means to alert administrators ab= out loop errors so that appropriate actions are undertaken. [Jon] We need to add in something like:- Each intermediate DOTS agent SHOULD add in the hop-limit option with the in= itial default value if it does not exist before forwarding upstream any inf= ormation. [Med] I'm not sure to understand this one. Please note that the text says "= A DOTS gateway may add the following CoAP option". This is typically a GW w= hich is instructed to insert the option will inject the option and follows = the setting of the initial value. [Jon1] I guess that I am trying to differentiate between updating an existi= ng Hop-Limit and not injecting a new one alongside a previous one. Having = multiple Hop-Limit options could get interesting! [Med] OK, I get your point. What about adding : NEW: Only one single instance of the option is allowed in a message. [Jon2] Works for me [Med] OK, thanks. [Jon] We need to define the format of the 5.06 CoAP diagnostic message so t= hat it is potentially parseable by the DOTS client as well as by any other = potential RFC that make use of this 5.06 code. In addition, it would be go= od if each intermediate DOTS agent appended its own IP (prefixed by a blank= ) to the end of the diagnostic message as the 5.06 response gets passed bac= k through the DOST agents to enable troubleshooting at the DOTS client. Th= e diagnostic message length would need to be restricted to something like 1= 000 bytes to prevent UDP fragmentation. Suggestions welcome here. [Med] I can see a value in recording the list of GWs involved in a loop for= debugging purposes at the DOTS server domain, but I'm not sure there is a = value to pass that list to the DOTS client. For example, a server domain ma= y want to hide its internal topology (list of GWs and servers involved in h= andling a mitigation request). Below a text proposal for discussion: To ease debugging and troubleshooting, the DOTS gateway which detects a loop SHOULD include its information (e.g., server name, alias, IP address) in the diagnostic payload under the conditions detailed in Section 5.5.2 of [RFC7252]. Each intermediate DOTS gateway involved in relaying a 5.06 (Hop Limit Reached) error message SHOULD prepend its own information in the diagnostic payload with a space character used as separator. The ultimate DOTS gateway SHOULD remove the diagnostic payload before forwarding the 5.06 (Hop Limit Reached) error message to a DOTS client domain. [Jon1] I have no issues if a server domain really wants to strip out its in= ternal hops - but troubleshooting is more of a challenge and would not reco= mmend it. [Jon1] However, when setting up a DOTS client, which is failing to work for= whatever reason, it would be good to have a reasonable level of diagnostic= s on the Client - separately invoking someone to look at a DOTS server's lo= gs may take time to get responded to - and you as a novice DOTS client user will have no ide= a as to what to tell the DOTS server guy to look for in the server's busy l= ogs. [Med] I hear that you are for: s/DOTS gateway SHOULD remove the diagnostic = payload before/DOTS gateway MAY remove the diagnostic payload before. Right= ? [Jon2] I feel a lot happier with MAY [Med] OK. [Jon1] I would also like the structure of the diagnostic message to be well= formatted (e.g., no leading text, only one of server name / alias / IP add= ress, blank separator etc.) so it can easily be documented in user manuals = etc. as well as perhaps parsed by a receiver of the 5.06 message (interim h= op or final destination). All other responses (albeit in cbor) are pretty = well documented. [Med] Isn't this covered in the above text? [Jon2] Dyslexia rules - I read 'prepend' as 'append' - sorry. Prepending w= ill do what I am looking for in part. [Med] Great! [Jon2] However, adding in more than one of server name / alias / IP addres= s per hop might be a bit confusing when you "count" the hops. [Med] This is exactly why the provided examples are not plural "(e.g., serv= er name, alias, IP address)". I agree that we can use a more strict languag= e. I can add this NEW sentence: "Only one information per DOTS gateway MUST appear in the diagnostic payloa= d." [Jon3] Yes please. ~jon3 ~Jon2 The initial hop-limit value SHOULD be configurable. If no in= itial value is explicitly provided, the default initial hop-limit v= alue of 16 MUST be used. Because forwarding errors may occur if inadequate hop-limit v= alues are used, DOTS agents at the boundaries of an administrative domain MAY be instructed to rewrite the value of hop-limit ca= rried in received messages (that is, ignore the value of hop-limit received in a message). This is an optional option. [Jon] This should read "This is an optional CoAP Option". [Med] I can make the change. Please note that the text starts with "A DOTS = gateway may add the following CoAP option" which is clear enough this is ab= out an optional CoAP option. [Jon1] I guess I am being picky! ~jon1 Regards Jon --_000_787AE7BB302AE849A7480A190F8B93302DEF7D8FOPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

ACked, Jon.

 

Thank you.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf= @jpshallow.com]
Envoy=E9 : mercredi 4 avril 2018 14:46
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: [Dots] WGLC signal-18 Draft Hop Limit tidy up<= /o:p>

 

This ca= n be closed.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 28 March 2018 15:16
To: Jon Shallow; dots@ietf.org<= br> Subject: Re: [Dots] WGLC signal-18 Draft Hop Limit tidy up

 

Jon,

 

RFC7252 does already mention th= e following :

 

   If the= Path MTU is not known for a destination, an IP MTU of 1280

   bytes = SHOULD be assumed; if nothing is known about the size of the

   header= s, good upper bounds are 1152 bytes for the message size and

   1024 b= ytes for the payload size.

 

We do already refer to that sec= tion in the draft. We don’t need to call out again for this particula= r case.

 

Thank you.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : mercredi 28 mars 2018 15:19
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: [Dots] WGLC signal-18 Draft Hop Limit tidy up<= /o:p>

 

Hi Med,=

&n= bsp;

One thi= ng that I earlier commented on appears to have slipped through the net (and= I missed spotting it in your update)

&n= bsp;

“The diagnostic message l= ength would need to be restricted to something like 1000 bytes to prevent U= DP fragmentation.”

 

This could be applied to all Co= AP diagnostic messages (RFC7252 does not seem to pick this up) or just to t= he hop-limit response (which could get large).

 

Perhaps the text could read som= ething like:-

      = “Each intermediate DOTS

      = gateway involved in relaying a 5.06 (Hop Limit Reached) error

      = message SHOULD prepend its own information in the diagnostic

      = payload with a space character used as separator, subject to there being su= fficient extra space in the diagnostic payload so that the overall packet d= oes not exceed the IP MTU (RFC7252 4.6. Message Size) .”

 

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 28 March 2018 12:58
To: Jon Shallow; dots@ietf.org<= br> Subject: Re: [Dots] WGLC signal-18 Draft Hop Limit tidy up

 

Re-,

 

I confirm that I implemented th= e changes we agreed in my local copy.

 

You may double check at: htt= ps://github.com/boucadair/draft-ietf-dots-signal-channel

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : mercredi 28 mars 2018 11:38
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: [Dots] WGLC signal-18 Draft Hop Limit tidy up<= /o:p>

 

Hi Med,=

&n= bsp;

See inl= ine [Jon3]

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

&n= bsp;

&n= bsp;

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow
Envoy=E9 : vendredi 23 mars 2018 16:35
=C0 : dots@ietf.org
Objet : [Dots] WGLC signal-18 Draft Hop Limit tidy up

 

Hi there,

 

I believe that there are a coup= le of changes required for the hop-limit definition – see [Jon] inlin= e.

 

     &= nbsp;     hop-limit:  This option (see Section 9.4= ) is used to detect and

     &= nbsp;        prevent infinite loops.&nbs= p; This option is typically inserted by a

     &= nbsp;        DOTS gateway.

 

     &= nbsp;        The length of the hop-limit= option is 1 byte.

 

     &= nbsp;        The value of the hop-limit = option is encoded as an unsigned

     &= nbsp;        integer (see Section 3.2 of= [RFC7252]).

 

     &= nbsp;        Each intermediate DOTS agen= t involved in the handling of a DOTS

     &= nbsp;        message MUST decrement the = hop-limit option value by 1 prior to

     &= nbsp;        forwarding upstream if this= parameter exists.  DOTS messages MUST

     &= nbsp;        NOT be forwarded if the hop= -limit option is set to '0' after

     &= nbsp;        decrement.  Messages t= hat cannot be forwarded because of exhausted

     &= nbsp;        hop-limit SHOULD be logged = with a 5.06 (Hop Limit Reached) error

     &= nbsp;        message sent back to the DO= TS peer.  It is RECOMMENDED that DOTS

     &= nbsp;        clients and gateways suppor= t means to alert administrators about

     &= nbsp;        loop errors so that appropr= iate actions are undertaken.

[Jon] We need to add in somethi= ng like:-

Each intermediate DOTS agent SH= OULD add in the hop-limit option with the initial default value if it does = not exist before forwarding upstream any information.

 

[Med] I’m not sure to und= erstand this one. Please note that the text says “A DOTS gateway may = add the following CoAP option”. This is typically a GW which is instructed to insert the option will inject the option and follows the = setting of the initial value.

&n= bsp;

[Jon1] = I guess that I am trying to differentiate between updating an existing Hop-= Limit and not injecting a new one alongside a previous one.  Having mu= ltiple Hop-Limit options could get interesting!

[Med] OK, I get your point. Wha= t about adding :

NEW:

 Only one single instance = of the option is allowed in a message.

[Jon2] = Works for me

[Med] OK, thanks.

&n= bsp;

[Jon] We need to define the for= mat of the 5.06 CoAP diagnostic message so that it is potentially parseable= by the DOTS client as well as by any other potential RFC that make use of = this 5.06 code.  In addition, it would be good if each intermediate DOTS agent appended its own IP (prefixed by a= blank) to the end of the diagnostic message as the 5.06 response gets pass= ed back through the DOST agents to enable troubleshooting at the DOTS clien= t.  The diagnostic message length would need to be restricted to something like 1000 bytes to prevent UDP fr= agmentation.  Suggestions welcome here.

 

[Med] I can see a value in reco= rding the list of GWs involved in a loop for debugging purposes at the DOTS= server domain, but I’m not sure there is a value to pass that list to the DOTS client. For example, a server domain may wan= t to hide its internal topology (list of GWs and servers involved in handli= ng a mitigation request). Below a  text proposal for discussion:<= /o:p>

 

   &= nbsp;  To ease debugging and troubleshooting, the DOTS gateway which

   &= nbsp;  detects a loop SHOULD include its information (e.g., server nam= e,

   &= nbsp;  alias, IP address) in the diagnostic payload under the conditio= ns

   &= nbsp;  detailed in Section 5.5.2 of [RFC7252].  Each intermediate= DOTS

   &= nbsp;  gateway involved in relaying a 5.06 (Hop Limit Reached) error

   &= nbsp;  message SHOULD prepend its own information in the diagnostic

   &= nbsp;  payload with a space character used as separator.  The ult= imate

   &= nbsp;  DOTS gateway SHOULD remove the diagnostic payload before

   &= nbsp;  forwarding the 5.06 (Hop Limit Reached) error message to a DOTS=

   &= nbsp;  client domain.

[Jon1] = I have no issues if a server domain really wants to strip out its internal = hops – but troubleshooting is more of a challenge and would not recom= mend it.

[Jon1] = However, when setting up a DOTS client, which is failing to work for whatev= er reason, it would be good to have a reasonable level of diagnostics on th= e Client – separately invoking someone to look at a DOTS server’s logs may take time

to get = responded to – and you as a novice DOTS client user will have no idea= as to what to tell the DOTS server guy to look for in the server’s b= usy logs.

[Med] I hear that you are for: = s/DOTS gateway SHOULD remove the diagnostic payload before/DOTS gateway MAY remove the diagnosti= c payload before. Right?

[Jon2] = I feel a lot happier with MAY

[Med] OK.

 

[Jon1] = I would also like the structure of the diagnostic message to be well format= ted (e.g., no leading text, only one of server name / alias / IP address, b= lank separator etc.) so it can easily be documented in user manuals etc. as well as perhaps parsed by a receiver= of the 5.06 message (interim hop or final destination).  All other re= sponses (albeit in cbor) are pretty well documented.

[Med] Isn’t this covered = in the above text?

[Jon2] = Dyslexia rules – I read ‘prepend’ as ‘append’= - sorry.  Prepending will do what I am looking for in part.

[Med] Great!

[Jon2] = However, adding in more than one of  server name / alias / IP address = per hop might be a bit confusing when you “count” the hops.

[Med] This is exactly why the p= rovided examples are not plural “(e.g., server name, alias, IP address)”. I agree that we can use a more strict language. I can add this NEW sentence:  

“Only one information per= DOTS gateway MUST appear in the diagnostic payload.”

[Jon3] = Yes please.

~jon3

~Jon2

 

&nbs= p;

     &= nbsp;        The initial hop-limit value= SHOULD be configurable.  If no initial

     &= nbsp;        value is explicitly provide= d, the default initial hop-limit value

     &= nbsp;        of 16 MUST be used.

 

     &= nbsp;        Because forwarding errors m= ay occur if inadequate hop-limit values

     &= nbsp;        are used, DOTS agents at th= e boundaries of an administrative

     &= nbsp;        domain MAY be instructed to= rewrite the value of hop-limit carried

     &= nbsp;        in received messages (that = is, ignore the value of hop-limit

     &= nbsp;        received in a message).

 

     &= nbsp;        This is an optional option.=

[Jon] This should read “T= his is an optional CoAP Option”.

&nbs= p;

[Med] I can make the change. Pl= ease note that the text starts with “A DOTS gateway may add the follo= wing CoAP option” which is clear enough this is about an optional CoAP option.

&n= bsp;

[Jon1] = I guess I am being picky!

~jon1

Regards

 

Jon

--_000_787AE7BB302AE849A7480A190F8B93302DEF7D8FOPEXCLILMA3corp_-- From nobody Wed Apr 4 05:59:04 2018 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 365E4128896 for ; Wed, 4 Apr 2018 05:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 yCDbhWRAjGnT for ; Wed, 4 Apr 2018 05:58:54 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 974DF127333 for ; Wed, 4 Apr 2018 05:58:53 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id x4so42197531wmh.5 for ; Wed, 04 Apr 2018 05:58:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=2EkjJe3n1JEDjSXgRRYxvPbp6y+oSKnFNJ/a2iVfVm0=; b=AtUl0YGKFkWB4XlWaRg6zv2wKitstRsT6EcCtMZSWWuTA9M30AQHj3pw1/8QntmqaA iv4LgvAr8BznIYJpo7hV9/UnDJvI2MKbDrXO9GbsZpOyafpq0d4mFP34GZU/bJE08qAx PYhJNIdtOQt/mKxj1yTeVXjM56Y47C9bLsdtP3Y8AGXuL1jeUQeX3oHNvvwyKRXUu4Y7 AMa+cMJrsH2nm01n6EhbZCrHAidxSHlvUZmXxCdduyhCdVXte54ViUKP9YtxoFhhzUG7 kRoCZKUv54n0ODLyAdDyQGosUd52aIbQr6TCI9HQeXw6R69Wh1kVh00YIYFJh+DFfYsY pHOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=2EkjJe3n1JEDjSXgRRYxvPbp6y+oSKnFNJ/a2iVfVm0=; b=Y51DJjKLrVsonFvYNia3dvTGY3WkUwBhmLMR1Z9QWtgn/A42437CVnX6nY7EoDMROy ENyqzU5vFvSLz/QTDBVBNmV42L/5XSajYhDDD9UoeNKK/JVRkicCkTnbCxDuqMz72m7C 608xlLLAja9AoTo3j9iVjOuMD3MAp9LpoBKpnHHhPKs2nfggXTMWhtuL5XlVaJDv1+Au od6hO5c89ZrmuGjf2HHyVDZoX4hcJPaXg8Em7YIXYOPq4qb4Ee+lSwnAcL2DyWttQd6O pXHKZkjkbMESkwbVXALR55vlu1oBynHLcVK3peKisNFd1h3mDP7IGavoFdQglT8HTq4Y MZUA== X-Gm-Message-State: AElRT7Hol7+h5Jg83jg8ENkYEK4/bnPG3YowUW5s7JVZ94Mf+N4SSKsq uFz3WS+y7lWhmnAocvsqN7V0bQUMYfziJd9ud4c= X-Google-Smtp-Source: AIpwx49JV6XRBgqOlqGsgHeSWqqxa1rZlIwfb6YSWTBPDpmz3goaXJXYAWnpCVsUotFpCF7tZ3982unj2Hl4Rxq1CB4= X-Received: by 10.46.32.154 with SMTP id g26mr11339781lji.71.1522846732097; Wed, 04 Apr 2018 05:58:52 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.130.68 with HTTP; Wed, 4 Apr 2018 05:58:51 -0700 (PDT) In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DEF7ADE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <152224582267.29792.2214827071198414612.idtracker@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C118E01184@eusaamb107.ericsson.se> <787AE7BB302AE849A7480A190F8B93302DEF7ADE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Daniel Migault Date: Wed, 4 Apr 2018 08:58:51 -0400 X-Google-Sender-Auth: XgO3FFYakt5Buakt4lyv60SSsc0 Message-ID: To: mohamed.boucadair@orange.com Cc: "dots@ietf.org" Content-Type: multipart/alternative; boundary="001a1143062a839c1505690562c1" Archived-At: Subject: Re: [Dots] New Version Notification for draft-ietf-dots-use-cases-11.txt 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: Wed, 04 Apr 2018 12:58:59 -0000 --001a1143062a839c1505690562c1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you Mohamed for the comments. We will address your comments on the next version. I have a small clarification regarding comment 7 on figure 2. I understand the figure is misleading as the figure seems to indicate a dedicated link between the DDoS target and the DMS. In the next version I am planning to have a figure when that specific communication goes though the transit provider. I think that would address your concern, but if not, please let me know. Yours, Daniel On Wed, Apr 4, 2018 at 4:42 AM, wrote: > Hi Daniel, all, > > FWIW, you may find some comments to the -11 at: > > PDF: https://github.com/boucadair/IETF-Drafts-Reviews/blob/ > master/draft-ietf-dots-use-cases-11-rev%20Med.pdf > DOC: https://github.com/boucadair/IETF-Drafts-Reviews/raw/ > master/draft-ietf-dots-use-cases-11-rev%20Med.doc > > Cheers, > Med > > > -----Message d'origine----- > > De : Dots [mailto:dots-bounces@ietf.org] De la part de Daniel Migault > > Envoy=C3=A9 : mercredi 28 mars 2018 16:24 > > =C3=80 : dots@ietf.org > > Objet : [Dots] FW: New Version Notification for > draft-ietf-dots-use-cases- > > 11.txt > > > > Hi everyone! > > > > Please find the draft-ietf-dots-use-cases-11 [1]. In order to meet the > > aggressive schedule agreed during the session in London, we would great= ly > > appreciate your feed backs by the end of the week ! > > > > The current document is limited to 3 use cases described over 10ish > pages.. We > > believe the current document addresses the feed backs and comments we > > received from the London session. If you believe otherwise, feel free t= o > > bring this on the mailing list. > > > > We expect to publish version 12 on Tuesday April 3. This version is > expected > > to address the received comments and be ready to WGLC. > > > > Comments can be addressed directly to the mailing list or using github > pull > > requests on the mkd version [2]. If you believe some discussions are > needed, > > please consider discussing those on the mailing list. > > > > Yours, > > Daniel > > [1] https://datatracker.ietf.org/doc/draft-ietf-dots-use-cases/ > > [2] https://github.com/dotswg/dots-use-cases/blob/master/ > draft-ietf-dots- > > use-cases.mkd > > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Wednesday, March 28, 2018 10:04 AM > > To: Kaname Nishizuka ; Nik Teague >; > > Daniel Migault ; Robert Moskowitz > > consult.com>; Stefan Fouant ; dots- > > chairs@ietf.org; Roland Dobbins ; Liang Xia > > ; Liang Xia > > Subject: New Version Notification for draft-ietf-dots-use-cases-11.txt > > > > > > A new version of I-D, draft-ietf-dots-use-cases-11.txt has been > successfully > > submitted by Daniel Migault and posted to the IETF repository. > > > > Name: draft-ietf-dots-use-cases > > Revision: 11 > > Title: Use cases for DDoS Open Threat Signaling > > Document date: 2018-03-28 > > Group: dots > > Pages: 14 > > URL: https://www.ietf.org/internet- > drafts/draft-ietf-dots-use- > > cases-11.txt > > Status: https://datatracker.ietf.org/ > doc/draft-ietf-dots-use-cases/ > > Htmlized: https://tools.ietf.org/html/draft-ietf-dots-use-cases-1= 1 > > Htmlized: https://datatracker.ietf.org/ > doc/html/draft-ietf-dots-use- > > cases > > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-use= - > cases- > > 11 > > > > Abstract: > > The DDoS Open Threat Signaling (DOTS) effort is intended to provide = a > > protocol to facilitate interoperability across disparate DDoS > > mitigation solutions and services. This document presents use cases > > which describe the interactions expected between the DOTS components > > as well as DOTS messaging exchanges. The purpose of describing use > > cases is to identify the interacting DOTS components, how they > > collaborate and what are the types of information to be exchanged. > > > > > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > The IETF Secretariat > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > --001a1143062a839c1505690562c1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you Mohamed for the comments. We will addr= ess your comments on the next version. I have a small clarification regardi= ng comment 7 on figure 2. I understand the figure is misleading as the figu= re seems to indicate a dedicated link between the DDoS target and the DMS. = In the next version I am planning to have a figure when that specific commu= nication goes though the transit provider. I think that would address your = concern, but if not, please let me know.

Yours,
Dan= iel

On = Wed, Apr 4, 2018 at 4:42 AM, <mohamed.boucadair@orange.com= > wrote:
Hi Daniel, all,

FWIW, you may find some comments to the -11 at:

PDF: https://github.com/boucadair/IETF-Drafts-Reviews/blob/mas= ter/draft-ietf-dots-use-cases-11-rev%20Med.pdf
DOC: https://github.com/boucadair/IETF-Drafts-Reviews/raw/maste= r/draft-ietf-dots-use-cases-11-rev%20Med.doc

Cheers,
Med

> -----Message d'origine-----
> De=C2=A0: Dots [mailto:dots-b= ounces@ietf.org] De la part de Daniel Migault
> Envoy=C3=A9=C2=A0: mercredi 28 mars 2018 16:24
> =C3=80=C2=A0: dots@ietf.org
> Objet=C2=A0: [Dots] FW: New Version Notification for draft-ietf-dots-u= se-cases-
> 11.txt
>
> Hi everyone!
>
> Please find the draft-ietf-dots-use-cases-11 [1]. In order to meet the=
> aggressive schedule agreed during the session in London, we would grea= tly
> appreciate your feed backs by the end of the week !
>
> The current document is limited to 3 use cases described over 1= 0ish pages.. We
> believe the current document a= ddresses the feed backs and comments we
> received from the London session. If you believe otherwise, feel free = to
> bring this on the mailing list.
>
> We expect to publish version 12 on Tuesday April 3. This version is ex= pected
> to address the received comments and be ready to WGLC.
>
> Comments can be addressed directly to the mailing list or using github= pull
> requests on the mkd version [2]. If you believe some discussions are n= eeded,
> please consider discussing those on the mailing list.
>
> Yours,
> Daniel
> [1] https://datatracker.ietf.org/doc/draft-ietf-dots-use-cases/
> [2]=C2=A0 https://github.c= om/dotswg/dots-use-cases/blob/master/draft-ietf-dots-
> use-cases.mkd
>
> -----Original Message-----
> From: internet-drafts@ietf= .org [mailto:internet-draft= s@ietf.org]
> Sent: Wednesday, March 28, 2018 10:04 AM
> To: Kaname Nishizuka <kaname@ntt= v6.jp>; Nik Teague <nteag= ue@verisign.com>;
> Daniel Migault <dani= el.migault@ericsson.com>; Robert Moskowitz <rgm@labs.htt-
> co= nsult.com>; Stefan Fouant <stefan.fouant@copperriverit.com>; dots-
> chairs@ietf.org; Roland Dobbins= <rdobbins@arbor.net>; Lian= g Xia
> <frank.xialiang@huawei= .com>; Liang Xia <Fr= ank.xialiang@huawei.com>
> Subject: New Version Notification for draft-ietf-dots-use-cases-11.txt
>
>
> A new version of I-D, draft-ietf-dots-use-cases-11.txt has been s= uccessfully
> submitted by Daniel Migault and posted to the IETF repository.
>
> Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-dots-use-cases
> Revision:=C2=A0 =C2=A0 =C2=A011
> Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Use case= s for DDoS Open Threat Signaling
> Document date:=C2=A0 =C2=A0 =C2=A0 =C2=A0 2018-03-28
> Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 dots
> Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 14
> URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-ietf-dots-use-<= br> > cases-11.txt
> Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-ietf-dots-use-cases/ > Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0htt= ps://tools.ietf.org/html/draft-ietf-dots-use-cases-11
> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0h= ttps://datatracker.ietf.org/doc/html/draft-ietf-dots-use-
> cases
> Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-use-<= wbr>cases-
> 11
>
> Abstract:
>=C2=A0 =C2=A0 The DDoS Open Threat Signaling (DOTS) effort is intended = to provide a
>=C2=A0 =C2=A0 protocol to facilitate interoperability across disparate = DDoS
>=C2=A0 =C2=A0 mitigation solutions and services.=C2=A0 This document pr= esents use cases
>=C2=A0 =C2=A0 which describe the interactions expected between the DOTS= components
>=C2=A0 =C2=A0 as well as DOTS messaging exchanges.=C2=A0 The purpose of= describing use
>=C2=A0 =C2=A0 cases is to identify the interacting DOTS components, how= they
>=C2=A0 =C2=A0 collaborate and what are the types of information to be e= xchanged.
>
>
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org. >
> The IETF Secretariat
>
> _______________________________________________
> Dots mailing list
> Dots@ietf.org
> https://www.ietf.org/mailman/listinfo/dots
_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots

--001a1143062a839c1505690562c1-- From nobody Wed Apr 4 06:24:52 2018 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 2113412762F for ; Wed, 4 Apr 2018 06:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L_fuMAK30YDS for ; Wed, 4 Apr 2018 06:24:48 -0700 (PDT) Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C16561204DA for ; Wed, 4 Apr 2018 06:24:47 -0700 (PDT) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id EB2371804A9; Wed, 4 Apr 2018 15:24:45 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.42]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id C3E551C00A7; Wed, 4 Apr 2018 15:24:45 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM41.corporate.adroot.infra.ftgroup ([fe80::c845:f762:8997:ec86%19]) with mapi id 14.03.0382.000; Wed, 4 Apr 2018 15:24:45 +0200 From: To: Daniel Migault CC: "dots@ietf.org" Thread-Topic: [Dots] New Version Notification for draft-ietf-dots-use-cases-11.txt Thread-Index: AQHTzBSw0YZBtJOhsUCg3yDnkmCXAKPwmCuA Date: Wed, 4 Apr 2018 13:24:44 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DEF7DEE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <152224582267.29792.2214827071198414612.idtracker@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C118E01184@eusaamb107.ericsson.se> <787AE7BB302AE849A7480A190F8B93302DEF7ADE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93302DEF7DEEOPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] New Version Notification for draft-ietf-dots-use-cases-11.txt 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: Wed, 04 Apr 2018 13:24:51 -0000 --_000_787AE7BB302AE849A7480A190F8B93302DEF7DEEOPEXCLILMA3corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGFuaWVsLA0KDQpTb3VuZHMgbGlrZSBhIGdvb2QgcGxhbi4gVGhhbmtzLg0KDQpDaGVlcnMsDQpN ZWQNCg0KRGUgOiBtZ2x0LmlldGZAZ21haWwuY29tIFttYWlsdG86bWdsdC5pZXRmQGdtYWlsLmNv bV0gRGUgbGEgcGFydCBkZSBEYW5pZWwgTWlnYXVsdA0KRW52b3nDqSA6IG1lcmNyZWRpIDQgYXZy aWwgMjAxOCAxNDo1OQ0Kw4AgOiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xODQpDYyA6IGRvdHNA aWV0Zi5vcmcNCk9iamV0IDogUmU6IFtEb3RzXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y IGRyYWZ0LWlldGYtZG90cy11c2UtY2FzZXMtMTEudHh0DQoNClRoYW5rIHlvdSBNb2hhbWVkIGZv ciB0aGUgY29tbWVudHMuIFdlIHdpbGwgYWRkcmVzcyB5b3VyIGNvbW1lbnRzIG9uIHRoZSBuZXh0 IHZlcnNpb24uIEkgaGF2ZSBhIHNtYWxsIGNsYXJpZmljYXRpb24gcmVnYXJkaW5nIGNvbW1lbnQg NyBvbiBmaWd1cmUgMi4gSSB1bmRlcnN0YW5kIHRoZSBmaWd1cmUgaXMgbWlzbGVhZGluZyBhcyB0 aGUgZmlndXJlIHNlZW1zIHRvIGluZGljYXRlIGEgZGVkaWNhdGVkIGxpbmsgYmV0d2VlbiB0aGUg RERvUyB0YXJnZXQgYW5kIHRoZSBETVMuIEluIHRoZSBuZXh0IHZlcnNpb24gSSBhbSBwbGFubmlu ZyB0byBoYXZlIGEgZmlndXJlIHdoZW4gdGhhdCBzcGVjaWZpYyBjb21tdW5pY2F0aW9uIGdvZXMg dGhvdWdoIHRoZSB0cmFuc2l0IHByb3ZpZGVyLiBJIHRoaW5rIHRoYXQgd291bGQgYWRkcmVzcyB5 b3VyIGNvbmNlcm4sIGJ1dCBpZiBub3QsIHBsZWFzZSBsZXQgbWUga25vdy4NCllvdXJzLA0KRGFu aWVsDQoNCk9uIFdlZCwgQXByIDQsIDIwMTggYXQgNDo0MiBBTSwgPG1vaGFtZWQuYm91Y2FkYWly QG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+PiB3cm90ZToN CkhpIERhbmllbCwgYWxsLA0KDQpGV0lXLCB5b3UgbWF5IGZpbmQgc29tZSBjb21tZW50cyB0byB0 aGUgLTExIGF0Og0KDQpQREY6IGh0dHBzOi8vZ2l0aHViLmNvbS9ib3VjYWRhaXIvSUVURi1EcmFm dHMtUmV2aWV3cy9ibG9iL21hc3Rlci9kcmFmdC1pZXRmLWRvdHMtdXNlLWNhc2VzLTExLXJldiUy ME1lZC5wZGYNCkRPQzogaHR0cHM6Ly9naXRodWIuY29tL2JvdWNhZGFpci9JRVRGLURyYWZ0cy1S ZXZpZXdzL3Jhdy9tYXN0ZXIvZHJhZnQtaWV0Zi1kb3RzLXVzZS1jYXNlcy0xMS1yZXYlMjBNZWQu ZG9jDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBE ZSA6IERvdHMgW21haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmRvdHMtYm91bmNl c0BpZXRmLm9yZz5dIERlIGxhIHBhcnQgZGUgRGFuaWVsIE1pZ2F1bHQNCj4gRW52b3nDqSA6IG1l cmNyZWRpIDI4IG1hcnMgMjAxOCAxNjoyNA0KPiDDgCA6IGRvdHNAaWV0Zi5vcmc8bWFpbHRvOmRv dHNAaWV0Zi5vcmc+DQo+IE9iamV0IDogW0RvdHNdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LWlldGYtZG90cy11c2UtY2FzZXMtDQo+IDExLnR4dA0KPg0KPiBIaSBldmVy eW9uZSENCj4NCj4gUGxlYXNlIGZpbmQgdGhlIGRyYWZ0LWlldGYtZG90cy11c2UtY2FzZXMtMTEg WzFdLiBJbiBvcmRlciB0byBtZWV0IHRoZQ0KPiBhZ2dyZXNzaXZlIHNjaGVkdWxlIGFncmVlZCBk dXJpbmcgdGhlIHNlc3Npb24gaW4gTG9uZG9uLCB3ZSB3b3VsZCBncmVhdGx5DQo+IGFwcHJlY2lh dGUgeW91ciBmZWVkIGJhY2tzIGJ5IHRoZSBlbmQgb2YgdGhlIHdlZWsgIQ0KPg0KPiBUaGUgY3Vy cmVudCBkb2N1bWVudCBpcyBsaW1pdGVkIHRvIDMgdXNlIGNhc2VzIGRlc2NyaWJlZCBvdmVyIDEw aXNoIHBhZ2VzLi4gV2UNCj4gYmVsaWV2ZSB0aGUgY3VycmVudCBkb2N1bWVudCBhZGRyZXNzZXMg dGhlIGZlZWQgYmFja3MgYW5kIGNvbW1lbnRzIHdlDQo+IHJlY2VpdmVkIGZyb20gdGhlIExvbmRv biBzZXNzaW9uLiBJZiB5b3UgYmVsaWV2ZSBvdGhlcndpc2UsIGZlZWwgZnJlZSB0bw0KPiBicmlu ZyB0aGlzIG9uIHRoZSBtYWlsaW5nIGxpc3QuDQo+DQo+IFdlIGV4cGVjdCB0byBwdWJsaXNoIHZl cnNpb24gMTIgb24gVHVlc2RheSBBcHJpbCAzLiBUaGlzIHZlcnNpb24gaXMgZXhwZWN0ZWQNCj4g dG8gYWRkcmVzcyB0aGUgcmVjZWl2ZWQgY29tbWVudHMgYW5kIGJlIHJlYWR5IHRvIFdHTEMuDQo+ DQo+IENvbW1lbnRzIGNhbiBiZSBhZGRyZXNzZWQgZGlyZWN0bHkgdG8gdGhlIG1haWxpbmcgbGlz dCBvciB1c2luZyBnaXRodWIgcHVsbA0KPiByZXF1ZXN0cyBvbiB0aGUgbWtkIHZlcnNpb24gWzJd LiBJZiB5b3UgYmVsaWV2ZSBzb21lIGRpc2N1c3Npb25zIGFyZSBuZWVkZWQsDQo+IHBsZWFzZSBj b25zaWRlciBkaXNjdXNzaW5nIHRob3NlIG9uIHRoZSBtYWlsaW5nIGxpc3QuDQo+DQo+IFlvdXJz LA0KPiBEYW5pZWwNCj4gWzFdIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWlldGYtZG90cy11c2UtY2FzZXMvDQo+IFsyXSAgaHR0cHM6Ly9naXRodWIuY29tL2RvdHN3Zy9k b3RzLXVzZS1jYXNlcy9ibG9iL21hc3Rlci9kcmFmdC1pZXRmLWRvdHMtDQo+IHVzZS1jYXNlcy5t a2QNCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogaW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IFttYWlsdG86aW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+XQ0K PiBTZW50OiBXZWRuZXNkYXksIE1hcmNoIDI4LCAyMDE4IDEwOjA0IEFNDQo+IFRvOiBLYW5hbWUg TmlzaGl6dWthIDxrYW5hbWVAbnR0djYuanA8bWFpbHRvOmthbmFtZUBudHR2Ni5qcD4+OyBOaWsg VGVhZ3VlIDxudGVhZ3VlQHZlcmlzaWduLmNvbTxtYWlsdG86bnRlYWd1ZUB2ZXJpc2lnbi5jb20+ PjsNCj4gRGFuaWVsIE1pZ2F1bHQgPGRhbmllbC5taWdhdWx0QGVyaWNzc29uLmNvbTxtYWlsdG86 ZGFuaWVsLm1pZ2F1bHRAZXJpY3Nzb24uY29tPj47IFJvYmVydCBNb3Nrb3dpdHogPHJnbUBsYWJz Lmh0dC0NCjxtYWlsdG86cmdtQGxhYnMuaHR0LSUwYj4+IGNvbnN1bHQuY29tPGh0dHA6Ly9jb25z dWx0LmNvbT4+OyBTdGVmYW4gRm91YW50IDxzdGVmYW4uZm91YW50QGNvcHBlcnJpdmVyaXQuY29t PG1haWx0bzpzdGVmYW4uZm91YW50QGNvcHBlcnJpdmVyaXQuY29tPj47IGRvdHMtDQo+IGNoYWly c0BpZXRmLm9yZzxtYWlsdG86Y2hhaXJzQGlldGYub3JnPjsgUm9sYW5kIERvYmJpbnMgPHJkb2Ji aW5zQGFyYm9yLm5ldDxtYWlsdG86cmRvYmJpbnNAYXJib3IubmV0Pj47IExpYW5nIFhpYQ0KPiA8 ZnJhbmsueGlhbGlhbmdAaHVhd2VpLmNvbTxtYWlsdG86ZnJhbmsueGlhbGlhbmdAaHVhd2VpLmNv bT4+OyBMaWFuZyBYaWEgPEZyYW5rLnhpYWxpYW5nQGh1YXdlaS5jb208bWFpbHRvOkZyYW5rLnhp YWxpYW5nQGh1YXdlaS5jb20+Pg0KPiBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g Zm9yIGRyYWZ0LWlldGYtZG90cy11c2UtY2FzZXMtMTEudHh0DQo+DQo+DQo+IEEgbmV3IHZlcnNp b24gb2YgSS1ELCBkcmFmdC1pZXRmLWRvdHMtdXNlLWNhc2VzLTExLnR4dCBoYXMgYmVlbiBzdWNj ZXNzZnVsbHkNCj4gc3VibWl0dGVkIGJ5IERhbmllbCBNaWdhdWx0IGFuZCBwb3N0ZWQgdG8gdGhl IElFVEYgcmVwb3NpdG9yeS4NCj4NCj4gTmFtZTogICAgICAgICBkcmFmdC1pZXRmLWRvdHMtdXNl LWNhc2VzDQo+IFJldmlzaW9uOiAgICAgMTENCj4gVGl0bGU6ICAgICAgICAgICAgICAgIFVzZSBj YXNlcyBmb3IgRERvUyBPcGVuIFRocmVhdCBTaWduYWxpbmcNCj4gRG9jdW1lbnQgZGF0ZTogICAg ICAgIDIwMTgtMDMtMjgNCj4gR3JvdXA6ICAgICAgICAgICAgICAgIGRvdHMNCj4gUGFnZXM6ICAg ICAgICAgICAgICAgIDE0DQo+IFVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1kb3RzLXVzZS0NCj4gY2FzZXMtMTEudHh0DQo+IFN0 YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRm LWRvdHMtdXNlLWNhc2VzLw0KPiBIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtZG90cy11c2UtY2FzZXMtMTENCj4gSHRtbGl6ZWQ6ICAgICAgIGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1kb3RzLXVzZS0N Cj4gY2FzZXMNCj4gRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/ dXJsMj1kcmFmdC1pZXRmLWRvdHMtdXNlLWNhc2VzLQ0KPiAxMQ0KPg0KPiBBYnN0cmFjdDoNCj4g ICAgVGhlIEREb1MgT3BlbiBUaHJlYXQgU2lnbmFsaW5nIChET1RTKSBlZmZvcnQgaXMgaW50ZW5k ZWQgdG8gcHJvdmlkZSBhDQo+ICAgIHByb3RvY29sIHRvIGZhY2lsaXRhdGUgaW50ZXJvcGVyYWJp bGl0eSBhY3Jvc3MgZGlzcGFyYXRlIEREb1MNCj4gICAgbWl0aWdhdGlvbiBzb2x1dGlvbnMgYW5k IHNlcnZpY2VzLiAgVGhpcyBkb2N1bWVudCBwcmVzZW50cyB1c2UgY2FzZXMNCj4gICAgd2hpY2gg ZGVzY3JpYmUgdGhlIGludGVyYWN0aW9ucyBleHBlY3RlZCBiZXR3ZWVuIHRoZSBET1RTIGNvbXBv bmVudHMNCj4gICAgYXMgd2VsbCBhcyBET1RTIG1lc3NhZ2luZyBleGNoYW5nZXMuICBUaGUgcHVy cG9zZSBvZiBkZXNjcmliaW5nIHVzZQ0KPiAgICBjYXNlcyBpcyB0byBpZGVudGlmeSB0aGUgaW50 ZXJhY3RpbmcgRE9UUyBjb21wb25lbnRzLCBob3cgdGhleQ0KPiAgICBjb2xsYWJvcmF0ZSBhbmQg d2hhdCBhcmUgdGhlIHR5cGVzIG9mIGluZm9ybWF0aW9uIHRvIGJlIGV4Y2hhbmdlZC4NCj4NCj4N Cj4NCj4NCj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVz IGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KPiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lv biBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnPGh0dHA6Ly90b29scy5p ZXRmLm9yZz4uDQo+DQo+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQo+DQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IERvdHMgbWFpbGluZyBsaXN0DQo+ IERvdHNAaWV0Zi5vcmc8bWFpbHRvOkRvdHNAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vZG90cw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KRG90cyBtYWlsaW5nIGxpc3QNCkRvdHNAaWV0Zi5vcmc8bWFp bHRvOkRvdHNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2RvdHMNCg0K --_000_787AE7BB302AE849A7480A190F8B93302DEF7DEEOPEXCLILMA3corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsN Cgljb2xvcjpibGFjazsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V Uzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2lu OjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJGUiIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5EYW5pZWwsDQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+U291bmRz IGxpa2UgYSBnb29kIHBsYW4uIFRoYW5rcy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5NZWQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzow Y20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRlJm5ic3A7 Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBtZ2x0LmlldGZAZ21haWwu Y29tIFttYWlsdG86bWdsdC5pZXRmQGdtYWlsLmNvbV0NCjxiPkRlIGxhIHBhcnQgZGU8L2I+IERh bmllbCBNaWdhdWx0PGJyPg0KPGI+RW52b3nDqSZuYnNwOzo8L2I+IG1lcmNyZWRpIDQgYXZyaWwg MjAxOCAxNDo1OTxicj4NCjxiPsOAJm5ic3A7OjwvYj4gQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09M Tjxicj4NCjxiPkNjJm5ic3A7OjwvYj4gZG90c0BpZXRmLm9yZzxicj4NCjxiPk9iamV0Jm5ic3A7 OjwvYj4gUmU6IFtEb3RzXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYt ZG90cy11c2UtY2FzZXMtMTEudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij5UaGFuayB5b3UgTW9oYW1lZCBmb3IgdGhlIGNvbW1lbnRzLiBXZSB3aWxsIGFkZHJlc3Mg eW91ciBjb21tZW50cyBvbiB0aGUgbmV4dCB2ZXJzaW9uLiBJIGhhdmUgYSBzbWFsbCBjbGFyaWZp Y2F0aW9uIHJlZ2FyZGluZyBjb21tZW50IDcgb24gZmlndXJlIDIuIEkgdW5kZXJzdGFuZCB0aGUg ZmlndXJlIGlzIG1pc2xlYWRpbmcgYXMgdGhlIGZpZ3VyZSBzZWVtcw0KIHRvIGluZGljYXRlIGEg ZGVkaWNhdGVkIGxpbmsgYmV0d2VlbiB0aGUgRERvUyB0YXJnZXQgYW5kIHRoZSBETVMuIEluIHRo ZSBuZXh0IHZlcnNpb24gSSBhbSBwbGFubmluZyB0byBoYXZlIGEgZmlndXJlIHdoZW4gdGhhdCBz cGVjaWZpYyBjb21tdW5pY2F0aW9uIGdvZXMgdGhvdWdoIHRoZSB0cmFuc2l0IHByb3ZpZGVyLiBJ IHRoaW5rIHRoYXQgd291bGQgYWRkcmVzcyB5b3VyIGNvbmNlcm4sIGJ1dCBpZiBub3QsIHBsZWFz ZSBsZXQgbWUga25vdy4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5Zb3VycywgPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkRhbmllbCA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u IFdlZCwgQXByIDQsIDIwMTggYXQgNDo0MiBBTSwgJmx0OzxhIGhyZWY9Im1haWx0bzptb2hhbWVk LmJvdWNhZGFpckBvcmFuZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+bW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SGkgRGFuaWVsLCBhbGwsPGJyPg0KPGJyPg0KRldJVywgeW91IG1heSBmaW5kIHNvbWUg Y29tbWVudHMgdG8gdGhlIC0xMSBhdDo8YnI+DQo8YnI+DQpQREY6IDxhIGhyZWY9Imh0dHBzOi8v Z2l0aHViLmNvbS9ib3VjYWRhaXIvSUVURi1EcmFmdHMtUmV2aWV3cy9ibG9iL21hc3Rlci9kcmFm dC1pZXRmLWRvdHMtdXNlLWNhc2VzLTExLXJldiUyME1lZC5wZGYiIHRhcmdldD0iX2JsYW5rIj4N Cmh0dHBzOi8vZ2l0aHViLmNvbS9ib3VjYWRhaXIvSUVURi1EcmFmdHMtUmV2aWV3cy9ibG9iL21h c3Rlci9kcmFmdC1pZXRmLWRvdHMtdXNlLWNhc2VzLTExLXJldiUyME1lZC5wZGY8L2E+PGJyPg0K RE9DOiA8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vYm91Y2FkYWlyL0lFVEYtRHJhZnRzLVJl dmlld3MvcmF3L21hc3Rlci9kcmFmdC1pZXRmLWRvdHMtdXNlLWNhc2VzLTExLXJldiUyME1lZC5k b2MiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZ2l0aHViLmNvbS9ib3VjYWRhaXIvSUVURi1E cmFmdHMtUmV2aWV3cy9yYXcvbWFzdGVyL2RyYWZ0LWlldGYtZG90cy11c2UtY2FzZXMtMTEtcmV2 JTIwTWVkLmRvYzwvYT48YnI+DQo8YnI+DQpDaGVlcnMsPGJyPg0KTWVkPGJyPg0KPGJyPg0KJmd0 OyAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS08YnI+DQomZ3Q7IERlJm5ic3A7OiBEb3RzIFtt YWlsdG86PGEgaHJlZj0ibWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZyI+ZG90cy1ib3VuY2Vz QGlldGYub3JnPC9hPl0gRGUgbGEgcGFydCBkZSBEYW5pZWwgTWlnYXVsdDxicj4NCiZndDsgRW52 b3nDqSZuYnNwOzogbWVyY3JlZGkgMjggbWFycyAyMDE4IDE2OjI0PGJyPg0KJmd0OyDDgCZuYnNw OzogPGEgaHJlZj0ibWFpbHRvOmRvdHNAaWV0Zi5vcmciPmRvdHNAaWV0Zi5vcmc8L2E+PGJyPg0K Jmd0OyBPYmpldCZuYnNwOzogW0RvdHNdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y IGRyYWZ0LWlldGYtZG90cy11c2UtY2FzZXMtPGJyPg0KJmd0OyAxMS50eHQ8YnI+DQomZ3Q7PGJy Pg0KJmd0OyBIaSBldmVyeW9uZSE8YnI+DQomZ3Q7PGJyPg0KJmd0OyBQbGVhc2UgZmluZCB0aGUg ZHJhZnQtaWV0Zi1kb3RzLXVzZS1jYXNlcy0xMSBbMV0uIEluIG9yZGVyIHRvIG1lZXQgdGhlPGJy Pg0KJmd0OyBhZ2dyZXNzaXZlIHNjaGVkdWxlIGFncmVlZCBkdXJpbmcgdGhlIHNlc3Npb24gaW4g TG9uZG9uLCB3ZSB3b3VsZCBncmVhdGx5PGJyPg0KJmd0OyBhcHByZWNpYXRlIHlvdXIgZmVlZCBi YWNrcyBieSB0aGUgZW5kIG9mIHRoZSB3ZWVrICE8YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGUgY3Vy cmVudCBkb2N1bWVudCBpcyBsaW1pdGVkIHRvIDMgdXNlIGNhc2VzIGRlc2NyaWJlZCBvdmVyIDEw aXNoIHBhZ2VzLi4gV2U8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jmd0OyBiZWxpZXZlIHRoZSBjdXJyZW50IGRvY3VtZW50IGFkZHJlc3NlcyB0aGUg ZmVlZCBiYWNrcyBhbmQgY29tbWVudHMgd2U8YnI+DQomZ3Q7IHJlY2VpdmVkIGZyb20gdGhlIExv bmRvbiBzZXNzaW9uLiBJZiB5b3UgYmVsaWV2ZSBvdGhlcndpc2UsIGZlZWwgZnJlZSB0bzxicj4N CiZndDsgYnJpbmcgdGhpcyBvbiB0aGUgbWFpbGluZyBsaXN0Ljxicj4NCiZndDs8YnI+DQomZ3Q7 IFdlIGV4cGVjdCB0byBwdWJsaXNoIHZlcnNpb24gMTIgb24gVHVlc2RheSBBcHJpbCAzLiBUaGlz IHZlcnNpb24gaXMgZXhwZWN0ZWQ8YnI+DQomZ3Q7IHRvIGFkZHJlc3MgdGhlIHJlY2VpdmVkIGNv bW1lbnRzIGFuZCBiZSByZWFkeSB0byBXR0xDLjxicj4NCiZndDs8YnI+DQomZ3Q7IENvbW1lbnRz IGNhbiBiZSBhZGRyZXNzZWQgZGlyZWN0bHkgdG8gdGhlIG1haWxpbmcgbGlzdCBvciB1c2luZyBn aXRodWIgcHVsbDxicj4NCiZndDsgcmVxdWVzdHMgb24gdGhlIG1rZCB2ZXJzaW9uIFsyXS4gSWYg eW91IGJlbGlldmUgc29tZSBkaXNjdXNzaW9ucyBhcmUgbmVlZGVkLDxicj4NCiZndDsgcGxlYXNl IGNvbnNpZGVyIGRpc2N1c3NpbmcgdGhvc2Ugb24gdGhlIG1haWxpbmcgbGlzdC48YnI+DQo8c3Bh biBsYW5nPSJFTi1VUyI+Jmd0Ozxicj4NCiZndDsgWW91cnMsPGJyPg0KJmd0OyBEYW5pZWw8YnI+ DQomZ3Q7IFsxXSA8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaWV0Zi1kb3RzLXVzZS1jYXNlcy8iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5n PSJFTi1VUyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1kb3Rz LXVzZS1jYXNlcy88L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQomZ3Q7IFsyXSZu YnNwOyA8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL2RvdHN3Zy9kb3RzLXVzZS1j YXNlcy9ibG9iL21hc3Rlci9kcmFmdC1pZXRmLWRvdHMtIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4g bGFuZz0iRU4tVVMiPmh0dHBzOi8vZ2l0aHViLmNvbS9kb3Rzd2cvZG90cy11c2UtY2FzZXMvYmxv Yi9tYXN0ZXIvZHJhZnQtaWV0Zi1kb3RzLTwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiPjxi cj4NCiZndDsgdXNlLWNhc2VzLm1rZDxicj4NCiZndDs8YnI+DQomZ3Q7IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tPGJyPg0KJmd0OyBGcm9tOiA8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZyI+PHNwYW4gbGFuZz0iRU4tVVMiPmludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiPiBbbWFpbHRvOjwvc3Bhbj48YSBo cmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIj48c3BhbiBsYW5nPSJFTi1VUyI+ aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1VUyI+XTxi cj4NCiZndDsgU2VudDogV2VkbmVzZGF5LCBNYXJjaCAyOCwgMjAxOCAxMDowNCBBTTxicj4NCiZn dDsgVG86IEthbmFtZSBOaXNoaXp1a2EgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86a2FuYW1l QG50dHY2LmpwIj48c3BhbiBsYW5nPSJFTi1VUyI+a2FuYW1lQG50dHY2LmpwPC9zcGFuPjwvYT48 c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OzsgTmlrIFRlYWd1ZSAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1h aWx0bzpudGVhZ3VlQHZlcmlzaWduLmNvbSI+PHNwYW4gbGFuZz0iRU4tVVMiPm50ZWFndWVAdmVy aXNpZ24uY29tPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0Ozs8YnI+DQomZ3Q7IERh bmllbCBNaWdhdWx0ICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmRhbmllbC5taWdhdWx0QGVy aWNzc29uLmNvbSI+PHNwYW4gbGFuZz0iRU4tVVMiPmRhbmllbC5taWdhdWx0QGVyaWNzc29uLmNv bTwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDs7IFJvYmVydCBNb3Nrb3dpdHogJmx0 Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86cmdtQGxhYnMuaHR0LSUwYiI+PHNwYW4gbGFuZz0iRU4t VVMiPnJnbUBsYWJzLmh0dC08YnI+DQo8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7 IDwvc3Bhbj48YSBocmVmPSJodHRwOi8vY29uc3VsdC5jb20iIHRhcmdldD0iX2JsYW5rIj48c3Bh biBsYW5nPSJFTi1VUyI+Y29uc3VsdC5jb208L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVTIj4m Z3Q7OyBTdGVmYW4gRm91YW50ICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnN0ZWZhbi5mb3Vh bnRAY29wcGVycml2ZXJpdC5jb20iPjxzcGFuIGxhbmc9IkVOLVVTIj5zdGVmYW4uZm91YW50QGNv cHBlcnJpdmVyaXQuY29tPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OzsNCiBkb3Rz LTxicj4NCiZndDsgPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpjaGFpcnNAaWV0Zi5vcmciPjxzcGFu IGxhbmc9IkVOLVVTIj5jaGFpcnNAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVT Ij47IFJvbGFuZCBEb2JiaW5zICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnJkb2JiaW5zQGFy Ym9yLm5ldCI+PHNwYW4gbGFuZz0iRU4tVVMiPnJkb2JiaW5zQGFyYm9yLm5ldDwvc3Bhbj48L2E+ PHNwYW4gbGFuZz0iRU4tVVMiPiZndDs7IExpYW5nIFhpYTxicj4NCiZndDsgJmx0Ozwvc3Bhbj48 YSBocmVmPSJtYWlsdG86ZnJhbmsueGlhbGlhbmdAaHVhd2VpLmNvbSI+PHNwYW4gbGFuZz0iRU4t VVMiPmZyYW5rLnhpYWxpYW5nQGh1YXdlaS5jb208L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVT Ij4mZ3Q7OyBMaWFuZyBYaWEgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86RnJhbmsueGlhbGlh bmdAaHVhd2VpLmNvbSI+PHNwYW4gbGFuZz0iRU4tVVMiPkZyYW5rLnhpYWxpYW5nQGh1YXdlaS5j b208L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7PGJyPg0KJmd0OyBTdWJqZWN0OiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtZG90cy11c2UtY2FzZXMtMTEu dHh0PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBk cmFmdC1pZXRmLWRvdHMtdXNlLWNhc2VzLTExLnR4dCBoYXMgYmVlbiBzdWNjZXNzZnVsbHk8YnI+ DQomZ3Q7IHN1Ym1pdHRlZCBieSBEYW5pZWwgTWlnYXVsdCBhbmQgcG9zdGVkIHRvIHRoZSBJRVRG IHJlcG9zaXRvcnkuPGJyPg0KPC9zcGFuPiZndDs8YnI+DQomZ3Q7IE5hbWU6Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RyYWZ0LWlldGYtZG90cy11c2UtY2FzZXM8YnI+DQomZ3Q7 IFJldmlzaW9uOiZuYnNwOyAmbmJzcDsgJm5ic3A7MTE8YnI+DQomZ3Q7IFRpdGxlOiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgVXNlIGNhc2Vz IGZvciBERG9TIE9wZW4gVGhyZWF0IFNpZ25hbGluZzxicj4NCiZndDsgRG9jdW1lbnQgZGF0ZTom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgMjAxOC0wMy0yODxicj4NCiZndDsgR3JvdXA6Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBkb3Rz PGJyPg0KJmd0OyBQYWdlczombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IDE0PGJyPg0KJmd0OyBVUkw6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzL2RyYWZ0LWlldGYtZG90cy11c2UtIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1kb3RzLXVzZS08L2E+PGJyPg0K Jmd0OyBjYXNlcy0xMS50eHQ8YnI+DQomZ3Q7IFN0YXR1czombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi1kb3RzLXVzZS1jYXNlcy8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWRvdHMtdXNlLWNhc2VzLzwvYT48YnI+DQomZ3Q7 IEh0bWxpemVkOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRvdHMtdXNlLWNhc2VzLTExIiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZG90cy11c2UtY2Fz ZXMtMTE8L2E+PGJyPg0KJmd0OyBIdG1saXplZDombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8 YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYt ZG90cy11c2UtIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvaHRtbC9kcmFmdC1pZXRmLWRvdHMtdXNlLTwvYT48YnI+DQomZ3Q7IGNhc2VzPGJyPg0KJmd0 OyBEaWZmOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtZG90cy11c2UtY2Fz ZXMtIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRy YWZ0LWlldGYtZG90cy11c2UtY2FzZXMtPC9hPjxicj4NCiZndDsgMTE8YnI+DQomZ3Q7PGJyPg0K Jmd0OyBBYnN0cmFjdDo8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBUaGUgRERvUyBPcGVuIFRocmVh dCBTaWduYWxpbmcgKERPVFMpIGVmZm9ydCBpcyBpbnRlbmRlZCB0byBwcm92aWRlIGE8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyBwcm90b2NvbCB0byBmYWNpbGl0YXRlIGludGVyb3BlcmFiaWxpdHkg YWNyb3NzIGRpc3BhcmF0ZSBERG9TPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgbWl0aWdhdGlvbiBz b2x1dGlvbnMgYW5kIHNlcnZpY2VzLiZuYnNwOyBUaGlzIGRvY3VtZW50IHByZXNlbnRzIHVzZSBj YXNlczxicj4NCiZndDsmbmJzcDsgJm5ic3A7IHdoaWNoIGRlc2NyaWJlIHRoZSBpbnRlcmFjdGlv bnMgZXhwZWN0ZWQgYmV0d2VlbiB0aGUgRE9UUyBjb21wb25lbnRzPGJyPg0KJmd0OyZuYnNwOyAm bmJzcDsgYXMgd2VsbCBhcyBET1RTIG1lc3NhZ2luZyBleGNoYW5nZXMuJm5ic3A7IFRoZSBwdXJw b3NlIG9mIGRlc2NyaWJpbmcgdXNlPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgY2FzZXMgaXMgdG8g aWRlbnRpZnkgdGhlIGludGVyYWN0aW5nIERPVFMgY29tcG9uZW50cywgaG93IHRoZXk8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyBjb2xsYWJvcmF0ZSBhbmQgd2hhdCBhcmUgdGhlIHR5cGVzIG9mIGlu Zm9ybWF0aW9uIHRvIGJlIGV4Y2hhbmdlZC48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8 YnI+DQomZ3Q7PGJyPg0KJmd0OyBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxl IG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uPGJyPg0KJmd0OyB1bnRpbCB0 aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IDxhIGhyZWY9Imh0 dHA6Ly90b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KdG9vbHMuaWV0Zi5vcmc8L2E+ Ljxicj4NCiZndDs8YnI+DQomZ3Q7IFRoZSBJRVRGIFNlY3JldGFyaWF0PGJyPg0KJmd0Ozxicj4N CiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQomZ3Q7IERvdHMgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86RG90c0Bp ZXRmLm9yZyI+RG90c0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90cyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90czwvYT48YnI+DQo8YnI+DQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkRvdHMgbWFpbGlu ZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOkRvdHNAaWV0Zi5vcmciPkRvdHNAaWV0Zi5vcmc8 L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9k b3RzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9kb3RzPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_787AE7BB302AE849A7480A190F8B93302DEF7DEEOPEXCLILMA3corp_-- From nobody Wed Apr 4 06:31:12 2018 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 5F23E127522 for ; Wed, 4 Apr 2018 06:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-2Pw67vCSYv for ; Wed, 4 Apr 2018 06:31:09 -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 3746912762F for ; Wed, 4 Apr 2018 06:31:05 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.90_1) (envelope-from ) id 1f3iVD-0006Us-Mz for ietf-supjps-dots@ietf.org; Wed, 04 Apr 2018 14:31:03 +0100 From: "Jon Shallow" To: Date: Wed, 4 Apr 2018 14:31:04 +0100 Message-ID: <014f01d3cc19$2e3880e0$8aa982a0$@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: AdPMGSyCaQQbv+vLSW+0gkDbU7HOEw== Content-Language: en-gb Archived-At: Subject: [Dots] Signal Channel - 300 Redirected Signaling 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: Wed, 04 Apr 2018 13:31:10 -0000 Hi there, I have implemented the 300 Redirected-Signal in my DOTS code. This then raises some questions about usability. Usability #1 Architecture 3.2.2 Redirected Signalling 4. Having redirected the DOTS client, DOTS server A ceases sending server signals. The DOTS client likewise stops sending client signals to DOTS server A. DOTS session 1 is terminated. Clearly indicates that the original session (Client to Server A) is no more once redirected and only Client to Server B is in use. How is the traffic redirected back to Server A once maintenance / overloading etc. has finished? My assumption is that Server B sends a redirect to go back to Server A as Server A has no way to say over a now non-existent session to say "come back". Do we need to keep the existing Client to Server A session warm (or perhaps to probe periodically) to see if Server A is capable of handling the Client again by a server response extension to the protocol (e.g. a 3.01) Should there be a retry period parameter added in to the 3.00 protocol (as I read it, ttl only refers to the IP address)? Usability #2 Server A says "Redirect to Server B" due to overloading. Server B accepts things for a while and then is instructed/decides to redirect traffic back to A. Server A is left still overload configured to redirect to B. How should the client handle this as there is no suitable Server? I agree that there needs to be co-ordination between Server A and Server B, but user error may creep in. Usability #3 Server A says "Redirect to Server B" as it going to be shut down because of maintenance. Server B accepts things for a while and then is instructed (in probable user error) to redirect traffic back to A (perhaps because it has hit an overload condition). How should the client handle this? Regards Jon From nobody Wed Apr 4 06:51:25 2018 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 5D251126BF7 for ; Wed, 4 Apr 2018 06:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDclkGEocTt4 for ; Wed, 4 Apr 2018 06:51: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 814C21204DA for ; Wed, 4 Apr 2018 06:51:21 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.90_1) (envelope-from ) id 1f3ioq-0006Vi-0x for ietf-supjps-dots@ietf.org; Wed, 04 Apr 2018 14:51:20 +0100 From: "Jon Shallow" To: Date: Wed, 4 Apr 2018 14:51:20 +0100 Message-ID: <016401d3cc1c$03321200$09963600$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0165_01D3CC24.64F76460" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdPMHAMfDWFlXvb3TSeAr5MVkYUzIg== Content-Language: en-gb Archived-At: Subject: [Dots] Data Channel ACL fragments 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: Wed, 04 Apr 2018 13:51:23 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0165_01D3CC24.64F76460 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi there, Do we still need to have the fragment definition for ACEs in the data channel? draft-ietf-netmod-acl-model-18 now supports fragments for ipv4 (flags + options) and implicitly in ipv6 through the next header field protocol set to 44 (fragment extension header). IPV4 ==== grouping acl-ipv4-header-fields { description "Fields in IPv4 header."; ... leaf flags { type bits { bit reserved { position 0; description "Reserved. Must be zero."; } bit fragment { position 1; description "Setting value to 0 indicates may fragment, while setting the value to 1 indicates do not fragment."; } bit more { position 2; description "Setting the value to 0 indicates this is the last fragment, and setting the value to 1 indicates more fragments are coming."; } } description "Bit definitions for the flags field in IPv4 header."; } leaf offset { type uint16 { range "20..65535"; } description "The fragment offset is measured in units of 8 octets (64 bits). The first fragment has offset zero. The length is 13 bits"; } Regards Jon ------=_NextPart_000_0165_01D3CC24.64F76460 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = there,

 

Do we still need to have the fragment definition for = ACEs in the data channel?

 

draft-ietf-netmod-acl-model-18 now supports fragments = for ipv4 (flags + options) and implicitly in ipv6 through the next = header field protocol set to 44 (fragment extension = header).

 

IPV4

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

  = grouping acl-ipv4-header-fields {

    description

      "Fields in IPv4 = header.";

...

    leaf flags {

      type bits = {

        bit = reserved {

          = position 0;

          = description

         &= nbsp;  "Reserved. Must be zero.";

        = }

        bit = fragment {

          = position 1;

          = description

         &= nbsp;  "Setting value to 0 indicates may fragment, while = setting

         &= nbsp;   the value to 1 indicates do not = fragment.";

        = }

        bit more = {

          = position 2;

          = description

         &= nbsp;  "Setting the value to 0 indicates this is the last = fragment,

         &= nbsp;   and setting the value to 1 indicates more fragments = are

         &= nbsp;   coming.";

        = }

      = }

      = description

        "Bit = definitions for the flags field in IPv4 header.";

    }

 

    leaf offset {

      type uint16 = {

   =      range = "20..65535";

      }

      = description

        "The = fragment offset is measured in units of 8 octets (64 = bits).

         The = first fragment has offset zero. The length is 13 = bits";

    = }

 

Regards

 

Jon

 

------=_NextPart_000_0165_01D3CC24.64F76460-- From nobody Wed Apr 4 07:07:15 2018 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 D86AF127601 for ; Wed, 4 Apr 2018 07:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A01tGKisRenb for ; Wed, 4 Apr 2018 07:07:11 -0700 (PDT) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 569D9127522 for ; Wed, 4 Apr 2018 07:07:11 -0700 (PDT) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 20C29C08B5; Wed, 4 Apr 2018 16:07:10 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.57]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id 05D311A0098; Wed, 4 Apr 2018 16:07:10 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM23.corporate.adroot.infra.ftgroup ([fe80::787e:db0c:23c4:71b3%19]) with mapi id 14.03.0382.000; Wed, 4 Apr 2018 16:07:09 +0200 From: To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Signal Channel - 300 Redirected Signaling Thread-Index: AdPMGSyCaQQbv+vLSW+0gkDbU7HOEwAAo7xA Date: Wed, 4 Apr 2018 14:07:09 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DEF7E7B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <014f01d3cc19$2e3880e0$8aa982a0$@jpshallow.com> In-Reply-To: <014f01d3cc19$2e3880e0$8aa982a0$@jpshallow.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling 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: Wed, 04 Apr 2018 14:07:14 -0000 Re-, Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow > Envoy=E9=A0: mercredi 4 avril 2018 15:31 > =C0=A0: dots@ietf.org > Objet=A0: [Dots] Signal Channel - 300 Redirected Signaling >=20 > Hi there, >=20 > I have implemented the 300 Redirected-Signal in my DOTS code. This then > raises some questions about usability. >=20 > Usability #1 >=20 > Architecture 3.2.2 Redirected Signalling >=20 > 4. Having redirected the DOTS client, DOTS server A ceases sending > server signals. The DOTS client likewise stops sending client > signals to DOTS server A. DOTS session 1 is terminated. >=20 > Clearly indicates that the original session (Client to Server A) is no mo= re > once redirected and only Client to Server B is in use. >=20 > How is the traffic redirected back to Server A once maintenance / > overloading etc. has finished? My assumption is that Server B sends a > redirect to go back to Server A as Server A has no way to say over a now > non-existent session to say "come back". [Med] That's one possibility. This one does not require any update to the s= ignal-channel specification. Another approach would be to not require any redirect signal from server B.= The client will remove server B's records upon the expiry of the TTL and w= ill fall back to the "base" DOTS servers configuration that was provisioned= to the client using DHCP or whatever mechanism.=20 >=20 > Do we need to keep the existing Client to Server A session warm (or perha= ps > to probe periodically) to see if Server A is capable of handling the Clie= nt > again by a server response extension to the protocol (e.g. a 3.01) [Med] Redirect was initially introduced to manage a server overload, so I d= on't think it makes sense to probe or maintain a session with server A.=20 >=20 > Should there be a retry period parameter added in to the 3.00 protocol (a= s I > read it, ttl only refers to the IP address)? [Med] The client will automatically switch to Server A when all alternate r= ecords expire. =20 >=20 > Usability #2 >=20 > Server A says "Redirect to Server B" due to overloading. Server B accept= s > things for a while and then is instructed/decides to redirect traffic bac= k > to A. Server A is left still overload configured to redirect to B. How > should the client handle this as there is no suitable Server? [Med] This is a service configuration problem. We may ask: * the client to log the error and notify the administrator. * and/or stop the redirection after n cycles. Still, this does not solve the problem.=20 >=20 > I agree that there needs to be co-ordination between Server A and Server = B, > but user error may creep in. >=20 > Usability #3 >=20 > Server A says "Redirect to Server B" as it going to be shut down because = of > maintenance. Server B accepts things for a while and then is instructed = (in > probable user error) to redirect traffic back to A (perhaps because it ha= s > hit an overload condition). How should the client handle this? [Med] Isn't this a sub-case or #2? >=20 >=20 > Regards >=20 > Jon >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Wed Apr 4 07:27:06 2018 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 8746D12778D for ; Wed, 4 Apr 2018 07:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amWWr9vH8Ngw for ; Wed, 4 Apr 2018 07:27:02 -0700 (PDT) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C94212025C for ; Wed, 4 Apr 2018 07:27:02 -0700 (PDT) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 79E09C097F; Wed, 4 Apr 2018 16:27:00 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.34]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id 57D0C180068; Wed, 4 Apr 2018 16:27:00 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6F.corporate.adroot.infra.ftgroup ([fe80::bd00:88f8:8552:3349%17]) with mapi id 14.03.0382.000; Wed, 4 Apr 2018 16:27:00 +0200 From: To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Data Channel ACL fragments Thread-Index: AdPMHAMfDWFlXvb3TSeAr5MVkYUzIgAA3pEA Date: Wed, 4 Apr 2018 14:26:59 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DEF7F97@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <016401d3cc1c$03321200$09963600$@jpshallow.com> In-Reply-To: <016401d3cc1c$03321200$09963600$@jpshallow.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93302DEF7F97OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Data Channel ACL fragments 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: Wed, 04 Apr 2018 14:27:04 -0000 --_000_787AE7BB302AE849A7480A190F8B93302DEF7F97OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, I guess we do still need this because we wanted to achieve this functionali= ty (especially for the non-initial fragments): =3D=3D This document supports fragment filtering which adds an additional layer of protection against a DoS attack that uses non-initial fragments only. When there is only layer 3 information in the ACL entry and the fragments keyword is present, for non-initial fragments matching the ACE entry, the 'deny' or 'accept' action associated with the ACE entry will be enforced. For initial or non-fragment matching the ACE entry, the next ACE entry will be processed. When there is both layer 3 and layer 4 information in the ACE entry and the fragments keyword is present, the ACE action is conservative for both 'accept' and 'deny' actions. The actions are conservative to not accidentally deny a fragmented portion of a flow because the fragments do not contain sufficient information to match all of the filter attributes. In the 'deny' action case, instead of denying a non-initial fragment, the next ACE entry is processed. In the 'accept' case, it is assumed that the layer 4 information in the non- initial fragment, if available, matches the layer 4 information in the ACE entry. =3D=3D No? Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : mercredi 4 avril 2018 15:51 =C0 : dots@ietf.org Objet : [Dots] Data Channel ACL fragments Hi there, Do we still need to have the fragment definition for ACEs in the data chann= el? draft-ietf-netmod-acl-model-18 now supports fragments for ipv4 (flags + opt= ions) and implicitly in ipv6 through the next header field protocol set to = 44 (fragment extension header). IPV4 =3D=3D=3D=3D grouping acl-ipv4-header-fields { description "Fields in IPv4 header."; ... leaf flags { type bits { bit reserved { position 0; description "Reserved. Must be zero."; } bit fragment { position 1; description "Setting value to 0 indicates may fragment, while setting the value to 1 indicates do not fragment."; } bit more { position 2; description "Setting the value to 0 indicates this is the last fragment, and setting the value to 1 indicates more fragments are coming."; } } description "Bit definitions for the flags field in IPv4 header."; } leaf offset { type uint16 { range "20..65535"; } description "The fragment offset is measured in units of 8 octets (64 bits). The first fragment has offset zero. The length is 13 bits"; } Regards Jon --_000_787AE7BB302AE849A7480A190F8B93302DEF7F97OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-,

 

I guess we do still need this b= ecause we wanted to achieve this functionality (especially for the non-init= ial fragments):

 

=3D=3D

   This d= ocument supports fragment filtering which adds an additional

   layer = of protection against a DoS attack that uses non-initial<= /p>

   fragme= nts only.  When there is only layer 3 information in the ACL

   entry = and the fragments keyword is present, for non-initial fragments<= /span>

   matchi= ng the ACE entry, the 'deny' or 'accept' action associated with<= /span>

   the AC= E entry will be enforced.  For initial or non-fragment matching

   the AC= E entry, the next ACE entry will be processed.  When there is

   both l= ayer 3 and layer 4 information in the ACE entry and the

   fragme= nts keyword is present, the ACE action is conservative for both<= /span>

   'accep= t' and 'deny' actions.  The actions are conservative to not=

   accide= ntally deny a fragmented portion of a flow because the

   fragme= nts do not contain sufficient information to match all of the

   filter= attributes.  In the 'deny' action case, instead of denying a

   non-in= itial fragment, the next ACE entry is processed.  In the

   'accep= t' case, it is assumed that the layer 4 information in the non-<= /span>

   initia= l fragment, if available, matches the layer 4 information in

   the ACE entry.

=3D=3D

 

No?

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.= org] De la part de Jon Shallow
Envoy=E9 : mercredi 4 avril 2018 15:51
=C0 : dots@ietf.org
Objet : [Dots] Data Channel ACL fragments

 

Hi there,

 

Do we still need to have the fr= agment definition for ACEs in the data channel?

 

draft-ietf-netmod-acl-model-18 = now supports fragments for ipv4 (flags + options) and implicitly in ipv= 6 through the next header field protocol set to 44 (fragment extension head= er).

 

IPV4

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

  grouping acl-ipv4-header= -fields {

    description<= o:p>

      = "Fields in IPv4 header.";

...

    leaf flags {=

      = type bits {

     &= nbsp;  bit reserved {

     &= nbsp;    position 0;

     &= nbsp;    description

     &= nbsp;      "Reserved. Must be zero.";

     &= nbsp;  }

     &= nbsp;  bit fragment {

     &= nbsp;    position 1;

     &= nbsp;    description

     &= nbsp;      "Setting value to 0 indicates may = fragment, while setting

     &= nbsp;       the value to 1 indicates do not f= ragment.";

     &= nbsp;  }

     &= nbsp;  bit more {

     &= nbsp;    position 2;

     &= nbsp;    description

     &= nbsp;      "Setting the value to 0 indicates = this is the last fragment,

     &= nbsp;       and setting the value to 1 indica= tes more fragments are

     &= nbsp;       coming.";<= /p>

     &= nbsp;  }

      = }

      = description

     &= nbsp;  "Bit definitions for the flags field in IPv4 header."= ;

    }=

 

    leaf offset = {

      = type uint16 {

      =   range "20..65535";

      = }

      = description

     &= nbsp;  "The fragment offset is measured in units of 8 octets (64 = bits).

     &= nbsp;   The first fragment has offset zero. The length is 13 bits= ";

    }=

 

Regards

 

Jon

 

--_000_787AE7BB302AE849A7480A190F8B93302DEF7F97OPEXCLILMA3corp_-- From nobody Wed Apr 4 07:46:14 2018 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 10505124D37 for ; Wed, 4 Apr 2018 07:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g95zsISGRDyt for ; Wed, 4 Apr 2018 07:46: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 9FCB912D94F for ; Wed, 4 Apr 2018 07:46:06 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.90_1) (envelope-from ) id 1f3jfp-0006Y6-4M; Wed, 04 Apr 2018 15:46:05 +0100 From: "Jon Shallow" To: , References: <014f01d3cc19$2e3880e0$8aa982a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7E7B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DEF7E7B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Wed, 4 Apr 2018 15:46:05 +0100 Message-ID: <019901d3cc23$a93ff8e0$fbbfeaa0$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ5xX4UsK17va5Vv37fpNudI6+9awKIdnG+opB1p+A= Content-Language: en-gb Archived-At: Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling 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: Wed, 04 Apr 2018 14:46:13 -0000 Hi there, See inline [Jon] Regards Jon -----Original Message----- From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 04 April 2018 15:07 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling Re-, Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow=20 > Envoy=E9=A0: mercredi 4 avril 2018 15:31 =C0=A0: dots@ietf.org = Objet=A0: [Dots]=20 > Signal Channel - 300 Redirected Signaling >=20 > Hi there, >=20 > I have implemented the 300 Redirected-Signal in my DOTS code. This=20 > then raises some questions about usability. >=20 > Usability #1 >=20 > Architecture 3.2.2 Redirected Signalling >=20 > 4. Having redirected the DOTS client, DOTS server A ceases sending > server signals. The DOTS client likewise stops sending client > signals to DOTS server A. DOTS session 1 is terminated. >=20 > Clearly indicates that the original session (Client to Server A) is no = > more once redirected and only Client to Server B is in use. >=20 > How is the traffic redirected back to Server A once maintenance /=20 > overloading etc. has finished? My assumption is that Server B sends a = > redirect to go back to Server A as Server A has no way to say over a=20 > now non-existent session to say "come back". [Med] That's one possibility. This one does not require any update to = the signal-channel specification. Another approach would be to not require any redirect signal from server = B. The client will remove server B's records upon the expiry of the TTL and will fall back to the "base" DOTS servers configuration that was = provisioned to the client using DHCP or whatever mechanism.=20 [Jon] OK. The TTL is defined at, associated with the IP address level under alt-server-record, not under ietf-dots-signal-channel:redirected-signal. The ttl definition is ambiguous as to what it refers to and perhaps could be tightened up in = the language (I read it as being associated with "addr" in the sense of a = DNS TTL). >=20 > Do we need to keep the existing Client to Server A session warm (or=20 > perhaps to probe periodically) to see if Server A is capable of=20 > handling the Client again by a server response extension to the=20 > protocol (e.g. a 3.01) [Med] Redirect was initially introduced to manage a server overload, so = I don't think it makes sense to probe or maintain a session with server A. = [Jon] Agreed, but I needed to raise the question. >=20 > Should there be a retry period parameter added in to the 3.00 protocol = > (as I read it, ttl only refers to the IP address)? [Med] The client will automatically switch to Server A when all = alternate records expire.=20 [Jon] OK - again the 4.6 text needs to get tightened up to reflect this = as the intent. =20 >=20 > Usability #2 >=20 > Server A says "Redirect to Server B" due to overloading. Server B=20 > accepts things for a while and then is instructed/decides to redirect=20 > traffic back to A. Server A is left still overload configured to=20 > redirect to B. How should the client handle this as there is no = suitable Server? [Med] This is a service configuration problem. We may ask: * the client to log the error and notify the administrator. * and/or stop the redirection after n cycles. Still, this does not solve the problem.=20 [Jon] Agreed there is a problem here >=20 > I agree that there needs to be co-ordination between Server A and=20 > Server B, but user error may creep in. >=20 > Usability #3 >=20 > Server A says "Redirect to Server B" as it going to be shut down=20 > because of maintenance. Server B accepts things for a while and then=20 > is instructed (in probable user error) to redirect traffic back to A=20 > (perhaps because it has hit an overload condition). How should the = client handle this? [Med] Isn't this a sub-case or #2? [Jon] Yes, but I wanted to bring in Server A being alive and able to = respond versus Server A down and not responding due to maintenance. [Jon] With my better understanding of TTL we still have an issue if the = TTL expires and Server A is having an extended outage. How do we recover = from that?=20 ~jon >=20 >=20 > Regards >=20 > Jon >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Wed Apr 4 08:09:54 2018 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 CB53912D72F for ; Wed, 4 Apr 2018 08:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Leg6uCvIHVt for ; Wed, 4 Apr 2018 08:09:45 -0700 (PDT) Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A548312DA01 for ; Wed, 4 Apr 2018 08:09:44 -0700 (PDT) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 1E2261804CC; Wed, 4 Apr 2018 17:09:43 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.42]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id F36251A0074; Wed, 4 Apr 2018 17:09:42 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM41.corporate.adroot.infra.ftgroup ([fe80::c845:f762:8997:ec86%19]) with mapi id 14.03.0382.000; Wed, 4 Apr 2018 17:09:42 +0200 From: To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Signal Channel - 300 Redirected Signaling Thread-Index: AQJ5xX4UsK17va5Vv37fpNudI6+9awKIdnG+opB1p+CAAAUyYA== Date: Wed, 4 Apr 2018 15:09:39 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DEF8054@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <014f01d3cc19$2e3880e0$8aa982a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7E7B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <019901d3cc23$a93ff8e0$fbbfeaa0$@jpshallow.com> In-Reply-To: <019901d3cc23$a93ff8e0$fbbfeaa0$@jpshallow.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling 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: Wed, 04 Apr 2018 15:09:48 -0000 Re-, Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > Envoy=E9=A0: mercredi 4 avril 2018 16:46 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; dots@ietf.org > Objet=A0: RE: [Dots] Signal Channel - 300 Redirected Signaling >=20 > Hi there, >=20 > See inline [Jon] >=20 > Regards >=20 > Jon >=20 > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > mohamed.boucadair@orange.com > Sent: 04 April 2018 15:07 > To: Jon Shallow; dots@ietf.org > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling >=20 > Re-, >=20 > Please see inline. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow > > Envoy=E9=A0: mercredi 4 avril 2018 15:31 =C0=A0: dots@ietf.org Objet=A0= : [Dots] > > Signal Channel - 300 Redirected Signaling > > > > Hi there, > > > > I have implemented the 300 Redirected-Signal in my DOTS code. This > > then raises some questions about usability. > > > > Usability #1 > > > > Architecture 3.2.2 Redirected Signalling > > > > 4. Having redirected the DOTS client, DOTS server A ceases sending > > server signals. The DOTS client likewise stops sending client > > signals to DOTS server A. DOTS session 1 is terminated. > > > > Clearly indicates that the original session (Client to Server A) is no > > more once redirected and only Client to Server B is in use. > > > > How is the traffic redirected back to Server A once maintenance / > > overloading etc. has finished? My assumption is that Server B sends a > > redirect to go back to Server A as Server A has no way to say over a > > now non-existent session to say "come back". >=20 > [Med] That's one possibility. This one does not require any update to the > signal-channel specification. >=20 > Another approach would be to not require any redirect signal from server = B. > The client will remove server B's records upon the expiry of the TTL and > will fall back to the "base" DOTS servers configuration that was provisio= ned > to the client using DHCP or whatever mechanism. > [Jon] OK. The TTL is defined at, associated with the IP address level > under alt-server-record, not under > ietf-dots-signal-channel:redirected-signal. The ttl definition is > ambiguous as to what it refers to and perhaps could be tightened up in th= e > language (I read it as being associated with "addr" in the sense of a DNS > TTL). >=20 [Med] The current design for a finer granularity as it allows to associate = the same or distinct TTL to addresses that are associated with the same rec= ord. I can make this change: OLD:=20 addr: IP address of an alternate DOTS server. ttl: Time to live (TTL) represented as an integer number of seconds. NEW: ttl: Time to live (TTL) of the alternate IP address, represented as an integer number of seconds. addr: IP address of an alternate DOTS server. A DOTS client MUST NOT use this IP address to contact its DOTS server upon expiry of the associated TTL. If all alternate IP addresses have expired, the DOTS client MUST use the DOTS server(s) that was provisioned using means discussed in Section 4.1. > > > > Do we need to keep the existing Client to Server A session warm (or > > perhaps to probe periodically) to see if Server A is capable of > > handling the Client again by a server response extension to the > > protocol (e.g. a 3.01) >=20 > [Med] Redirect was initially introduced to manage a server overload, so I > don't think it makes sense to probe or maintain a session with server A. > [Jon] Agreed, but I needed to raise the question. >=20 > > > > Should there be a retry period parameter added in to the 3.00 protocol > > (as I read it, ttl only refers to the IP address)? >=20 > [Med] The client will automatically switch to Server A when all alternate > records expire. > [Jon] OK - again the 4.6 text needs to get tightened up to reflect this a= s > the intent. >=20 [Med] see above.=20 >=20 > > > > Usability #2 > > > > Server A says "Redirect to Server B" due to overloading. Server B > > accepts things for a while and then is instructed/decides to redirect > > traffic back to A. Server A is left still overload configured to > > redirect to B. How should the client handle this as there is no suitab= le > Server? >=20 > [Med] This is a service configuration problem. We may ask: > * the client to log the error and notify the administrator. > * and/or stop the redirection after n cycles. >=20 > Still, this does not solve the problem. > [Jon] Agreed there is a problem here >=20 > > > > I agree that there needs to be co-ordination between Server A and > > Server B, but user error may creep in. > > > > Usability #3 > > > > Server A says "Redirect to Server B" as it going to be shut down > > because of maintenance. Server B accepts things for a while and then > > is instructed (in probable user error) to redirect traffic back to A > > (perhaps because it has hit an overload condition). How should the cli= ent > handle this? >=20 > [Med] Isn't this a sub-case or #2? > [Jon] Yes, but I wanted to bring in Server A being alive and able to resp= ond > versus Server A down and not responding due to maintenance. > [Jon] With my better understanding of TTL we still have an issue if the T= TL > expires and Server A is having an extended outage. How do we recover fro= m > that? [Med] Exact. This is a service configuration problem, IMHO.=20 > ~jon > > > > > > Regards > > > > Jon > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Wed Apr 4 08:29:36 2018 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 3E37112DA0A for ; Wed, 4 Apr 2018 08:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6kCntYA4BNk3 for ; Wed, 4 Apr 2018 08:29:33 -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 C5A1B126FB3 for ; Wed, 4 Apr 2018 08:29:32 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.90_1) (envelope-from ) id 1f3kLr-0006a1-6L; Wed, 04 Apr 2018 16:29:31 +0100 From: "Jon Shallow" To: , References: <016401d3cc1c$03321200$09963600$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7F97@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DEF7F97@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Wed, 4 Apr 2018 16:29:31 +0100 Message-ID: <01a701d3cc29$ba915b10$2fb41130$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01A8_01D3CC32.1C5797D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEYhrWXRSNBek+fWBybzdJS41Z0KAI4GsKdpVV1uzA= Content-Language: en-gb Archived-At: Subject: Re: [Dots] Data Channel ACL fragments 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: Wed, 04 Apr 2018 15:29:35 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01A8_01D3CC32.1C5797D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Med et all, =20 See inline [Jon] =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 04 April 2018 15:27 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Data Channel ACL fragments =20 Re-, =20 I guess we do still need this because we wanted to achieve this functionality (especially for the non-initial fragments): =20 =3D=3D This document supports fragment filtering which adds an additional layer of protection against a DoS attack that uses non-initial fragments only. When there is only layer 3 information in the ACL entry and the fragments keyword is present, for non-initial fragments matching the ACE entry, the 'deny' or 'accept' action associated with the ACE entry will be enforced. For initial or non-fragment matching the ACE entry, the next ACE entry will be processed. When there is both layer 3 and layer 4 information in the ACE entry and the fragments keyword is present, the ACE action is conservative for both 'accept' and 'deny' actions. The actions are conservative to not accidentally deny a fragmented portion of a flow because the fragments do not contain sufficient information to match all of the filter attributes. In the 'deny' action case, instead of denying a non-initial fragment, the next ACE entry is processed. In the 'accept' case, it is assumed that the layer 4 information in the non- initial fragment, if available, matches the layer 4 information in the ACE entry. =3D=3D =20 [Jon] Actually, as I read the text above, if the additional layer of protection is required against fragmented attacks and v-[46]-fragment is = set with action =93drop=94, then any non-initial fragment is dropped =96 = fine. =20 However, the initial fragment skips this ACE test and goes onto the next ACE. Assuming that there is a =93accept=94 that matches everything else = (i.e. we like the packet apart from when it is fragmented), then the initial fragment is let through. =20 The target IP then consumes lots of RAM whilst waiting for the missing fragment segments=85=85..D(D)oS Success. =20 There is no way to drop the initial fragment with the above text other = than to =93drop=94 genuine non fragmented traffic as well. I think that = logic is flawed to drop just subsequent fragments. =20 [Jon] I also wonder how the above is going to get implemented =96 it = would be easier to say any fragmented packet sequence is not allowed (including = the initial packet) rather than only a part of the sequence which then leads = to a DoS in its own rights. =20 No? =20 [Jon] See above. I do agree that flags -> fragment -> 1 is a bit = ambiguous is its definition when used to match a packet as an acl/ace, but I do = think the match intent is that the packet is not fragmented. =20 =20 Cheers, Med =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : mercredi 4 avril 2018 15:51 =C0 : dots@ietf.org Objet : [Dots] Data Channel ACL fragments =20 Hi there, =20 Do we still need to have the fragment definition for ACEs in the data channel? =20 draft-ietf-netmod-acl-model-18 now supports fragments for ipv4 (flags + options) and implicitly in ipv6 through the next header field protocol = set to 44 (fragment extension header). =20 IPV4 =3D=3D=3D=3D grouping acl-ipv4-header-fields { description "Fields in IPv4 header."; ... leaf flags { type bits { bit reserved { position 0; description "Reserved. Must be zero."; } bit fragment { position 1; description "Setting value to 0 indicates may fragment, while setting the value to 1 indicates do not fragment."; } bit more { position 2; description "Setting the value to 0 indicates this is the last fragment, and setting the value to 1 indicates more fragments are coming."; } } description "Bit definitions for the flags field in IPv4 header."; } =20 leaf offset { type uint16 { range "20..65535"; } description "The fragment offset is measured in units of 8 octets (64 bits). The first fragment has offset zero. The length is 13 bits"; } =20 Regards =20 Jon =20 ------=_NextPart_000_01A8_01D3CC32.1C5797D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Med et all,

 

See inline = [Jon]

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com
Sent: 04 April 2018 = 15:27
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] Data Channel ACL fragments

 

Re-,

 

I guess we do still need this because we wanted to = achieve this functionality (especially for the non-initial = fragments):

 

=3D=3D

   This document supports = fragment filtering which adds an additional

   layer of protection against a = DoS attack that uses non-initial

   fragments only.  When = there is only layer 3 information in the ACL

   entry and the fragments = keyword is present, for non-initial fragments

   matching the ACE entry, the = 'deny' or 'accept' action associated with

   the ACE entry will be = enforced.  For initial or non-fragment = matching

   the ACE entry, the next ACE = entry will be processed.  When there is

   both layer 3 and layer 4 = information in the ACE entry and the

   fragments keyword is present, = the ACE action is conservative for both

   'accept' and 'deny' = actions.  The actions are conservative to = not

   accidentally deny a = fragmented portion of a flow because the

   fragments do not contain = sufficient information to match all of the

   filter attributes.  In = the 'deny' action case, instead of denying a

   non-initial fragment, the = next ACE entry is processed.  In the

   'accept' case, it is assumed = that the layer 4 information in the non-

   initial fragment, if = available, matches the layer 4 information in

   the ACE entry.

=3D=3D

 

[Jon] = Actually, as I read the text above, if the additional layer of = protection is required against fragmented attacks and v-[46]-fragment is = set with action “drop”, then any non-initial fragment is = dropped – fine.

 

However, = the initial fragment skips this ACE test and goes onto the next ACE.=A0 = Assuming that there is a “accept” that matches everything = else (i.e. we like the packet apart from when it is fragmented), then = the initial fragment is let through.

 

The target = IP then consumes lots of RAM whilst waiting for the missing fragment = segments……..D(D)oS Success.

 

There is no = way to drop the initial fragment with the above text other than to = “drop” genuine non fragmented traffic as well.=A0 I think = that logic is flawed to drop just subsequent = fragments.

 

[Jon] I = also wonder how the above is going to get implemented – it would = be easier to say any fragmented packet sequence is not allowed = (including the initial packet) rather than only a part of the sequence = which then leads to a DoS in its own rights.

 

No?

 

[Jon] See = above.=A0 I do agree that flags -> fragment -> 1 is a bit = ambiguous is its definition when used to match a packet as an acl/ace, = but I do think the match intent is that the packet is not = fragmented.

 

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] = De la part de Jon Shallow
Envoy=E9 : mercredi 4 = avril 2018 15:51
=C0 : dots@ietf.org
Objet : = [Dots] Data Channel ACL fragments

 

Hi there,

 

Do we still = need to have the fragment definition for ACEs in the data = channel?

 

draft-ietf-netmod-acl-model-18 now supports fragments = for ipv4 (flags + options) and implicitly in ipv6 through the next = header field protocol set to 44 (fragment extension = header).

 

IPV4

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

  = grouping acl-ipv4-header-fields {

    description

      "Fields in IPv4 = header.";

...

    leaf flags {

      type bits = {

        bit = reserved {

          = position 0;

          = description

         &= nbsp;  "Reserved. Must be zero.";

        = }

        bit = fragment {

          = position 1;

          = description

         &= nbsp;  "Setting value to 0 indicates may fragment, while = setting

         &= nbsp;   the value to 1 indicates do not = fragment.";

        = }

        bit more = {

          = position 2;

          = description

         &= nbsp;  "Setting the value to 0 indicates this is the last = fragment,

         &= nbsp;   and setting the value to 1 indicates more fragments = are

         &= nbsp;   coming.";

        = }

      = }

      = description

        "Bit = definitions for the flags field in IPv4 header.";

    }

 

    leaf offset {

      type uint16 = {

   =      range = "20..65535";

      }

      = description

        "The = fragment offset is measured in units of 8 octets (64 = bits).

         The = first fragment has offset zero. The length is 13 = bits";

    = }

 

Regards

 

Jon

 

------=_NextPart_000_01A8_01D3CC32.1C5797D0-- From nobody Wed Apr 4 08:40:48 2018 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 2D42812DA28 for ; Wed, 4 Apr 2018 08:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.811 X-Spam-Level: X-Spam-Status: No, score=-2.811 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_SORBS_WEB=1.5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 8d5LP6q1u-OM for ; Wed, 4 Apr 2018 08:40:44 -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 A603112DA0A for ; Wed, 4 Apr 2018 08:40:44 -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=1522856443; 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: dlp-product:dlp-version:dlp-reaction: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-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-Network-Message-Id: 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=BlZOeR9ayFA/x7PgjIBPiGzZCT0/MhV54Up4mh kwvLg=; b=qEm31yKC4TxoiLBCD4cjtCU4DCqI684MqdAywcv2 CRwVSV+a5u4+zMj4pgJbGyCirQnmH+ed377F+1r5RWCOCum3B/ rib4lZLlzFbAi3GAFBSO6G/c41SdRZ97TO7qQYQMg3bMZhdwMQ JXGdf7K/QiSrnXJ1YRAwjKzWm5PQzUk= Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 291a_749d_b6f9dd93_2f21_4cb0_a53d_979b942b5a8d; Wed, 04 Apr 2018 10:40:43 -0500 Received: from DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 4 Apr 2018 09:39:47 -0600 Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 4 Apr 2018 09:39:46 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Wed, 4 Apr 2018 09:39:46 -0600 Received: from NAM01-BN3-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.1347.2; Wed, 4 Apr 2018 09:39:44 -0600 Received: from BN6PR16MB1425.namprd16.prod.outlook.com (10.172.207.19) by BN6PR16MB1763.namprd16.prod.outlook.com (10.172.28.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.653.12; Wed, 4 Apr 2018 15:39:44 +0000 Received: from BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d]) by BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d%2]) with mapi id 15.20.0653.012; Wed, 4 Apr 2018 15:39:44 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: [Dots] Signal Channel - 300 Redirected Signaling Thread-Index: AdPMGSyCaQQbv+vLSW+0gkDbU7HOEwAAo7xAAAH7T4AAARdqYA== Date: Wed, 4 Apr 2018 15:39:44 +0000 Message-ID: References: <014f01d3cc19$2e3880e0$8aa982a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7E7B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <019901d3cc23$a93ff8e0$fbbfeaa0$@jpshallow.com> In-Reply-To: <019901d3cc23$a93ff8e0$fbbfeaa0$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [122.166.131.6] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR16MB1763; 7:JgJaKTjcY4jpMF+j1qa0M5q53drr+D+tza5g2si61P8yQQ3jLIwhwdwqPDPz6DHFi8jXBdClywHIFRbI/vp3nYhsdORPm7S16WoJ8zqw1elxPLZ25XGR/F3njjoPlFwoay/pDwTQ513KlSklUouVdmnrUoK3HwsZj3+r8OlxmApYgrF5z82RiIhZgSRC/oTbRcrad+GWJkStauOCjYjG7JRhwNm/zZMnL8tO7EwQQCAXynpASKmXF9kFYhbbz/TK x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 09235ccc-94ae-48b6-0d84-08d59a424a39 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BN6PR16MB1763; x-ms-traffictypediagnostic: BN6PR16MB1763: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(18271650672692); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231221)(944501327)(52105095)(6041310)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:BN6PR16MB1763; BCL:0; PCL:0; RULEID:; SRVR:BN6PR16MB1763; x-forefront-prvs: 0632519F33 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39380400002)(39860400002)(376002)(346002)(366004)(57704003)(13464003)(55784002)(189003)(199004)(32952001)(5250100002)(8936002)(74316002)(305945005)(7736002)(6116002)(316002)(2201001)(6506007)(59450400001)(53546011)(68736007)(486006)(478600001)(99286004)(80792005)(2501003)(102836004)(476003)(26005)(14454004)(186003)(5660300001)(86362001)(97736004)(81156014)(8676002)(81166006)(106356001)(446003)(25786009)(3660700001)(33656002)(11346002)(55016002)(229853002)(110136005)(66066001)(2906002)(3280700002)(7696005)(72206003)(105586002)(6306002)(966005)(6436002)(6246003)(9686003)(76176011)(53936002)(2900100001)(3846002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR16MB1763; H:BN6PR16MB1425.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 7UB/FB4FsLZR3wzRm7faD+j/u7rvEl1hr1Uk7FRl2mkYNIeuSnoxy16DjZflw08YLxlpDBKuSIkHjS4Wr8/umPBXVvBRRehbuM7usx32eOCXrLFPy01QdDD4uYGUreZjxUgh0yWu7XATmSCj5BMLCdxgTmDe+Iq7cuN0yy/jK14AnEqYKAzsjD1MhG0e7CGYYveH5Xu2e1HXc4VsHOOOkz73mbltHcxnRpP9Ii3Ynw1t6kNQpM6sFhMt2HNCUIdJrppMP7Mde5KAmUDnew+R6+k+c3ito3VgfnjnHSpX/DzgNgIk0TeoVRuZi4fRVR0Vo2b1uI2EeK0g3U6FS2yR6b4IukoHf0jsKHd59E60JOHa1AmRv87XbJ4oKRNtdszA7fjy4XNe5WW7ztO4Zbxnq1eN4A4x9YVJ3Wj6byyG8Nw= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 09235ccc-94ae-48b6-0d84-08d59a424a39 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2018 15:39:44.4633 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR16MB1763 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6257> : inlines <6542> : streams <1783185> : uri <2620388> Archived-At: Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling 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: Wed, 04 Apr 2018 15:40:47 -0000 The TTL value returned under alt-server-record is equivalent to the DNS TTL= value. A DDoS mitigation provider with multiple DOTS servers typically=20 re-directs a DOTS client to a different DOTS server only if the alternate D= OTS server has the capacity to handle the requests from the DOTS client. We can add the following lines to avoid loops : If the DOTS client has been redirected to a DOTS server to which it has alr= eady sent the mitigation request within the last five minutes, it MUST ignore the redirection and try reaching others servers lis= ted in the local configuration or discovered using dynamic means such as DH= CP or SRV procedures.=20 This prevents infinite ping-ponging between servers in case of redirection = loops. -Tiru > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow > Sent: Wednesday, April 4, 2018 8:16 PM > To: mohamed.boucadair@orange.com; dots@ietf.org > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling >=20 > Hi there, >=20 > See inline [Jon] >=20 > Regards >=20 > Jon >=20 > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > mohamed.boucadair@orange.com > Sent: 04 April 2018 15:07 > To: Jon Shallow; dots@ietf.org > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling >=20 > Re-, >=20 > Please see inline. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow > > Envoy=E9=A0: mercredi 4 avril 2018 15:31 =C0=A0: dots@ietf.org Objet=A0= : [Dots] > > Signal Channel - 300 Redirected Signaling > > > > Hi there, > > > > I have implemented the 300 Redirected-Signal in my DOTS code. This > > then raises some questions about usability. > > > > Usability #1 > > > > Architecture 3.2.2 Redirected Signalling > > > > 4. Having redirected the DOTS client, DOTS server A ceases sending > > server signals. The DOTS client likewise stops sending client > > signals to DOTS server A. DOTS session 1 is terminated. > > > > Clearly indicates that the original session (Client to Server A) is no > > more once redirected and only Client to Server B is in use. > > > > How is the traffic redirected back to Server A once maintenance / > > overloading etc. has finished? My assumption is that Server B sends a > > redirect to go back to Server A as Server A has no way to say over a > > now non-existent session to say "come back". >=20 > [Med] That's one possibility. This one does not require any update to the= signal- > channel specification. >=20 > Another approach would be to not require any redirect signal from server = B. > The client will remove server B's records upon the expiry of the TTL and = will fall > back to the "base" DOTS servers configuration that was provisioned to the= client > using DHCP or whatever mechanism. > [Jon] OK. The TTL is defined at, associated with the IP address level u= nder alt- > server-record, not under > ietf-dots-signal-channel:redirected-signal. The ttl definition is > ambiguous as to what it refers to and perhaps could be tightened up in th= e > language (I read it as being associated with "addr" in the sense of a DNS= TTL). >=20 > > > > Do we need to keep the existing Client to Server A session warm (or > > perhaps to probe periodically) to see if Server A is capable of > > handling the Client again by a server response extension to the > > protocol (e.g. a 3.01) >=20 > [Med] Redirect was initially introduced to manage a server overload, so I= don't > think it makes sense to probe or maintain a session with server A. > [Jon] Agreed, but I needed to raise the question. >=20 > > > > Should there be a retry period parameter added in to the 3.00 protocol > > (as I read it, ttl only refers to the IP address)? >=20 > [Med] The client will automatically switch to Server A when all alternate= records > expire. > [Jon] OK - again the 4.6 text needs to get tightened up to reflect this a= s the > intent. >=20 >=20 > > > > Usability #2 > > > > Server A says "Redirect to Server B" due to overloading. Server B > > accepts things for a while and then is instructed/decides to redirect > > traffic back to A. Server A is left still overload configured to > > redirect to B. How should the client handle this as there is no > > suitable > Server? >=20 > [Med] This is a service configuration problem. We may ask: > * the client to log the error and notify the administrator. > * and/or stop the redirection after n cycles. >=20 > Still, this does not solve the problem. > [Jon] Agreed there is a problem here >=20 > > > > I agree that there needs to be co-ordination between Server A and > > Server B, but user error may creep in. > > > > Usability #3 > > > > Server A says "Redirect to Server B" as it going to be shut down > > because of maintenance. Server B accepts things for a while and then > > is instructed (in probable user error) to redirect traffic back to A > > (perhaps because it has hit an overload condition). How should the > > client > handle this? >=20 > [Med] Isn't this a sub-case or #2? > [Jon] Yes, but I wanted to bring in Server A being alive and able to resp= ond > versus Server A down and not responding due to maintenance. > [Jon] With my better understanding of TTL we still have an issue if the T= TL > expires and Server A is having an extended outage. How do we recover fro= m > that? > ~jon > > > > > > Regards > > > > Jon > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Thu Apr 5 00:20:38 2018 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 050B4126CF6 for ; Thu, 5 Apr 2018 00:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 C-8KC4rK4GRj for ; Thu, 5 Apr 2018 00:20:30 -0700 (PDT) Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48FE0120725 for ; Thu, 5 Apr 2018 00:20:30 -0700 (PDT) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id CF8BAC0B73; Thu, 5 Apr 2018 09:20:28 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.42]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id A88841A00B6; Thu, 5 Apr 2018 09:20:28 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM41.corporate.adroot.infra.ftgroup ([fe80::c845:f762:8997:ec86%19]) with mapi id 14.03.0382.000; Thu, 5 Apr 2018 09:20:28 +0200 From: To: "Konda, Tirumaleswar Reddy" , "Jon Shallow" , "dots@ietf.org" Thread-Topic: [Dots] Signal Channel - 300 Redirected Signaling Thread-Index: AdPMGSyCsK17va5Vv37fpNudI6+9awAAo7xAAAH7T4AAARdqYAAhi77w Date: Thu, 5 Apr 2018 07:20:28 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DEF8524@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <014f01d3cc19$2e3880e0$8aa982a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7E7B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <019901d3cc23$a93ff8e0$fbbfeaa0$@jpshallow.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling 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, 05 Apr 2018 07:20:34 -0000 Hi Tiru,=20 Works for me. =20 I updated the draft with the text additions that were discussed in this thr= ead. The changes can be found at: =20 https://github.com/boucadair/draft-ietf-dots-signal-channel/blob/master/dra= ft-ietf-dots-signal-channel.txt=20 Cheers, Med > -----Message d'origine----- > De=A0: Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.c= om] > Envoy=E9=A0: mercredi 4 avril 2018 17:40 > =C0=A0: Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org > Objet=A0: RE: [Dots] Signal Channel - 300 Redirected Signaling >=20 > The TTL value returned under alt-server-record is equivalent to the DNS T= TL > value. A DDoS mitigation provider with multiple DOTS servers typically > re-directs a DOTS client to a different DOTS server only if the alternate > DOTS server has the capacity to handle the requests from the DOTS client. >=20 > We can add the following lines to avoid loops : >=20 > If the DOTS client has been redirected to a DOTS server to which it has > already sent the mitigation request within the last five > minutes, it MUST ignore the redirection and try reaching others servers > listed in the local configuration or discovered using dynamic means such = as > DHCP or SRV procedures. > This prevents infinite ping-ponging between servers in case of redirectio= n > loops. >=20 > -Tiru >=20 > > -----Original Message----- > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow > > Sent: Wednesday, April 4, 2018 8:16 PM > > To: mohamed.boucadair@orange.com; dots@ietf.org > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > Hi there, > > > > See inline [Jon] > > > > Regards > > > > Jon > > > > -----Original Message----- > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > mohamed.boucadair@orange.com > > Sent: 04 April 2018 15:07 > > To: Jon Shallow; dots@ietf.org > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > Re-, > > > > Please see inline. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow > > > Envoy=E9=A0: mercredi 4 avril 2018 15:31 =C0=A0: dots@ietf.org Objet= =A0: [Dots] > > > Signal Channel - 300 Redirected Signaling > > > > > > Hi there, > > > > > > I have implemented the 300 Redirected-Signal in my DOTS code. This > > > then raises some questions about usability. > > > > > > Usability #1 > > > > > > Architecture 3.2.2 Redirected Signalling > > > > > > 4. Having redirected the DOTS client, DOTS server A ceases sendin= g > > > server signals. The DOTS client likewise stops sending client > > > signals to DOTS server A. DOTS session 1 is terminated. > > > > > > Clearly indicates that the original session (Client to Server A) is n= o > > > more once redirected and only Client to Server B is in use. > > > > > > How is the traffic redirected back to Server A once maintenance / > > > overloading etc. has finished? My assumption is that Server B sends = a > > > redirect to go back to Server A as Server A has no way to say over a > > > now non-existent session to say "come back". > > > > [Med] That's one possibility. This one does not require any update to t= he > signal- > > channel specification. > > > > Another approach would be to not require any redirect signal from serve= r B. > > The client will remove server B's records upon the expiry of the TTL an= d > will fall > > back to the "base" DOTS servers configuration that was provisioned to t= he > client > > using DHCP or whatever mechanism. > > [Jon] OK. The TTL is defined at, associated with the IP address level > under alt- > > server-record, not under > > ietf-dots-signal-channel:redirected-signal. The ttl definition is > > ambiguous as to what it refers to and perhaps could be tightened up in = the > > language (I read it as being associated with "addr" in the sense of a D= NS > TTL). > > > > > > > > Do we need to keep the existing Client to Server A session warm (or > > > perhaps to probe periodically) to see if Server A is capable of > > > handling the Client again by a server response extension to the > > > protocol (e.g. a 3.01) > > > > [Med] Redirect was initially introduced to manage a server overload, so= I > don't > > think it makes sense to probe or maintain a session with server A. > > [Jon] Agreed, but I needed to raise the question. > > > > > > > > Should there be a retry period parameter added in to the 3.00 protoco= l > > > (as I read it, ttl only refers to the IP address)? > > > > [Med] The client will automatically switch to Server A when all alterna= te > records > > expire. > > [Jon] OK - again the 4.6 text needs to get tightened up to reflect this= as > the > > intent. > > > > > > > > > > Usability #2 > > > > > > Server A says "Redirect to Server B" due to overloading. Server B > > > accepts things for a while and then is instructed/decides to redirect > > > traffic back to A. Server A is left still overload configured to > > > redirect to B. How should the client handle this as there is no > > > suitable > > Server? > > > > [Med] This is a service configuration problem. We may ask: > > * the client to log the error and notify the administrator. > > * and/or stop the redirection after n cycles. > > > > Still, this does not solve the problem. > > [Jon] Agreed there is a problem here > > > > > > > > I agree that there needs to be co-ordination between Server A and > > > Server B, but user error may creep in. > > > > > > Usability #3 > > > > > > Server A says "Redirect to Server B" as it going to be shut down > > > because of maintenance. Server B accepts things for a while and then > > > is instructed (in probable user error) to redirect traffic back to A > > > (perhaps because it has hit an overload condition). How should the > > > client > > handle this? > > > > [Med] Isn't this a sub-case or #2? > > [Jon] Yes, but I wanted to bring in Server A being alive and able to > respond > > versus Server A down and not responding due to maintenance. > > [Jon] With my better understanding of TTL we still have an issue if the= TTL > > expires and Server A is having an extended outage. How do we recover f= rom > > that? > > ~jon > > > > > > > > > Regards > > > > > > Jon > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots From nobody Thu Apr 5 01:05:24 2018 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 1347C120725 for ; Thu, 5 Apr 2018 01:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2KGB6olnmo7 for ; Thu, 5 Apr 2018 01:05:18 -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 4948B1200F1 for ; Thu, 5 Apr 2018 01:05:18 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.90_1) (envelope-from ) id 1f3ztT-00077U-GO; Thu, 05 Apr 2018 09:05:15 +0100 From: "Jon Shallow" To: , "Konda, Tirumaleswar Reddy" , References: <014f01d3cc19$2e3880e0$8aa982a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7E7B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <019901d3cc23$a93ff8e0$fbbfeaa0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8524@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DEF8524@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Thu, 5 Apr 2018 09:05:16 +0100 Message-ID: <004e01d3ccb4$d505e7f0$7f11b7d0$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ5xX4UsK17va5Vv37fpNudI6+9awKIdnG+AkIt6UkCuIhgoQJj4oJpolaboIA= Content-Language: en-gb Archived-At: Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling 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, 05 Apr 2018 08:05:21 -0000 Hi Med, Thanks for this refresh to 4.6 Redirected Signaling Some comments #1 The DOTS server can return the error response code 3.00 in response to a PUT request from the DOTS client or convey the error response code 3.00 in a unidirectional notification response from the DOTS server. Why is this limited to a PUT request and/or unidirectional notification response? - Surely, any response, unsolicited or otherwise can contain a 3.00 - If Observe is not in use, then any unsolicited notification response = will potentially get rejected by the coap library layer, so a DOTS Server = cannot signal maintenance outage other than by closing the session. - I missed this the last review - sorry #2 If the DOTS client has been redirected to a DOTS server to which it has already sent the mitigation request within the last five (5) minutes, it MUST ignore the redirection and try to contact other DOTS s/ has already sent the mitigation request/ has already communicated = with/ #3 A DOTS client MUST NOT use an alternate IP address to contact its DOTS server upon expiry of the associated TTL. To remove ambiguity over the use of FQDN, this could read A DOTS client MUST NOT use an alternate IP address to contact its DOTS server upon expiry of the associated TTL. Furthermore, a = DOTS Client MUST NOT use the alt-server FQDN if all of the alt-server-records have expired. Or alternatively alt-server: FQDN of an alternate DOTS server. This could read alt-server: FQDN of an alternate DOTS server. This FQDN is not to = be used for looking up IP addresses to use, but is there for the SNI = extension (7.1. (D)TLS Protocol Profile) Regards Jon -----Original Message----- From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 05 April 2018 08:20 To: Konda, Tirumaleswar Reddy; Jon Shallow; dots@ietf.org Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling Hi Tiru,=20 Works for me. =20 I updated the draft with the text additions that were discussed in this thread. The changes can be found at: =20 https://github.com/boucadair/draft-ietf-dots-signal-channel/blob/master/d= raf t-ietf-dots-signal-channel.txt=20 Cheers, Med > -----Message d'origine----- > De=A0: Konda, Tirumaleswar Reddy=20 > [mailto:TirumaleswarReddy_Konda@McAfee.com] > Envoy=E9=A0: mercredi 4 avril 2018 17:40 > =C0=A0: Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org = Objet=A0: RE:=20 > [Dots] Signal Channel - 300 Redirected Signaling >=20 > The TTL value returned under alt-server-record is equivalent to the=20 > DNS TTL value. A DDoS mitigation provider with multiple DOTS servers=20 > typically re-directs a DOTS client to a different DOTS server only if=20 > the alternate DOTS server has the capacity to handle the requests from = the DOTS client. >=20 > We can add the following lines to avoid loops : >=20 > If the DOTS client has been redirected to a DOTS server to which it=20 > has already sent the mitigation request within the last five minutes,=20 > it MUST ignore the redirection and try reaching others servers listed=20 > in the local configuration or discovered using dynamic means such as=20 > DHCP or SRV procedures. > This prevents infinite ping-ponging between servers in case of=20 > redirection loops. >=20 > -Tiru >=20 > > -----Original Message----- > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow > > Sent: Wednesday, April 4, 2018 8:16 PM > > To: mohamed.boucadair@orange.com; dots@ietf.org > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > Hi there, > > > > See inline [Jon] > > > > Regards > > > > Jon > > > > -----Original Message----- > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of=20 > > mohamed.boucadair@orange.com > > Sent: 04 April 2018 15:07 > > To: Jon Shallow; dots@ietf.org > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > Re-, > > > > Please see inline. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Jon = Shallow=20 > > > Envoy=E9=A0: mercredi 4 avril 2018 15:31 =C0=A0: dots@ietf.org = Objet=A0:=20 > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > Hi there, > > > > > > I have implemented the 300 Redirected-Signal in my DOTS code. =20 > > > This then raises some questions about usability. > > > > > > Usability #1 > > > > > > Architecture 3.2.2 Redirected Signalling > > > > > > 4. Having redirected the DOTS client, DOTS server A ceases = sending > > > server signals. The DOTS client likewise stops sending = client > > > signals to DOTS server A. DOTS session 1 is terminated. > > > > > > Clearly indicates that the original session (Client to Server A)=20 > > > is no more once redirected and only Client to Server B is in use. > > > > > > How is the traffic redirected back to Server A once maintenance /=20 > > > overloading etc. has finished? My assumption is that Server B=20 > > > sends a redirect to go back to Server A as Server A has no way to=20 > > > say over a now non-existent session to say "come back". > > > > [Med] That's one possibility. This one does not require any update=20 > > to the > signal- > > channel specification. > > > > Another approach would be to not require any redirect signal from = server B. > > The client will remove server B's records upon the expiry of the TTL = > > and > will fall > > back to the "base" DOTS servers configuration that was provisioned=20 > > to the > client > > using DHCP or whatever mechanism. > > [Jon] OK. The TTL is defined at, associated with the IP address=20 > > level > under alt- > > server-record, not under > > ietf-dots-signal-channel:redirected-signal. The ttl definition is > > ambiguous as to what it refers to and perhaps could be tightened up=20 > > in the language (I read it as being associated with "addr" in the=20 > > sense of a DNS > TTL). > > > > > > > > Do we need to keep the existing Client to Server A session warm=20 > > > (or perhaps to probe periodically) to see if Server A is capable=20 > > > of handling the Client again by a server response extension to the = > > > protocol (e.g. a 3.01) > > > > [Med] Redirect was initially introduced to manage a server overload, = > > so I > don't > > think it makes sense to probe or maintain a session with server A. > > [Jon] Agreed, but I needed to raise the question. > > > > > > > > Should there be a retry period parameter added in to the 3.00=20 > > > protocol (as I read it, ttl only refers to the IP address)? > > > > [Med] The client will automatically switch to Server A when all=20 > > alternate > records > > expire. > > [Jon] OK - again the 4.6 text needs to get tightened up to reflect=20 > > this as > the > > intent. > > > > > > > > > > Usability #2 > > > > > > Server A says "Redirect to Server B" due to overloading. Server B = > > > accepts things for a while and then is instructed/decides to=20 > > > redirect traffic back to A. Server A is left still overload=20 > > > configured to redirect to B. How should the client handle this as = > > > there is no suitable > > Server? > > > > [Med] This is a service configuration problem. We may ask: > > * the client to log the error and notify the administrator. > > * and/or stop the redirection after n cycles. > > > > Still, this does not solve the problem. > > [Jon] Agreed there is a problem here > > > > > > > > I agree that there needs to be co-ordination between Server A and=20 > > > Server B, but user error may creep in. > > > > > > Usability #3 > > > > > > Server A says "Redirect to Server B" as it going to be shut down=20 > > > because of maintenance. Server B accepts things for a while and=20 > > > then is instructed (in probable user error) to redirect traffic=20 > > > back to A (perhaps because it has hit an overload condition). How = > > > should the client > > handle this? > > > > [Med] Isn't this a sub-case or #2? > > [Jon] Yes, but I wanted to bring in Server A being alive and able to > respond > > versus Server A down and not responding due to maintenance. > > [Jon] With my better understanding of TTL we still have an issue if=20 > > the TTL expires and Server A is having an extended outage. How do=20 > > we recover from that? > > ~jon > > > > > > > > > Regards > > > > > > Jon > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Thu Apr 5 01:23:14 2018 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 6ED7E126DED for ; Thu, 5 Apr 2018 01:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 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, T_RP_MATCHES_RCVD=-0.01, 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 YiptJNQrEKQq for ; Thu, 5 Apr 2018 01:23:04 -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 C75B5120725 for ; Thu, 5 Apr 2018 01:23:03 -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=1522916583; 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: dlp-product:dlp-version:dlp-reaction: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: authentication-results:x-microsoft-antispam-prvs: x-exchange-antispam-report-test:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: 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=RkF9WdFUgBbZUU+t7ipp60K9YRyMy6M5+WAWvl JfBu4=; b=NjNvdtXu5AStgaoRkgLLaKfAMpDyc20fGM50Y/4C smHDBrtkf/LdEYePJM9crLk62V3KdkOvEm34WDMryOka2/i8Lk 49JIAGOcIYpO7044sn11B+CQiZfvmvMhnfX/hBS28xElbpU95y /aVDU9yaWlCtIphv0gJGJ0uOPHLghHM= Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 68d0_3da9_1745881f_576f_4553_b385_ddb8c8279e7b; Thu, 05 Apr 2018 03:23:02 -0500 Received: from DNVEXUSR1N14.corpzone.internalzone.com (10.44.48.87) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 5 Apr 2018 02:22:55 -0600 Received: from DNVEXUSR1N11.corpzone.internalzone.com (10.44.48.84) by DNVEXUSR1N14.corpzone.internalzone.com (10.44.48.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 5 Apr 2018 02:22:54 -0600 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXUSR1N11.corpzone.internalzone.com (10.44.48.84) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Thu, 5 Apr 2018 02:22:54 -0600 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (10.44.176.240) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 5 Apr 2018 02:22:52 -0600 Received: from BN6PR16MB1425.namprd16.prod.outlook.com (10.172.207.19) by BN6PR16MB1683.namprd16.prod.outlook.com (10.172.28.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.653.12; Thu, 5 Apr 2018 08:22:51 +0000 Received: from BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d]) by BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d%2]) with mapi id 15.20.0653.012; Thu, 5 Apr 2018 08:22:51 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: [Dots] Data Channel ACL fragments Thread-Index: AdPMHAMfDWFlXvb3TSeAr5MVkYUzIgAA3pEAAAKPJoAAIuTfcA== Date: Thu, 5 Apr 2018 08:22:50 +0000 Message-ID: References: <016401d3cc1c$03321200$09963600$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7F97@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <01a701d3cc29$ba915b10$2fb41130$@jpshallow.com> In-Reply-To: <01a701d3cc29$ba915b10$2fb41130$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR16MB1683; 7:P13AxRRHLFoXdPrn/fbi+zAGQmFeFcd85uBiTWhSZ6MS7AO3S1+mpKdARg1BD62veojfx6KkCL5rGjk88bnMwVEHKuvLPGxbCLsvYcYxWbTUv0NqDHuyM5IOiP9z3aOz84CYYwRmyoFY3+9tpORwpXBbkISYmhAxxA7RqdjnM/joLl2tu4RKylOJlOCUNzQWGu7fLwv64sU3uh7wBI2hJyhKVGFervin/8SFksUyQ2jrVToSNU7nU3vv2mdrlQDN x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: a28889b4-fc40-4325-f636-08d59ace6c31 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BN6PR16MB1683; x-ms-traffictypediagnostic: BN6PR16MB1683: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(192374486261705)(114627819485645)(95692535739014)(18271650672692)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231221)(944501327)(52105095)(10201501046)(3002001)(93006095)(93001095)(6041310)(20161123562045)(20161123560045)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:BN6PR16MB1683; BCL:0; PCL:0; RULEID:; SRVR:BN6PR16MB1683; x-forefront-prvs: 06339BAE63 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(376002)(366004)(346002)(39380400002)(32952001)(199004)(51444003)(189003)(53546011)(6506007)(606006)(3280700002)(229853002)(81156014)(8676002)(99286004)(81166006)(19609705001)(9326002)(3846002)(6116002)(72206003)(186003)(26005)(74316002)(2906002)(790700001)(76176011)(33656002)(8936002)(7696005)(97736004)(316002)(6246003)(68736007)(106356001)(2900100001)(53936002)(66066001)(5250100002)(478600001)(7736002)(105586002)(80792005)(59450400001)(2501003)(6436002)(476003)(5660300001)(966005)(110136005)(86362001)(14454004)(11346002)(9686003)(54896002)(6306002)(55016002)(486006)(446003)(236005)(25786009)(3660700001)(2201001)(102836004)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR16MB1683; H:BN6PR16MB1425.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: RuAu7h0Wb5AgoapFgSqus+T9VzIjkkFa8YDnrcuaopVSVsmu5N88WeL8RbXBeBWcYqRsLwb34RNVVcE8t85/sM6ABBqmEU0EFq/TY8VjPtN2W0/Pt0mmT7SCMKJjCPOqUPBOaY6+fUkiDgWpPNnOPqu2Cipi0R49cHyCfEIygn8okQWxUP4Zz4fTuGNmPLGnCY40fg2SnA6fMHMnwocyYvKDejxXtmsBusX4unQhQeDDcrC0G7M6COA1haI1mwVcC29CYy0qyhFmoj5V0rMp1UHYv2CQQx90rJFI3D1Gwh35KTCCJYeLvZr+/AINchdE7qRolWnkfpTVqZilYdAlx0e9PwjHlaem00+CZkTdzcVtjp0Re8NOa7sXyHpX8PNPHWIDSpVoYdVLaNWbPIavLfnU+Oy71NSwtfGr5gKViKg= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR16MB14257B016ED90BC00A9BA3E5EABB0BN6PR16MB1425namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: a28889b4-fc40-4325-f636-08d59ace6c31 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Apr 2018 08:22:50.8774 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR16MB1683 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6257> : inlines <6547> : streams <1783251> : uri <2620774> Archived-At: Subject: Re: [Dots] Data Channel ACL fragments 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, 05 Apr 2018 08:23:11 -0000 --_000_BN6PR16MB14257B016ED90BC00A9BA3E5EABB0BN6PR16MB1425namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jon, The fragment definition to protect the target from attacks that use non-ini= tial fragments only. We followed the Security considerations for IP filtering given in Section 2= of https://www.ietf.org/rfc/rfc1858.txt to drop the initial fragment, so t= he non-initial fragments will be discarded by the destination host (its imp= lemented and discussed in https://www.cisco.com/c/en/us/support/docs/ip/gen= eric-routing-encapsulation-gre/8014-acl-wp.html). -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Wednesday, April 4, 2018 9:00 PM To: mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] Data Channel ACL fragments Hi Med et all, See inline [Jon] Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 04 April 2018 15:27 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Data Channel ACL fragments Re-, I guess we do still need this because we wanted to achieve this functionali= ty (especially for the non-initial fragments): =3D=3D This document supports fragment filtering which adds an additional layer of protection against a DoS attack that uses non-initial fragments only. When there is only layer 3 information in the ACL entry and the fragments keyword is present, for non-initial fragments matching the ACE entry, the 'deny' or 'accept' action associated with the ACE entry will be enforced. For initial or non-fragment matching the ACE entry, the next ACE entry will be processed. When there is both layer 3 and layer 4 information in the ACE entry and the fragments keyword is present, the ACE action is conservative for both 'accept' and 'deny' actions. The actions are conservative to not accidentally deny a fragmented portion of a flow because the fragments do not contain sufficient information to match all of the filter attributes. In the 'deny' action case, instead of denying a non-initial fragment, the next ACE entry is processed. In the 'accept' case, it is assumed that the layer 4 information in the non- initial fragment, if available, matches the layer 4 information in the ACE entry. =3D=3D [Jon] Actually, as I read the text above, if the additional layer of protec= tion is required against fragmented attacks and v-[46]-fragment is set with= action "drop", then any non-initial fragment is dropped - fine. However, the initial fragment skips this ACE test and goes onto the next AC= E. Assuming that there is a "accept" that matches everything else (i.e. we= like the packet apart from when it is fragmented), then the initial fragme= nt is let through. The target IP then consumes lots of RAM whilst waiting for the missing frag= ment segments........D(D)oS Success. There is no way to drop the initial fragment with the above text other than= to "drop" genuine non fragmented traffic as well. I think that logic is f= lawed to drop just subsequent fragments. [Jon] I also wonder how the above is going to get implemented - it would be= easier to say any fragmented packet sequence is not allowed (including the= initial packet) rather than only a part of the sequence which then leads t= o a DoS in its own rights. No? [Jon] See above. I do agree that flags -> fragment -> 1 is a bit ambiguous= is its definition when used to match a packet as an acl/ace, but I do thin= k the match intent is that the packet is not fragmented. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : mercredi 4 avril 2018 15:51 =C0 : dots@ietf.org Objet : [Dots] Data Channel ACL fragments Hi there, Do we still need to have the fragment definition for ACEs in the data chann= el? draft-ietf-netmod-acl-model-18 now supports fragments for ipv4 (flags + opt= ions) and implicitly in ipv6 through the next header field protocol set to = 44 (fragment extension header). IPV4 =3D=3D=3D=3D grouping acl-ipv4-header-fields { description "Fields in IPv4 header."; ... leaf flags { type bits { bit reserved { position 0; description "Reserved. Must be zero."; } bit fragment { position 1; description "Setting value to 0 indicates may fragment, while setting the value to 1 indicates do not fragment."; } bit more { position 2; description "Setting the value to 0 indicates this is the last fragment, and setting the value to 1 indicates more fragments are coming."; } } description "Bit definitions for the flags field in IPv4 header."; } leaf offset { type uint16 { range "20..65535"; } description "The fragment offset is measured in units of 8 octets (64 bits). The first fragment has offset zero. The length is 13 bits"; } Regards Jon --_000_BN6PR16MB14257B016ED90BC00A9BA3E5EABB0BN6PR16MB1425namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jon,

&nbs= p;

The fragm= ent definition to protect the target from attacks that use non-initial frag= ments only.

We follow= ed the Security considerations for IP filtering given in Section 2 of https://www.ietf.org/rfc/r= fc1858.txt to drop the initial fragment, so the non-initial fragments w= ill be discarded by the destination host (its implemented and discussed in https://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulation= -gre/8014-acl-wp.html).

&nbs= p;

-Tiru

 

From:<= /span> Dots [mailto:dots-bou= nces@ietf.org] On Behalf Of Jon Shallow
Sent: Wednesday, April 4, 2018 9:00 PM
To: mohamed.boucadair@orange.com; dots@ietf.org
Subject: Re: [Dots] Data Channel ACL fragments

 

Hi Med = et all,

&n= bsp;

See inl= ine [Jon]

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 04 April 2018 15:27
To: Jon Shallow; dots@ietf.org<= br> Subject: Re: [Dots] Data Channel ACL fragments

 

Re-,

 

I guess we do still need this because we wante= d to achieve this functionality (especially for the non-initial fragments):=

 

=3D=3D

   This document support= s fragment filtering which adds an additional

   layer of protection a= gainst a DoS attack that uses non-initial

   fragments only. = When there is only layer 3 information in the ACL

   entry and the fragmen= ts keyword is present, for non-initial fragments

   matching the ACE entr= y, the 'deny' or 'accept' action associated with

   the ACE entry will be= enforced.  For initial or non-fragment matching

   the ACE entry, the ne= xt ACE entry will be processed.  When there is

   both layer 3 and laye= r 4 information in the ACE entry and the

   fragments keyword is = present, the ACE action is conservative for both

   'accept' and 'deny' a= ctions.  The actions are conservative to not

   accidentally deny a f= ragmented portion of a flow because the

   fragments do not cont= ain sufficient information to match all of the

   filter attributes.&nb= sp; In the 'deny' action case, instead of denying a

   non-initial fragment,= the next ACE entry is processed.  In the

   'accept' case, it is = assumed that the layer 4 information in the non-

   initial fragment, if = available, matches the layer 4 information in

   the ACE entry.

=3D=3D

 

[Jon] Actually, as I r= ead the text above, if the additional layer of protection is required again= st fragmented attacks and v-[46]-fragment is set with action “drop= 221;, then any non-initial fragment is dropped – fine.

 

However, the initial f= ragment skips this ACE test and goes onto the next ACE.  Assuming that= there is a “accept” that matches everything else (i.e. we like= the packet apart from when it is fragmented), then the initial fragment is let through.

 

The target IP then con= sumes lots of RAM whilst waiting for the missing fragment segments…&#= 8230;..D(D)oS Success.

 

There is no way to dro= p the initial fragment with the above text other than to “drop”= genuine non fragmented traffic as well.  I think that logic is flawed= to drop just subsequent fragments.

 

[Jon] I also wonder ho= w the above is going to get implemented – it would be easier to say a= ny fragmented packet sequence is not allowed (including the initial packet)= rather than only a part of the sequence which then leads to a DoS in its own rights.

 

No?

 

[Jon] See above. = I do agree that flags -> fragment -> 1 is a bit ambiguous is its def= inition when used to match a packet as an acl/ace, but I do think the match= intent is that the packet is not fragmented.

 

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow
Envoy=E9 : mercredi 4 avril 2018 15:51
=C0 : dots@ietf.org
Objet : [Dots] Data Channel ACL fragments

 

Hi there,

 

Do we still need to have the fr= agment definition for ACEs in the data channel?

 

draft-ietf-netmod-acl-model-18 = now supports fragments for ipv4 (flags + options) and implicitly in ipv= 6 through the next header field protocol set to 44 (fragment extension head= er).

 

IPV4

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

  grouping acl-ipv4-header= -fields {

    description<= o:p>

      = "Fields in IPv4 header.";

...

    leaf flags {=

      = type bits {

     &= nbsp;  bit reserved {

     &= nbsp;    position 0;

     &= nbsp;    description

     &= nbsp;      "Reserved. Must be zero.";

     &= nbsp;  }

     &= nbsp;  bit fragment {

     &= nbsp;    position 1;

     &= nbsp;    description

     &= nbsp;      "Setting value to 0 indicates may = fragment, while setting

     &= nbsp;       the value to 1 indicates do not f= ragment.";

     &= nbsp;  }

     &= nbsp;  bit more {

     &= nbsp;    position 2;

     &= nbsp;    description

     &= nbsp;      "Setting the value to 0 indicates = this is the last fragment,

     &= nbsp;       and setting the value to 1 indica= tes more fragments are

     &= nbsp;       coming.";<= /p>

     &= nbsp;  }

      = }

      = description

     &= nbsp;  "Bit definitions for the flags field in IPv4 header."= ;

    }=

 

    leaf offset = {

      = type uint16 {

      =   range "20..65535";

      = }

      = description

     &= nbsp;  "The fragment offset is measured in units of 8 octets (64 = bits).

     &= nbsp;   The first fragment has offset zero. The length is 13 bits= ";

    }=

 

Regards

 

Jon

 

--_000_BN6PR16MB14257B016ED90BC00A9BA3E5EABB0BN6PR16MB1425namp_-- From nobody Thu Apr 5 01:50:10 2018 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 E8CA8126DED for ; Thu, 5 Apr 2018 01:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 M05A_daTA1Jp for ; Thu, 5 Apr 2018 01:50:06 -0700 (PDT) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6936126DC2 for ; Thu, 5 Apr 2018 01:50:05 -0700 (PDT) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 41A661803AC; Thu, 5 Apr 2018 10:50:04 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.33]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id E280E4007E; Thu, 5 Apr 2018 10:50:03 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM42.corporate.adroot.infra.ftgroup ([fe80::d5fd:9c7d:2ee3:39d9%19]) with mapi id 14.03.0382.000; Thu, 5 Apr 2018 10:50:03 +0200 From: To: Jon Shallow , "Konda, Tirumaleswar Reddy" , "dots@ietf.org" Thread-Topic: [Dots] Signal Channel - 300 Redirected Signaling Thread-Index: AQJ5xX4UsK17va5Vv37fpNudI6+9awKIdnG+AkIt6UkCuIhgoQJj4oJpolaboICAABQa8A== Date: Thu, 5 Apr 2018 08:50:02 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DEF861C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <014f01d3cc19$2e3880e0$8aa982a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7E7B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <019901d3cc23$a93ff8e0$fbbfeaa0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8524@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <004e01d3ccb4$d505e7f0$7f11b7d0$@jpshallow.com> In-Reply-To: <004e01d3ccb4$d505e7f0$7f11b7d0$@jpshallow.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling 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, 05 Apr 2018 08:50:09 -0000 Re-, Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > Envoy=E9=A0: jeudi 5 avril 2018 10:05 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; dots@ietf.o= rg > Objet=A0: RE: [Dots] Signal Channel - 300 Redirected Signaling >=20 > Hi Med, >=20 > Thanks for this refresh to 4.6 Redirected Signaling >=20 > Some comments >=20 > #1 >=20 > The DOTS server can return the error response code 3.00 in response > to a PUT request from the DOTS client or convey the error response > code 3.00 in a unidirectional notification response from the DOTS > server. >=20 > Why is this limited to a PUT request and/or unidirectional notification > response? > - Surely, any response, unsolicited or otherwise can contain a 3.00 > - If Observe is not in use, then any unsolicited notification response wi= ll > potentially get rejected by the coap library layer, so a DOTS Server cann= ot > signal maintenance outage other than by closing the session. > - I missed this the last review - sorry >=20 [Med] There is no restriction in the text:=20 If a DOTS server wants to redirect a DOTS client to an alternative DOTS server for a signal session, then the response code 3.00 (alternate server) will be returned in the response to the DOTS client. The text you quoted is about a case in which redirect is likely : " The DOT= S server **can** return the error response code.." > #2 >=20 > If the DOTS client has been redirected to a DOTS server to which it > has already sent the mitigation request within the last five (5) > minutes, it MUST ignore the redirection and try to contact other DOTS >=20 > s/ has already sent the mitigation request/ has already communicated with= / [Med] Fixed. >=20 > #3 >=20 > A DOTS client MUST NOT use an alternate IP address to contact its > DOTS server upon expiry of the associated TTL. >=20 > To remove ambiguity over the use of FQDN, this could read >=20 > A DOTS client MUST NOT use an alternate IP address to contact its > DOTS server upon expiry of the associated TTL. Furthermore, a DOTS > Client MUST NOT use the alt-server FQDN if all of the > alt-server-records > have expired. >=20 [Med] I can add this to remove ambiguity.=20 > Or alternatively >=20 > alt-server: FQDN of an alternate DOTS server. >=20 > This could read >=20 > alt-server: FQDN of an alternate DOTS server. This FQDN is not to be > used for looking up IP addresses to use, but is there for the SNI extensi= on > (7.1. (D)TLS Protocol Profile) >=20 >=20 > Regards >=20 > Jon > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > mohamed.boucadair@orange.com > Sent: 05 April 2018 08:20 > To: Konda, Tirumaleswar Reddy; Jon Shallow; dots@ietf.org > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling >=20 > Hi Tiru, >=20 > Works for me. >=20 > I updated the draft with the text additions that were discussed in this > thread. The changes can be found at: > https://github.com/boucadair/draft-ietf-dots-signal-channel/blob/master/d= raf > t-ietf-dots-signal-channel.txt >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Konda, Tirumaleswar Reddy > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > Envoy=E9=A0: mercredi 4 avril 2018 17:40 > > =C0=A0: Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet=A0:= RE: > > [Dots] Signal Channel - 300 Redirected Signaling > > > > The TTL value returned under alt-server-record is equivalent to the > > DNS TTL value. A DDoS mitigation provider with multiple DOTS servers > > typically re-directs a DOTS client to a different DOTS server only if > > the alternate DOTS server has the capacity to handle the requests from = the > DOTS client. > > > > We can add the following lines to avoid loops : > > > > If the DOTS client has been redirected to a DOTS server to which it > > has already sent the mitigation request within the last five minutes, > > it MUST ignore the redirection and try reaching others servers listed > > in the local configuration or discovered using dynamic means such as > > DHCP or SRV procedures. > > This prevents infinite ping-ponging between servers in case of > > redirection loops. > > > > -Tiru > > > > > -----Original Message----- > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow > > > Sent: Wednesday, April 4, 2018 8:16 PM > > > To: mohamed.boucadair@orange.com; dots@ietf.org > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > Hi there, > > > > > > See inline [Jon] > > > > > > Regards > > > > > > Jon > > > > > > -----Original Message----- > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > > mohamed.boucadair@orange.com > > > Sent: 04 April 2018 15:07 > > > To: Jon Shallow; dots@ietf.org > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > Re-, > > > > > > Please see inline. > > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallo= w > > > > Envoy=E9=A0: mercredi 4 avril 2018 15:31 =C0=A0: dots@ietf.org Obje= t=A0: > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > Hi there, > > > > > > > > I have implemented the 300 Redirected-Signal in my DOTS code. > > > > This then raises some questions about usability. > > > > > > > > Usability #1 > > > > > > > > Architecture 3.2.2 Redirected Signalling > > > > > > > > 4. Having redirected the DOTS client, DOTS server A ceases send= ing > > > > server signals. The DOTS client likewise stops sending clie= nt > > > > signals to DOTS server A. DOTS session 1 is terminated. > > > > > > > > Clearly indicates that the original session (Client to Server A) > > > > is no more once redirected and only Client to Server B is in use. > > > > > > > > How is the traffic redirected back to Server A once maintenance / > > > > overloading etc. has finished? My assumption is that Server B > > > > sends a redirect to go back to Server A as Server A has no way to > > > > say over a now non-existent session to say "come back". > > > > > > [Med] That's one possibility. This one does not require any update > > > to the > > signal- > > > channel specification. > > > > > > Another approach would be to not require any redirect signal from ser= ver > B. > > > The client will remove server B's records upon the expiry of the TTL > > > and > > will fall > > > back to the "base" DOTS servers configuration that was provisioned > > > to the > > client > > > using DHCP or whatever mechanism. > > > [Jon] OK. The TTL is defined at, associated with the IP address > > > level > > under alt- > > > server-record, not under > > > ietf-dots-signal-channel:redirected-signal. The ttl definition is > > > ambiguous as to what it refers to and perhaps could be tightened up > > > in the language (I read it as being associated with "addr" in the > > > sense of a DNS > > TTL). > > > > > > > > > > > Do we need to keep the existing Client to Server A session warm > > > > (or perhaps to probe periodically) to see if Server A is capable > > > > of handling the Client again by a server response extension to the > > > > protocol (e.g. a 3.01) > > > > > > [Med] Redirect was initially introduced to manage a server overload, > > > so I > > don't > > > think it makes sense to probe or maintain a session with server A. > > > [Jon] Agreed, but I needed to raise the question. > > > > > > > > > > > Should there be a retry period parameter added in to the 3.00 > > > > protocol (as I read it, ttl only refers to the IP address)? > > > > > > [Med] The client will automatically switch to Server A when all > > > alternate > > records > > > expire. > > > [Jon] OK - again the 4.6 text needs to get tightened up to reflect > > > this as > > the > > > intent. > > > > > > > > > > > > > > Usability #2 > > > > > > > > Server A says "Redirect to Server B" due to overloading. Server B > > > > accepts things for a while and then is instructed/decides to > > > > redirect traffic back to A. Server A is left still overload > > > > configured to redirect to B. How should the client handle this as > > > > there is no suitable > > > Server? > > > > > > [Med] This is a service configuration problem. We may ask: > > > * the client to log the error and notify the administrator. > > > * and/or stop the redirection after n cycles. > > > > > > Still, this does not solve the problem. > > > [Jon] Agreed there is a problem here > > > > > > > > > > > I agree that there needs to be co-ordination between Server A and > > > > Server B, but user error may creep in. > > > > > > > > Usability #3 > > > > > > > > Server A says "Redirect to Server B" as it going to be shut down > > > > because of maintenance. Server B accepts things for a while and > > > > then is instructed (in probable user error) to redirect traffic > > > > back to A (perhaps because it has hit an overload condition). How > > > > should the client > > > handle this? > > > > > > [Med] Isn't this a sub-case or #2? > > > [Jon] Yes, but I wanted to bring in Server A being alive and able to > > respond > > > versus Server A down and not responding due to maintenance. > > > [Jon] With my better understanding of TTL we still have an issue if > > > the TTL expires and Server A is having an extended outage. How do > > > we recover from that? > > > ~jon > > > > > > > > > > > > Regards > > > > > > > > Jon > > > > > > > > _______________________________________________ > > > > Dots mailing list > > > > Dots@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Thu Apr 5 02:00:25 2018 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 637EE126DC2 for ; Thu, 5 Apr 2018 02:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUAUm5rhvlsK for ; Thu, 5 Apr 2018 02:00: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 383241201FA for ; Thu, 5 Apr 2018 02:00:21 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.90_1) (envelope-from ) id 1f40kl-0007A2-Fd; Thu, 05 Apr 2018 10:00:19 +0100 From: "Jon Shallow" To: , "Konda, Tirumaleswar Reddy" , References: <014f01d3cc19$2e3880e0$8aa982a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7E7B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <019901d3cc23$a93ff8e0$fbbfeaa0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8524@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <004e01d3ccb4$d505e7f0$7f11b7d0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF861C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DEF861C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Thu, 5 Apr 2018 10:00:20 +0100 Message-ID: <006e01d3ccbc$86539960$92facc20$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ5xX4UsK17va5Vv37fpNudI6+9awKIdnG+AkIt6UkCuIhgoQJj4oJpArGJQHwBTyE/F6I2rnZg Content-Language: en-gb Archived-At: Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling 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, 05 Apr 2018 09:00:24 -0000 Hi Med, See inline [Jon] Regards Jon -----Original Message----- From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 05 April 2018 09:50 To: Jon Shallow; Konda, Tirumaleswar Reddy; dots@ietf.org Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling Re-, Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > Envoy=E9=A0: jeudi 5 avril 2018 10:05 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy;=20 > dots@ietf.org Objet=A0: RE: [Dots] Signal Channel - 300 Redirected=20 > Signaling >=20 > Hi Med, >=20 > Thanks for this refresh to 4.6 Redirected Signaling >=20 > Some comments >=20 > #1 >=20 > The DOTS server can return the error response code 3.00 in response > to a PUT request from the DOTS client or convey the error response > code 3.00 in a unidirectional notification response from the DOTS > server. >=20 > Why is this limited to a PUT request and/or unidirectional=20 > notification response? > - Surely, any response, unsolicited or otherwise can contain a 3.00 > - If Observe is not in use, then any unsolicited notification response = > will potentially get rejected by the coap library layer, so a DOTS=20 > Server cannot signal maintenance outage other than by closing the = session. > - I missed this the last review - sorry >=20 [Med] There is no restriction in the text:=20 If a DOTS server wants to redirect a DOTS client to an alternative DOTS server for a signal session, then the response code 3.00 (alternate server) will be returned in the response to the DOTS client. [Jon] Agreed this preceding paragraph is more generic (which is why I possibly did not pick up on this), but then the para I quoted implies it = is restricted to a PUT request which is not the case. Perhaps s/in response to a PUT request from/in response to any request from/ which works for me. The text you quoted is about a case in which redirect is likely : " The = DOTS server **can** return the error response code.." [Jon] but implied (not a MUST I agree) that it cannot be done if it was = a GET request=20 > #2 >=20 > If the DOTS client has been redirected to a DOTS server to which it > has already sent the mitigation request within the last five (5) > minutes, it MUST ignore the redirection and try to contact other=20 > DOTS >=20 > s/ has already sent the mitigation request/ has already communicated=20 > with/ [Med] Fixed. [Jon] Thanks >=20 > #3 >=20 > A DOTS client MUST NOT use an alternate IP address to contact = its > DOTS server upon expiry of the associated TTL. >=20 > To remove ambiguity over the use of FQDN, this could read >=20 > A DOTS client MUST NOT use an alternate IP address to contact = its > DOTS server upon expiry of the associated TTL. Furthermore, a = DOTS > Client MUST NOT use the alt-server FQDN if all of the=20 > alt-server-records > have expired. >=20 [Med] I can add this to remove ambiguity.=20 [Jon} Please do ~jon > Or alternatively >=20 > alt-server: FQDN of an alternate DOTS server. >=20 > This could read >=20 > alt-server: FQDN of an alternate DOTS server. This FQDN is not to = > be used for looking up IP addresses to use, but is there for the SNI=20 > extension (7.1. (D)TLS Protocol Profile) >=20 >=20 > Regards >=20 > Jon > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of=20 > mohamed.boucadair@orange.com > Sent: 05 April 2018 08:20 > To: Konda, Tirumaleswar Reddy; Jon Shallow; dots@ietf.org > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling >=20 > Hi Tiru, >=20 > Works for me. >=20 > I updated the draft with the text additions that were discussed in=20 > this thread. The changes can be found at: > https://github.com/boucadair/draft-ietf-dots-signal-channel/blob/maste > r/draf > t-ietf-dots-signal-channel.txt >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Konda, Tirumaleswar Reddy > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > Envoy=E9=A0: mercredi 4 avril 2018 17:40 =C0=A0: Jon Shallow; = BOUCADAIR=20 > > Mohamed IMT/OLN; dots@ietf.org Objet=A0: RE: > > [Dots] Signal Channel - 300 Redirected Signaling > > > > The TTL value returned under alt-server-record is equivalent to the=20 > > DNS TTL value. A DDoS mitigation provider with multiple DOTS servers = > > typically re-directs a DOTS client to a different DOTS server only=20 > > if the alternate DOTS server has the capacity to handle the requests = > > from the > DOTS client. > > > > We can add the following lines to avoid loops : > > > > If the DOTS client has been redirected to a DOTS server to which it=20 > > has already sent the mitigation request within the last five=20 > > minutes, it MUST ignore the redirection and try reaching others=20 > > servers listed in the local configuration or discovered using=20 > > dynamic means such as DHCP or SRV procedures. > > This prevents infinite ping-ponging between servers in case of=20 > > redirection loops. > > > > -Tiru > > > > > -----Original Message----- > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow > > > Sent: Wednesday, April 4, 2018 8:16 PM > > > To: mohamed.boucadair@orange.com; dots@ietf.org > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > Hi there, > > > > > > See inline [Jon] > > > > > > Regards > > > > > > Jon > > > > > > -----Original Message----- > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of=20 > > > mohamed.boucadair@orange.com > > > Sent: 04 April 2018 15:07 > > > To: Jon Shallow; dots@ietf.org > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > Re-, > > > > > > Please see inline. > > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Jon=20 > > > > Shallow Envoy=E9=A0: mercredi 4 avril 2018 15:31 =C0=A0: = dots@ietf.org Objet=A0: > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > Hi there, > > > > > > > > I have implemented the 300 Redirected-Signal in my DOTS code. > > > > This then raises some questions about usability. > > > > > > > > Usability #1 > > > > > > > > Architecture 3.2.2 Redirected Signalling > > > > > > > > 4. Having redirected the DOTS client, DOTS server A ceases sending > > > > server signals. The DOTS client likewise stops sending client > > > > signals to DOTS server A. DOTS session 1 is terminated. > > > > > > > > Clearly indicates that the original session (Client to Server A) = > > > > is no more once redirected and only Client to Server B is in = use. > > > > > > > > How is the traffic redirected back to Server A once maintenance=20 > > > > / overloading etc. has finished? My assumption is that Server B = > > > > sends a redirect to go back to Server A as Server A has no way=20 > > > > to say over a now non-existent session to say "come back". > > > > > > [Med] That's one possibility. This one does not require any update = > > > to the > > signal- > > > channel specification. > > > > > > Another approach would be to not require any redirect signal from=20 > > > server > B. > > > The client will remove server B's records upon the expiry of the=20 > > > TTL and > > will fall > > > back to the "base" DOTS servers configuration that was provisioned = > > > to the > > client > > > using DHCP or whatever mechanism. > > > [Jon] OK. The TTL is defined at, associated with the IP address=20 > > > level > > under alt- > > > server-record, not under > > > ietf-dots-signal-channel:redirected-signal. The ttl definition = is > > > ambiguous as to what it refers to and perhaps could be tightened=20 > > > up in the language (I read it as being associated with "addr" in=20 > > > the sense of a DNS > > TTL). > > > > > > > > > > > Do we need to keep the existing Client to Server A session warm=20 > > > > (or perhaps to probe periodically) to see if Server A is capable = > > > > of handling the Client again by a server response extension to=20 > > > > the protocol (e.g. a 3.01) > > > > > > [Med] Redirect was initially introduced to manage a server=20 > > > overload, so I > > don't > > > think it makes sense to probe or maintain a session with server A. > > > [Jon] Agreed, but I needed to raise the question. > > > > > > > > > > > Should there be a retry period parameter added in to the 3.00=20 > > > > protocol (as I read it, ttl only refers to the IP address)? > > > > > > [Med] The client will automatically switch to Server A when all=20 > > > alternate > > records > > > expire. > > > [Jon] OK - again the 4.6 text needs to get tightened up to reflect = > > > this as > > the > > > intent. > > > > > > > > > > > > > > Usability #2 > > > > > > > > Server A says "Redirect to Server B" due to overloading. Server = > > > > B accepts things for a while and then is instructed/decides to=20 > > > > redirect traffic back to A. Server A is left still overload=20 > > > > configured to redirect to B. How should the client handle this=20 > > > > as there is no suitable > > > Server? > > > > > > [Med] This is a service configuration problem. We may ask: > > > * the client to log the error and notify the administrator. > > > * and/or stop the redirection after n cycles. > > > > > > Still, this does not solve the problem. > > > [Jon] Agreed there is a problem here > > > > > > > > > > > I agree that there needs to be co-ordination between Server A=20 > > > > and Server B, but user error may creep in. > > > > > > > > Usability #3 > > > > > > > > Server A says "Redirect to Server B" as it going to be shut down = > > > > because of maintenance. Server B accepts things for a while and = > > > > then is instructed (in probable user error) to redirect traffic=20 > > > > back to A (perhaps because it has hit an overload condition). =20 > > > > How should the client > > > handle this? > > > > > > [Med] Isn't this a sub-case or #2? > > > [Jon] Yes, but I wanted to bring in Server A being alive and able=20 > > > to > > respond > > > versus Server A down and not responding due to maintenance. > > > [Jon] With my better understanding of TTL we still have an issue=20 > > > if the TTL expires and Server A is having an extended outage. How = > > > do we recover from that? > > > ~jon > > > > > > > > > > > > Regards > > > > > > > > Jon > > > > > > > > _______________________________________________ > > > > Dots mailing list > > > > Dots@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Thu Apr 5 02:16:24 2018 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 D6C56126DED for ; Thu, 5 Apr 2018 02:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 8CGHBZl_QL_4 for ; Thu, 5 Apr 2018 02:16:19 -0700 (PDT) Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98538126579 for ; Thu, 5 Apr 2018 02:16:19 -0700 (PDT) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 038E820BA5; Thu, 5 Apr 2018 11:16:18 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.62]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id D69521C00F7; Thu, 5 Apr 2018 11:16:17 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5E.corporate.adroot.infra.ftgroup ([fe80::2912:bfa5:91d3:bf63%18]) with mapi id 14.03.0382.000; Thu, 5 Apr 2018 11:16:17 +0200 From: To: Jon Shallow , "Konda, Tirumaleswar Reddy" , "dots@ietf.org" Thread-Topic: [Dots] Signal Channel - 300 Redirected Signaling Thread-Index: AQJ5xX4UsK17va5Vv37fpNudI6+9awKIdnG+AkIt6UkCuIhgoQJj4oJpArGJQHwBTyE/F6I2rnZggAADxrA= Date: Thu, 5 Apr 2018 09:16:16 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DEF8650@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <014f01d3cc19$2e3880e0$8aa982a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7E7B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <019901d3cc23$a93ff8e0$fbbfeaa0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8524@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <004e01d3ccb4$d505e7f0$7f11b7d0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF861C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <006e01d3ccbc$86539960$92facc20$@jpshallow.com> In-Reply-To: <006e01d3ccbc$86539960$92facc20$@jpshallow.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling 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, 05 Apr 2018 09:16:23 -0000 Re-, Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > Envoy=E9=A0: jeudi 5 avril 2018 11:00 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; dots@ietf.o= rg > Objet=A0: RE: [Dots] Signal Channel - 300 Redirected Signaling >=20 > Hi Med, >=20 > See inline [Jon] >=20 > Regards >=20 > Jon > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > mohamed.boucadair@orange.com > Sent: 05 April 2018 09:50 > To: Jon Shallow; Konda, Tirumaleswar Reddy; dots@ietf.org > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling >=20 > Re-, >=20 > Please see inline. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > Envoy=E9=A0: jeudi 5 avril 2018 10:05 > > =C0=A0: BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; > > dots@ietf.org Objet=A0: RE: [Dots] Signal Channel - 300 Redirected > > Signaling > > > > Hi Med, > > > > Thanks for this refresh to 4.6 Redirected Signaling > > > > Some comments > > > > #1 > > > > The DOTS server can return the error response code 3.00 in response > > to a PUT request from the DOTS client or convey the error response > > code 3.00 in a unidirectional notification response from the DOTS > > server. > > > > Why is this limited to a PUT request and/or unidirectional > > notification response? > > - Surely, any response, unsolicited or otherwise can contain a 3.00 > > - If Observe is not in use, then any unsolicited notification response > > will potentially get rejected by the coap library layer, so a DOTS > > Server cannot signal maintenance outage other than by closing the sessi= on. > > - I missed this the last review - sorry > > >=20 > [Med] There is no restriction in the text: >=20 > If a DOTS server wants to redirect a DOTS client to an alternative > DOTS server for a signal session, then the response code 3.00 > (alternate server) will be returned in the response to the DOTS > client. >=20 > [Jon] Agreed this preceding paragraph is more generic (which is why I > possibly did not pick up on this), but then the para I quoted implies it = is > restricted to a PUT request which is not the case. Perhaps > s/in response to a PUT request from/in response to any request from/ > which works for me. >=20 > The text you quoted is about a case in which redirect is likely : " The D= OTS > server **can** return the error response code.." > [Jon] but implied (not a MUST I agree) that it cannot be done if it was a > GET request >=20 [Med] This is not what that text says. It only says that a typical usage is= a response to PUT. This does not prevent a server to return for other requ= ests. The example with PUT is more trivial compared to, for example GET/DEL= ETE, which requires that the redirected server maintains the required infor= mation to process the request.=20 Anyway, to avoid misinterpreting the text, I changed it to:=20 The DOTS server can return the error response code 3.00 in response to a request from the DOTS client or convey the error response code 3.00 in a unidirectional notification response from the DOTS server. > > #2 > > > > If the DOTS client has been redirected to a DOTS server to which it > > has already sent the mitigation request within the last five (5) > > minutes, it MUST ignore the redirection and try to contact other > > DOTS > > > > s/ has already sent the mitigation request/ has already communicated > > with/ >=20 > [Med] Fixed. > [Jon] Thanks >=20 > > > > #3 > > > > A DOTS client MUST NOT use an alternate IP address to contact its > > DOTS server upon expiry of the associated TTL. > > > > To remove ambiguity over the use of FQDN, this could read > > > > A DOTS client MUST NOT use an alternate IP address to contact its > > DOTS server upon expiry of the associated TTL. Furthermore, a DO= TS > > Client MUST NOT use the alt-server FQDN if all of the > > alt-server-records > > have expired. > > >=20 > [Med] I can add this to remove ambiguity. > [Jon} Please do > ~jon >=20 > > Or alternatively > > > > alt-server: FQDN of an alternate DOTS server. > > > > This could read > > > > alt-server: FQDN of an alternate DOTS server. This FQDN is not to > > be used for looking up IP addresses to use, but is there for the SNI > > extension (7.1. (D)TLS Protocol Profile) > > > > > > Regards > > > > Jon > > -----Original Message----- > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > mohamed.boucadair@orange.com > > Sent: 05 April 2018 08:20 > > To: Konda, Tirumaleswar Reddy; Jon Shallow; dots@ietf.org > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > Hi Tiru, > > > > Works for me. > > > > I updated the draft with the text additions that were discussed in > > this thread. The changes can be found at: > > https://github.com/boucadair/draft-ietf-dots-signal-channel/blob/maste > > r/draf > > t-ietf-dots-signal-channel.txt > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: Konda, Tirumaleswar Reddy > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > Envoy=E9=A0: mercredi 4 avril 2018 17:40 =C0=A0: Jon Shallow; BOUCADA= IR > > > Mohamed IMT/OLN; dots@ietf.org Objet=A0: RE: > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > The TTL value returned under alt-server-record is equivalent to the > > > DNS TTL value. A DDoS mitigation provider with multiple DOTS servers > > > typically re-directs a DOTS client to a different DOTS server only > > > if the alternate DOTS server has the capacity to handle the requests > > > from the > > DOTS client. > > > > > > We can add the following lines to avoid loops : > > > > > > If the DOTS client has been redirected to a DOTS server to which it > > > has already sent the mitigation request within the last five > > > minutes, it MUST ignore the redirection and try reaching others > > > servers listed in the local configuration or discovered using > > > dynamic means such as DHCP or SRV procedures. > > > This prevents infinite ping-ponging between servers in case of > > > redirection loops. > > > > > > -Tiru > > > > > > > -----Original Message----- > > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow > > > > Sent: Wednesday, April 4, 2018 8:16 PM > > > > To: mohamed.boucadair@orange.com; dots@ietf.org > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > Hi there, > > > > > > > > See inline [Jon] > > > > > > > > Regards > > > > > > > > Jon > > > > > > > > -----Original Message----- > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > > > mohamed.boucadair@orange.com > > > > Sent: 04 April 2018 15:07 > > > > To: Jon Shallow; dots@ietf.org > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > Re-, > > > > > > > > Please see inline. > > > > > > > > Cheers, > > > > Med > > > > > > > > > -----Message d'origine----- > > > > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Jon > > > > > Shallow Envoy=E9=A0: mercredi 4 avril 2018 15:31 =C0=A0: dots@iet= f.org > Objet=A0: > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > Hi there, > > > > > > > > > > I have implemented the 300 Redirected-Signal in my DOTS code. > > > > > This then raises some questions about usability. > > > > > > > > > > Usability #1 > > > > > > > > > > Architecture 3.2.2 Redirected Signalling > > > > > > > > > > 4. Having redirected the DOTS client, DOTS server A ceases > sending > > > > > server signals. The DOTS client likewise stops sending > client > > > > > signals to DOTS server A. DOTS session 1 is terminated. > > > > > > > > > > Clearly indicates that the original session (Client to Server A) > > > > > is no more once redirected and only Client to Server B is in use. > > > > > > > > > > How is the traffic redirected back to Server A once maintenance > > > > > / overloading etc. has finished? My assumption is that Server B > > > > > sends a redirect to go back to Server A as Server A has no way > > > > > to say over a now non-existent session to say "come back". > > > > > > > > [Med] That's one possibility. This one does not require any update > > > > to the > > > signal- > > > > channel specification. > > > > > > > > Another approach would be to not require any redirect signal from > > > > server > > B. > > > > The client will remove server B's records upon the expiry of the > > > > TTL and > > > will fall > > > > back to the "base" DOTS servers configuration that was provisioned > > > > to the > > > client > > > > using DHCP or whatever mechanism. > > > > [Jon] OK. The TTL is defined at, associated with the IP address > > > > level > > > under alt- > > > > server-record, not under > > > > ietf-dots-signal-channel:redirected-signal. The ttl definition is > > > > ambiguous as to what it refers to and perhaps could be tightened > > > > up in the language (I read it as being associated with "addr" in > > > > the sense of a DNS > > > TTL). > > > > > > > > > > > > > > Do we need to keep the existing Client to Server A session warm > > > > > (or perhaps to probe periodically) to see if Server A is capable > > > > > of handling the Client again by a server response extension to > > > > > the protocol (e.g. a 3.01) > > > > > > > > [Med] Redirect was initially introduced to manage a server > > > > overload, so I > > > don't > > > > think it makes sense to probe or maintain a session with server A. > > > > [Jon] Agreed, but I needed to raise the question. > > > > > > > > > > > > > > Should there be a retry period parameter added in to the 3.00 > > > > > protocol (as I read it, ttl only refers to the IP address)? > > > > > > > > [Med] The client will automatically switch to Server A when all > > > > alternate > > > records > > > > expire. > > > > [Jon] OK - again the 4.6 text needs to get tightened up to reflect > > > > this as > > > the > > > > intent. > > > > > > > > > > > > > > > > > > Usability #2 > > > > > > > > > > Server A says "Redirect to Server B" due to overloading. Server > > > > > B accepts things for a while and then is instructed/decides to > > > > > redirect traffic back to A. Server A is left still overload > > > > > configured to redirect to B. How should the client handle this > > > > > as there is no suitable > > > > Server? > > > > > > > > [Med] This is a service configuration problem. We may ask: > > > > * the client to log the error and notify the administrator. > > > > * and/or stop the redirection after n cycles. > > > > > > > > Still, this does not solve the problem. > > > > [Jon] Agreed there is a problem here > > > > > > > > > > > > > > I agree that there needs to be co-ordination between Server A > > > > > and Server B, but user error may creep in. > > > > > > > > > > Usability #3 > > > > > > > > > > Server A says "Redirect to Server B" as it going to be shut down > > > > > because of maintenance. Server B accepts things for a while and > > > > > then is instructed (in probable user error) to redirect traffic > > > > > back to A (perhaps because it has hit an overload condition). > > > > > How should the client > > > > handle this? > > > > > > > > [Med] Isn't this a sub-case or #2? > > > > [Jon] Yes, but I wanted to bring in Server A being alive and able > > > > to > > > respond > > > > versus Server A down and not responding due to maintenance. > > > > [Jon] With my better understanding of TTL we still have an issue > > > > if the TTL expires and Server A is having an extended outage. How > > > > do we recover from that? > > > > ~jon > > > > > > > > > > > > > > > Regards > > > > > > > > > > Jon > > > > > > > > > > _______________________________________________ > > > > > Dots mailing list > > > > > Dots@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > _______________________________________________ > > > > Dots mailing list > > > > Dots@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > _______________________________________________ > > > > Dots mailing list > > > > Dots@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Thu Apr 5 02:30:50 2018 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 7DA4612702E for ; Thu, 5 Apr 2018 02:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNljo4clsVhG for ; Thu, 5 Apr 2018 02:30:46 -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 3B51D126579 for ; Thu, 5 Apr 2018 02:30:46 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.90_1) (envelope-from ) id 1f41EC-0007BK-Gm; Thu, 05 Apr 2018 10:30:44 +0100 From: "Jon Shallow" To: , "Konda, Tirumaleswar Reddy" , References: <014f01d3cc19$2e3880e0$8aa982a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7E7B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <019901d3cc23$a93ff8e0$fbbfeaa0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8524@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <004e01d3ccb4$d505e7f0$7f11b7d0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF861C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <006e01d3ccbc$86539960$92facc20$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8650@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DEF8650@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Thu, 5 Apr 2018 10:30:45 +0100 Message-ID: <007301d3ccc0$c61fb430$525f1c90$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ5xX4UsK17va5Vv37fpNudI6+9awKIdnG+AkIt6UkCuIhgoQJj4oJpArGJQHwBTyE/FwGNdJ60AM+kxIKiI8yLkA== Content-Language: en-gb Archived-At: Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling 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, 05 Apr 2018 09:30:49 -0000 Hi Med, See inline [Jon1] Regards Jon =20 > > -----Message d'origine----- > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > Envoy=E9=A0: jeudi 5 avril 2018 10:05 > > =C0=A0: BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy;=20 > > dots@ietf.org Objet=A0: RE: [Dots] Signal Channel - 300 Redirected=20 > > Signaling > > > > Hi Med, > > > > Thanks for this refresh to 4.6 Redirected Signaling > > > > Some comments > > > > #1 > > > > The DOTS server can return the error response code 3.00 in = response > > to a PUT request from the DOTS client or convey the error = response > > code 3.00 in a unidirectional notification response from the DOTS > > server. > > > > Why is this limited to a PUT request and/or unidirectional=20 > > notification response? > > - Surely, any response, unsolicited or otherwise can contain a 3.00 > > - If Observe is not in use, then any unsolicited notification=20 > > response will potentially get rejected by the coap library layer, so = > > a DOTS Server cannot signal maintenance outage other than by closing = the session. > > - I missed this the last review - sorry > > >=20 > [Med] There is no restriction in the text: >=20 > If a DOTS server wants to redirect a DOTS client to an alternative > DOTS server for a signal session, then the response code 3.00 > (alternate server) will be returned in the response to the DOTS > client. >=20 > [Jon] Agreed this preceding paragraph is more generic (which is why I=20 > possibly did not pick up on this), but then the para I quoted implies=20 > it is restricted to a PUT request which is not the case. Perhaps s/in = > response to a PUT request from/in response to any request from/ which=20 > works for me. >=20 > The text you quoted is about a case in which redirect is likely : "=20 > The DOTS server **can** return the error response code.." > [Jon] but implied (not a MUST I agree) that it cannot be done if it=20 > was a GET request >=20 [Med] This is not what that text says. It only says that a typical usage = is a response to PUT. This does not prevent a server to return for other requests. The example with PUT is more trivial compared to, for example GET/DELETE, which requires that the redirected server maintains the = required information to process the request.=20 [Jon1] I would not be expecting the redirected server to maintain state = / information, but would be expecting the DOTS client to treat the = connection to the redirected Server as if the DOTS client was just starting up and = both ends need to get synchronized (e.g. get Server's current mitigation = state) before retrying any GET / PUT etc.=20 Anyway, to avoid misinterpreting the text, I changed it to:=20 The DOTS server can return the error response code 3.00 in response to a request from the DOTS client or convey the error response code 3.00 in a unidirectional notification response from the DOTS server. [Jon1] Thanks ~jon1 > > #2 > > > > If the DOTS client has been redirected to a DOTS server to which = it > > has already sent the mitigation request within the last five (5) > > minutes, it MUST ignore the redirection and try to contact other=20 > > DOTS > > > > s/ has already sent the mitigation request/ has already communicated = > > with/ >=20 > [Med] Fixed. > [Jon] Thanks >=20 > > > > #3 > > > > A DOTS client MUST NOT use an alternate IP address to contact = its > > DOTS server upon expiry of the associated TTL. > > > > To remove ambiguity over the use of FQDN, this could read > > > > A DOTS client MUST NOT use an alternate IP address to contact = its > > DOTS server upon expiry of the associated TTL. Furthermore, a DOTS > > Client MUST NOT use the alt-server FQDN if all of the=20 > > alt-server-records > > have expired. > > >=20 > [Med] I can add this to remove ambiguity. > [Jon} Please do > ~jon >=20 > > Or alternatively > > > > alt-server: FQDN of an alternate DOTS server. > > > > This could read > > > > alt-server: FQDN of an alternate DOTS server. This FQDN is not=20 > > to be used for looking up IP addresses to use, but is there for the=20 > > SNI extension (7.1. (D)TLS Protocol Profile) > > > > > > Regards > > > > Jon > > -----Original Message----- > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of=20 > > mohamed.boucadair@orange.com > > Sent: 05 April 2018 08:20 > > To: Konda, Tirumaleswar Reddy; Jon Shallow; dots@ietf.org > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > Hi Tiru, > > > > Works for me. > > > > I updated the draft with the text additions that were discussed in=20 > > this thread. The changes can be found at: > > https://github.com/boucadair/draft-ietf-dots-signal-channel/blob/mas > > te > > r/draf > > t-ietf-dots-signal-channel.txt > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: Konda, Tirumaleswar Reddy > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > Envoy=E9=A0: mercredi 4 avril 2018 17:40 =C0=A0: Jon Shallow; = BOUCADAIR=20 > > > Mohamed IMT/OLN; dots@ietf.org Objet=A0: RE: > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > The TTL value returned under alt-server-record is equivalent to=20 > > > the DNS TTL value. A DDoS mitigation provider with multiple DOTS=20 > > > servers typically re-directs a DOTS client to a different DOTS=20 > > > server only if the alternate DOTS server has the capacity to=20 > > > handle the requests from the > > DOTS client. > > > > > > We can add the following lines to avoid loops : > > > > > > If the DOTS client has been redirected to a DOTS server to which=20 > > > it has already sent the mitigation request within the last five=20 > > > minutes, it MUST ignore the redirection and try reaching others=20 > > > servers listed in the local configuration or discovered using=20 > > > dynamic means such as DHCP or SRV procedures. > > > This prevents infinite ping-ponging between servers in case of=20 > > > redirection loops. > > > > > > -Tiru > > > > > > > -----Original Message----- > > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon=20 > > > > Shallow > > > > Sent: Wednesday, April 4, 2018 8:16 PM > > > > To: mohamed.boucadair@orange.com; dots@ietf.org > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > Hi there, > > > > > > > > See inline [Jon] > > > > > > > > Regards > > > > > > > > Jon > > > > > > > > -----Original Message----- > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of=20 > > > > mohamed.boucadair@orange.com > > > > Sent: 04 April 2018 15:07 > > > > To: Jon Shallow; dots@ietf.org > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > Re-, > > > > > > > > Please see inline. > > > > > > > > Cheers, > > > > Med > > > > > > > > > -----Message d'origine----- > > > > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Jon=20 > > > > > Shallow Envoy=E9=A0: mercredi 4 avril 2018 15:31 =C0=A0: = dots@ietf.org > Objet=A0: > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > Hi there, > > > > > > > > > > I have implemented the 300 Redirected-Signal in my DOTS code. > > > > > This then raises some questions about usability. > > > > > > > > > > Usability #1 > > > > > > > > > > Architecture 3.2.2 Redirected Signalling > > > > > > > > > > 4. Having redirected the DOTS client, DOTS server A ceases > sending > > > > > server signals. The DOTS client likewise stops sending > client > > > > > signals to DOTS server A. DOTS session 1 is = terminated. > > > > > > > > > > Clearly indicates that the original session (Client to Server=20 > > > > > A) is no more once redirected and only Client to Server B is = in use. > > > > > > > > > > How is the traffic redirected back to Server A once=20 > > > > > maintenance / overloading etc. has finished? My assumption is = > > > > > that Server B sends a redirect to go back to Server A as=20 > > > > > Server A has no way to say over a now non-existent session to = say "come back". > > > > > > > > [Med] That's one possibility. This one does not require any=20 > > > > update to the > > > signal- > > > > channel specification. > > > > > > > > Another approach would be to not require any redirect signal=20 > > > > from server > > B. > > > > The client will remove server B's records upon the expiry of the = > > > > TTL and > > > will fall > > > > back to the "base" DOTS servers configuration that was=20 > > > > provisioned to the > > > client > > > > using DHCP or whatever mechanism. > > > > [Jon] OK. The TTL is defined at, associated with the IP=20 > > > > address level > > > under alt- > > > > server-record, not under > > > > ietf-dots-signal-channel:redirected-signal. The ttl definition = is > > > > ambiguous as to what it refers to and perhaps could be tightened = > > > > up in the language (I read it as being associated with "addr" in = > > > > the sense of a DNS > > > TTL). > > > > > > > > > > > > > > Do we need to keep the existing Client to Server A session=20 > > > > > warm (or perhaps to probe periodically) to see if Server A is=20 > > > > > capable of handling the Client again by a server response=20 > > > > > extension to the protocol (e.g. a 3.01) > > > > > > > > [Med] Redirect was initially introduced to manage a server=20 > > > > overload, so I > > > don't > > > > think it makes sense to probe or maintain a session with server = A. > > > > [Jon] Agreed, but I needed to raise the question. > > > > > > > > > > > > > > Should there be a retry period parameter added in to the 3.00=20 > > > > > protocol (as I read it, ttl only refers to the IP address)? > > > > > > > > [Med] The client will automatically switch to Server A when all=20 > > > > alternate > > > records > > > > expire. > > > > [Jon] OK - again the 4.6 text needs to get tightened up to=20 > > > > reflect this as > > > the > > > > intent. > > > > > > > > > > > > > > > > > > Usability #2 > > > > > > > > > > Server A says "Redirect to Server B" due to overloading. =20 > > > > > Server B accepts things for a while and then is=20 > > > > > instructed/decides to redirect traffic back to A. Server A is = > > > > > left still overload configured to redirect to B. How should=20 > > > > > the client handle this as there is no suitable > > > > Server? > > > > > > > > [Med] This is a service configuration problem. We may ask: > > > > * the client to log the error and notify the administrator. > > > > * and/or stop the redirection after n cycles. > > > > > > > > Still, this does not solve the problem. > > > > [Jon] Agreed there is a problem here > > > > > > > > > > > > > > I agree that there needs to be co-ordination between Server A=20 > > > > > and Server B, but user error may creep in. > > > > > > > > > > Usability #3 > > > > > > > > > > Server A says "Redirect to Server B" as it going to be shut=20 > > > > > down because of maintenance. Server B accepts things for a=20 > > > > > while and then is instructed (in probable user error) to=20 > > > > > redirect traffic back to A (perhaps because it has hit an = overload condition). > > > > > How should the client > > > > handle this? > > > > > > > > [Med] Isn't this a sub-case or #2? > > > > [Jon] Yes, but I wanted to bring in Server A being alive and=20 > > > > able to > > > respond > > > > versus Server A down and not responding due to maintenance. > > > > [Jon] With my better understanding of TTL we still have an issue = > > > > if the TTL expires and Server A is having an extended outage. =20 > > > > How do we recover from that? > > > > ~jon > > > > > > > > > > > > > > > Regards > > > > > > > > > > Jon > > > > > > > > > > _______________________________________________ > > > > > Dots mailing list > > > > > Dots@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > _______________________________________________ > > > > Dots mailing list > > > > Dots@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > _______________________________________________ > > > > Dots mailing list > > > > Dots@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Thu Apr 5 02:33:54 2018 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 C7AAF12708C for ; Thu, 5 Apr 2018 02:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 lYG-ycqwfspg for ; Thu, 5 Apr 2018 02:33:50 -0700 (PDT) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A26D12702E for ; Thu, 5 Apr 2018 02:33:50 -0700 (PDT) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 978061601AF; Thu, 5 Apr 2018 11:33:48 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.18]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 78565180066; Thu, 5 Apr 2018 11:33:48 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM34.corporate.adroot.infra.ftgroup ([fe80::cba:56d0:a732:ef5a%19]) with mapi id 14.03.0382.000; Thu, 5 Apr 2018 11:33:48 +0200 From: To: Jon Shallow , "Konda, Tirumaleswar Reddy" , "dots@ietf.org" Thread-Topic: [Dots] Signal Channel - 300 Redirected Signaling Thread-Index: AQJ5xX4UsK17va5Vv37fpNudI6+9awKIdnG+AkIt6UkCuIhgoQJj4oJpArGJQHwBTyE/FwGNdJ60AM+kxIKiI8yLkIAAA8jw Date: Thu, 5 Apr 2018 09:33:47 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DEF8699@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <014f01d3cc19$2e3880e0$8aa982a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7E7B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <019901d3cc23$a93ff8e0$fbbfeaa0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8524@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <004e01d3ccb4$d505e7f0$7f11b7d0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF861C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <006e01d3ccbc$86539960$92facc20$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8650@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <007301d3ccc0$c61fb430$525f1c90$@jpshallow.com> In-Reply-To: <007301d3ccc0$c61fb430$525f1c90$@jpshallow.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling 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, 05 Apr 2018 09:33:53 -0000 Re-, ACKed.=20 I guess that this one is closed. Cheers, Med > -----Message d'origine----- > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > Envoy=E9=A0: jeudi 5 avril 2018 11:31 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; dots@ietf.o= rg > Objet=A0: RE: [Dots] Signal Channel - 300 Redirected Signaling >=20 > Hi Med, >=20 > See inline [Jon1] >=20 > Regards >=20 > Jon >=20 >=20 > > > -----Message d'origine----- > > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > Envoy=E9=A0: jeudi 5 avril 2018 10:05 > > > =C0=A0: BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; > > > dots@ietf.org Objet=A0: RE: [Dots] Signal Channel - 300 Redirected > > > Signaling > > > > > > Hi Med, > > > > > > Thanks for this refresh to 4.6 Redirected Signaling > > > > > > Some comments > > > > > > #1 > > > > > > The DOTS server can return the error response code 3.00 in respons= e > > > to a PUT request from the DOTS client or convey the error response > > > code 3.00 in a unidirectional notification response from the DOTS > > > server. > > > > > > Why is this limited to a PUT request and/or unidirectional > > > notification response? > > > - Surely, any response, unsolicited or otherwise can contain a 3.00 > > > - If Observe is not in use, then any unsolicited notification > > > response will potentially get rejected by the coap library layer, so > > > a DOTS Server cannot signal maintenance outage other than by closing = the > session. > > > - I missed this the last review - sorry > > > > > > > [Med] There is no restriction in the text: > > > > If a DOTS server wants to redirect a DOTS client to an alternative > > DOTS server for a signal session, then the response code 3.00 > > (alternate server) will be returned in the response to the DOTS > > client. > > > > [Jon] Agreed this preceding paragraph is more generic (which is why I > > possibly did not pick up on this), but then the para I quoted implies > > it is restricted to a PUT request which is not the case. Perhaps s/in > > response to a PUT request from/in response to any request from/ which > > works for me. > > > > The text you quoted is about a case in which redirect is likely : " > > The DOTS server **can** return the error response code.." > > [Jon] but implied (not a MUST I agree) that it cannot be done if it > > was a GET request > > >=20 > [Med] This is not what that text says. It only says that a typical usage = is > a response to PUT. This does not prevent a server to return for other > requests. The example with PUT is more trivial compared to, for example > GET/DELETE, which requires that the redirected server maintains the requi= red > information to process the request. >=20 > [Jon1] I would not be expecting the redirected server to maintain state / > information, but would be expecting the DOTS client to treat the connecti= on > to the redirected Server as if the DOTS client was just starting up and b= oth > ends need to get synchronized (e.g. get Server's current mitigation state= ) > before retrying any GET / PUT etc. >=20 > Anyway, to avoid misinterpreting the text, I changed it to: >=20 > The DOTS server can return the error response code 3.00 in response > to a request from the DOTS client or convey the error response code > 3.00 in a unidirectional notification response from the DOTS server. > [Jon1] Thanks > ~jon1 >=20 > > > #2 > > > > > > If the DOTS client has been redirected to a DOTS server to which i= t > > > has already sent the mitigation request within the last five (5) > > > minutes, it MUST ignore the redirection and try to contact other > > > DOTS > > > > > > s/ has already sent the mitigation request/ has already communicated > > > with/ > > > > [Med] Fixed. > > [Jon] Thanks > > > > > > > > #3 > > > > > > A DOTS client MUST NOT use an alternate IP address to contact i= ts > > > DOTS server upon expiry of the associated TTL. > > > > > > To remove ambiguity over the use of FQDN, this could read > > > > > > A DOTS client MUST NOT use an alternate IP address to contact i= ts > > > DOTS server upon expiry of the associated TTL. Furthermore, a > DOTS > > > Client MUST NOT use the alt-server FQDN if all of the > > > alt-server-records > > > have expired. > > > > > > > [Med] I can add this to remove ambiguity. > > [Jon} Please do > > ~jon > > > > > Or alternatively > > > > > > alt-server: FQDN of an alternate DOTS server. > > > > > > This could read > > > > > > alt-server: FQDN of an alternate DOTS server. This FQDN is not > > > to be used for looking up IP addresses to use, but is there for the > > > SNI extension (7.1. (D)TLS Protocol Profile) > > > > > > > > > Regards > > > > > > Jon > > > -----Original Message----- > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > > mohamed.boucadair@orange.com > > > Sent: 05 April 2018 08:20 > > > To: Konda, Tirumaleswar Reddy; Jon Shallow; dots@ietf.org > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > Hi Tiru, > > > > > > Works for me. > > > > > > I updated the draft with the text additions that were discussed in > > > this thread. The changes can be found at: > > > https://github.com/boucadair/draft-ietf-dots-signal-channel/blob/mas > > > te > > > r/draf > > > t-ietf-dots-signal-channel.txt > > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De=A0: Konda, Tirumaleswar Reddy > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > Envoy=E9=A0: mercredi 4 avril 2018 17:40 =C0=A0: Jon Shallow; BOUCA= DAIR > > > > Mohamed IMT/OLN; dots@ietf.org Objet=A0: RE: > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > The TTL value returned under alt-server-record is equivalent to > > > > the DNS TTL value. A DDoS mitigation provider with multiple DOTS > > > > servers typically re-directs a DOTS client to a different DOTS > > > > server only if the alternate DOTS server has the capacity to > > > > handle the requests from the > > > DOTS client. > > > > > > > > We can add the following lines to avoid loops : > > > > > > > > If the DOTS client has been redirected to a DOTS server to which > > > > it has already sent the mitigation request within the last five > > > > minutes, it MUST ignore the redirection and try reaching others > > > > servers listed in the local configuration or discovered using > > > > dynamic means such as DHCP or SRV procedures. > > > > This prevents infinite ping-ponging between servers in case of > > > > redirection loops. > > > > > > > > -Tiru > > > > > > > > > -----Original Message----- > > > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon > > > > > Shallow > > > > > Sent: Wednesday, April 4, 2018 8:16 PM > > > > > To: mohamed.boucadair@orange.com; dots@ietf.org > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > Hi there, > > > > > > > > > > See inline [Jon] > > > > > > > > > > Regards > > > > > > > > > > Jon > > > > > > > > > > -----Original Message----- > > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > > > > mohamed.boucadair@orange.com > > > > > Sent: 04 April 2018 15:07 > > > > > To: Jon Shallow; dots@ietf.org > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > Re-, > > > > > > > > > > Please see inline. > > > > > > > > > > Cheers, > > > > > Med > > > > > > > > > > > -----Message d'origine----- > > > > > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Jon > > > > > > Shallow Envoy=E9=A0: mercredi 4 avril 2018 15:31 =C0=A0: dots@i= etf.org > > Objet=A0: > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > Hi there, > > > > > > > > > > > > I have implemented the 300 Redirected-Signal in my DOTS code. > > > > > > This then raises some questions about usability. > > > > > > > > > > > > Usability #1 > > > > > > > > > > > > Architecture 3.2.2 Redirected Signalling > > > > > > > > > > > > 4. Having redirected the DOTS client, DOTS server A ceases > > sending > > > > > > server signals. The DOTS client likewise stops sending > > client > > > > > > signals to DOTS server A. DOTS session 1 is terminated. > > > > > > > > > > > > Clearly indicates that the original session (Client to Server > > > > > > A) is no more once redirected and only Client to Server B is in > use. > > > > > > > > > > > > How is the traffic redirected back to Server A once > > > > > > maintenance / overloading etc. has finished? My assumption is > > > > > > that Server B sends a redirect to go back to Server A as > > > > > > Server A has no way to say over a now non-existent session to s= ay > "come back". > > > > > > > > > > [Med] That's one possibility. This one does not require any > > > > > update to the > > > > signal- > > > > > channel specification. > > > > > > > > > > Another approach would be to not require any redirect signal > > > > > from server > > > B. > > > > > The client will remove server B's records upon the expiry of the > > > > > TTL and > > > > will fall > > > > > back to the "base" DOTS servers configuration that was > > > > > provisioned to the > > > > client > > > > > using DHCP or whatever mechanism. > > > > > [Jon] OK. The TTL is defined at, associated with the IP > > > > > address level > > > > under alt- > > > > > server-record, not under > > > > > ietf-dots-signal-channel:redirected-signal. The ttl definition = is > > > > > ambiguous as to what it refers to and perhaps could be tightened > > > > > up in the language (I read it as being associated with "addr" in > > > > > the sense of a DNS > > > > TTL). > > > > > > > > > > > > > > > > > Do we need to keep the existing Client to Server A session > > > > > > warm (or perhaps to probe periodically) to see if Server A is > > > > > > capable of handling the Client again by a server response > > > > > > extension to the protocol (e.g. a 3.01) > > > > > > > > > > [Med] Redirect was initially introduced to manage a server > > > > > overload, so I > > > > don't > > > > > think it makes sense to probe or maintain a session with server A= . > > > > > [Jon] Agreed, but I needed to raise the question. > > > > > > > > > > > > > > > > > Should there be a retry period parameter added in to the 3.00 > > > > > > protocol (as I read it, ttl only refers to the IP address)? > > > > > > > > > > [Med] The client will automatically switch to Server A when all > > > > > alternate > > > > records > > > > > expire. > > > > > [Jon] OK - again the 4.6 text needs to get tightened up to > > > > > reflect this as > > > > the > > > > > intent. > > > > > > > > > > > > > > > > > > > > > > Usability #2 > > > > > > > > > > > > Server A says "Redirect to Server B" due to overloading. > > > > > > Server B accepts things for a while and then is > > > > > > instructed/decides to redirect traffic back to A. Server A is > > > > > > left still overload configured to redirect to B. How should > > > > > > the client handle this as there is no suitable > > > > > Server? > > > > > > > > > > [Med] This is a service configuration problem. We may ask: > > > > > * the client to log the error and notify the administrator. > > > > > * and/or stop the redirection after n cycles. > > > > > > > > > > Still, this does not solve the problem. > > > > > [Jon] Agreed there is a problem here > > > > > > > > > > > > > > > > > I agree that there needs to be co-ordination between Server A > > > > > > and Server B, but user error may creep in. > > > > > > > > > > > > Usability #3 > > > > > > > > > > > > Server A says "Redirect to Server B" as it going to be shut > > > > > > down because of maintenance. Server B accepts things for a > > > > > > while and then is instructed (in probable user error) to > > > > > > redirect traffic back to A (perhaps because it has hit an overl= oad > condition). > > > > > > How should the client > > > > > handle this? > > > > > > > > > > [Med] Isn't this a sub-case or #2? > > > > > [Jon] Yes, but I wanted to bring in Server A being alive and > > > > > able to > > > > respond > > > > > versus Server A down and not responding due to maintenance. > > > > > [Jon] With my better understanding of TTL we still have an issue > > > > > if the TTL expires and Server A is having an extended outage. > > > > > How do we recover from that? > > > > > ~jon > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > Jon > > > > > > > > > > > > _______________________________________________ > > > > > > Dots mailing list > > > > > > Dots@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > _______________________________________________ > > > > > Dots mailing list > > > > > Dots@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > _______________________________________________ > > > > > Dots mailing list > > > > > Dots@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Thu Apr 5 02:44:40 2018 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 CC1D41270A7 for ; Thu, 5 Apr 2018 02:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IR6RvO6cM2y7 for ; Thu, 5 Apr 2018 02:44:36 -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 DCC9412708C for ; Thu, 5 Apr 2018 02:44:35 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.90_1) (envelope-from ) id 1f41Ra-0007By-5A; Thu, 05 Apr 2018 10:44:34 +0100 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , , References: <016401d3cc1c$03321200$09963600$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7F97@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <01a701d3cc29$ba915b10$2fb41130$@jpshallow.com> In-Reply-To: Date: Thu, 5 Apr 2018 10:44:34 +0100 Message-ID: <007501d3ccc2$b49f0b00$1ddd2100$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0076_01D3CCCB.1666A750" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEYhrWXRSNBek+fWBybzdJS41Z0KAI4GsKdAX18SvQDE9Kik6UyIHxQ Content-Language: en-gb Archived-At: Subject: Re: [Dots] Data Channel ACL fragments 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, 05 Apr 2018 09:44:39 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0076_01D3CCCB.1666A750 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Tiru, =20 Actually no, as there is a disconnect between the Cisco document and = what we have currently got set up. =20 The Cisco Document refers to ACL, which is an ACE in = netmod-acl-model/DOTS speak. A DOTS ACL can be a list of separate matching ACEs. =20 With netmod-acl, we have layer 3 definitions and then separately layer 4 definitions =96 there is now no concept of L3+L4 within the same ACE. =20 So, the Cisco statement =93Note: When there is both Layer 3 and Layer 4 information in the ACL line and the fragments keyword is present=94 will = never be true for an ACE entry. =20 ---- =20 I still do not understand from the Cisco Document how you can build a = set of ACLs that say (but I may be missing something) =93All traffic to port 53 is allowed unless it is fragmented, in which = case all fragments are to be dropped=94 =20 I can create a set of ACLs that say =93All traffic to port 53 is allowed unless it is fragmented, in which = case all non-initial fragments are to be dropped=94 Which does set things up for a DoS of the target with all the initial fragments waiting re-assembly. =20 ---- =20 Which then gets more complicated to construct something when we can only = do either L3 or L4 matching on a per ACE. =20 Regards =20 Jon =20 From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of = Konda, Tirumaleswar Reddy Sent: 05 April 2018 09:23 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] Data Channel ACL fragments =20 Hi Jon, =20 The fragment definition to protect the target from attacks that use non-initial fragments only. We followed the Security considerations for IP filtering given in = Section 2 of https://www.ietf.org/rfc/rfc1858.txt to drop the initial fragment, so = the non-initial fragments will be discarded by the destination host (its implemented and discussed in https://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulati= on- gre/8014-acl-wp.html). =20 -Tiru =20 From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Wednesday, April 4, 2018 9:00 PM To: mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] Data Channel ACL fragments =20 Hi Med et all, =20 See inline [Jon] =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 04 April 2018 15:27 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Data Channel ACL fragments =20 Re-, =20 I guess we do still need this because we wanted to achieve this functionality (especially for the non-initial fragments): =20 =3D=3D This document supports fragment filtering which adds an additional layer of protection against a DoS attack that uses non-initial fragments only. When there is only layer 3 information in the ACL entry and the fragments keyword is present, for non-initial fragments matching the ACE entry, the 'deny' or 'accept' action associated with the ACE entry will be enforced. For initial or non-fragment matching the ACE entry, the next ACE entry will be processed. When there is both layer 3 and layer 4 information in the ACE entry and the fragments keyword is present, the ACE action is conservative for both 'accept' and 'deny' actions. The actions are conservative to not accidentally deny a fragmented portion of a flow because the fragments do not contain sufficient information to match all of the filter attributes. In the 'deny' action case, instead of denying a non-initial fragment, the next ACE entry is processed. In the 'accept' case, it is assumed that the layer 4 information in the non- initial fragment, if available, matches the layer 4 information in the ACE entry. =3D=3D =20 [Jon] Actually, as I read the text above, if the additional layer of protection is required against fragmented attacks and v-[46]-fragment is = set with action =93drop=94, then any non-initial fragment is dropped =96 = fine. =20 However, the initial fragment skips this ACE test and goes onto the next ACE. Assuming that there is a =93accept=94 that matches everything else = (i.e. we like the packet apart from when it is fragmented), then the initial fragment is let through. =20 The target IP then consumes lots of RAM whilst waiting for the missing fragment segments=85=85..D(D)oS Success. =20 There is no way to drop the initial fragment with the above text other = than to =93drop=94 genuine non fragmented traffic as well. I think that = logic is flawed to drop just subsequent fragments. =20 [Jon] I also wonder how the above is going to get implemented =96 it = would be easier to say any fragmented packet sequence is not allowed (including = the initial packet) rather than only a part of the sequence which then leads = to a DoS in its own rights. =20 No? =20 [Jon] See above. I do agree that flags -> fragment -> 1 is a bit = ambiguous is its definition when used to match a packet as an acl/ace, but I do = think the match intent is that the packet is not fragmented. =20 =20 Cheers, Med =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : mercredi 4 avril 2018 15:51 =C0 : dots@ietf.org Objet : [Dots] Data Channel ACL fragments =20 Hi there, =20 Do we still need to have the fragment definition for ACEs in the data channel? =20 draft-ietf-netmod-acl-model-18 now supports fragments for ipv4 (flags + options) and implicitly in ipv6 through the next header field protocol = set to 44 (fragment extension header). =20 IPV4 =3D=3D=3D=3D grouping acl-ipv4-header-fields { description "Fields in IPv4 header."; ... leaf flags { type bits { bit reserved { position 0; description "Reserved. Must be zero."; } bit fragment { position 1; description "Setting value to 0 indicates may fragment, while setting the value to 1 indicates do not fragment."; } bit more { position 2; description "Setting the value to 0 indicates this is the last fragment, and setting the value to 1 indicates more fragments are coming."; } } description "Bit definitions for the flags field in IPv4 header."; } =20 leaf offset { type uint16 { range "20..65535"; } description "The fragment offset is measured in units of 8 octets (64 bits). The first fragment has offset zero. The length is 13 bits"; } =20 Regards =20 Jon =20 ------=_NextPart_000_0076_01D3CCCB.1666A750 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

Actually no, as there is = a disconnect between the Cisco document and what we have currently got = set up.

 

The Cisco Document = refers to ACL, which is an ACE in netmod-acl-model/DOTS speak.=A0 A DOTS = ACL can be a list of separate matching ACEs.

 

With netmod-acl, we have = layer 3 definitions and then separately layer 4 definitions – = there is now no concept of L3+L4 within the same = ACE.

 

So, the Cisco statement = “Note: When there is both Layer 3 and Layer 4 information in the = ACL line and the fragments keyword is present” will never be true = for an ACE entry.

 

----

 

I still do not = understand from the Cisco Document how you can build a set of ACLs that = say (but I may be missing something)

“All traffic to = port 53 is allowed unless it is fragmented, in which case all fragments = are to be dropped”

 

I can create a set of = ACLs that say

“All traffic to port 53 is allowed unless = it is fragmented, in which case all non-initial fragments are to be = dropped”

Which does set things up for a DoS of the target = with all the initial fragments waiting = re-assembly.

 

----

 

Which then gets more = complicated to construct something when we can only do either L3 or L4 = matching on a per ACE.

 

Regards

 

Jon

 

From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 05 April 2018 = 09:23
To: Jon Shallow; mohamed.boucadair@orange.com; = dots@ietf.org
Subject: Re: [Dots] Data Channel ACL = fragments

 

Hi = Jon,

 

The fragment definition to protect = the target from attacks that use non-initial fragments = only.

We followed the Security = considerations for IP filtering given in Section 2 of https://www.ietf.org/rfc/rf= c1858.txt to drop the initial fragment, so the non-initial fragments = will be discarded by the destination host (its implemented and discussed = in https://www.cisco.com/c/en/us/support/do= cs/ip/generic-routing-encapsulation-gre/8014-acl-wp.html).=

 

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of Jon Shallow
Sent: Wednesday, April 4, 2018 = 9:00 PM
To: mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: Re: = [Dots] Data Channel ACL fragments

 

Hi Med et = all,

 

See inline = [Jon]

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of mohamed.boucadair@orange.com=
Sent: 04 April 2018 15:27
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] Data Channel ACL fragments

 

Re-,

 

I guess we do still need this because we wanted to = achieve this functionality (especially for the non-initial = fragments):

 

=3D=3D

   This document supports = fragment filtering which adds an additional

   layer of protection against a = DoS attack that uses non-initial

   fragments only.  When = there is only layer 3 information in the ACL

   entry and the fragments = keyword is present, for non-initial fragments

   matching the ACE entry, the = 'deny' or 'accept' action associated with

   the ACE entry will be = enforced.  For initial or non-fragment = matching

   the ACE entry, the next ACE = entry will be processed.  When there is

   both layer 3 and layer 4 = information in the ACE entry and the

   fragments keyword is present, = the ACE action is conservative for both

   'accept' and 'deny' = actions.  The actions are conservative to = not

   accidentally deny a = fragmented portion of a flow because the

   fragments do not contain = sufficient information to match all of the

   filter attributes.  In = the 'deny' action case, instead of denying a

   non-initial fragment, the = next ACE entry is processed.  In the

   'accept' case, it is assumed = that the layer 4 information in the non-

   initial fragment, if = available, matches the layer 4 information in

   the ACE entry.

=3D=3D

 

[Jon] = Actually, as I read the text above, if the additional layer of = protection is required against fragmented attacks and v-[46]-fragment is = set with action “drop”, then any non-initial fragment is = dropped – fine.

 

However, = the initial fragment skips this ACE test and goes onto the next = ACE.  Assuming that there is a “accept” that matches = everything else (i.e. we like the packet apart from when it is = fragmented), then the initial fragment is let = through.

 

The target = IP then consumes lots of RAM whilst waiting for the missing fragment = segments……..D(D)oS Success.

 

There is no = way to drop the initial fragment with the above text other than to = “drop” genuine non fragmented traffic as well.  I think = that logic is flawed to drop just subsequent = fragments.

 

[Jon] I = also wonder how the above is going to get implemented – it would = be easier to say any fragmented packet sequence is not allowed = (including the initial packet) rather than only a part of the sequence = which then leads to a DoS in its own rights.

 

No?

 

[Jon] See = above.  I do agree that flags -> fragment -> 1 is a bit = ambiguous is its definition when used to match a packet as an acl/ace, = but I do think the match intent is that the packet is not = fragmented.

 

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] = De la part de Jon Shallow
Envoy=E9 : mercredi 4 = avril 2018 15:51
=C0 : dots@ietf.org
Objet : = [Dots] Data Channel ACL fragments

 

Hi there,

 

Do we still = need to have the fragment definition for ACEs in the data = channel?

 

draft-ietf-netmod-acl-model-18 now supports fragments = for ipv4 (flags + options) and implicitly in ipv6 through the next = header field protocol set to 44 (fragment extension = header).

 

IPV4

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

  = grouping acl-ipv4-header-fields {

    description

      "Fields in IPv4 = header.";

...

    leaf flags {

      type bits = {

        bit = reserved {

          = position 0;

          = description

         &= nbsp;  "Reserved. Must be zero.";

        = }

        bit = fragment {

          = position 1;

          = description

         &= nbsp;  "Setting value to 0 indicates may fragment, while = setting

         &= nbsp;   the value to 1 indicates do not = fragment.";

        = }

        bit more = {

          = position 2;

          = description

         &= nbsp;  "Setting the value to 0 indicates this is the last = fragment,

         &= nbsp;   and setting the value to 1 indicates more fragments = are

         &= nbsp;   coming.";

        = }

      = }

      = description

        "Bit = definitions for the flags field in IPv4 header.";

    }

 

    leaf offset {

      type uint16 = {

   =      range = "20..65535";

      }

      = description

        "The = fragment offset is measured in units of 8 octets (64 = bits).

         The = first fragment has offset zero. The length is 13 = bits";

    = }

 

Regards

 

Jon

 

------=_NextPart_000_0076_01D3CCCB.1666A750-- From nobody Thu Apr 5 02:45:32 2018 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 413A91270AB for ; Thu, 5 Apr 2018 02:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1cUUdlsmWa_L for ; Thu, 5 Apr 2018 02:45:26 -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 68CD11270A7 for ; Thu, 5 Apr 2018 02:45:23 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.90_1) (envelope-from ) id 1f41SL-0007CC-ST; Thu, 05 Apr 2018 10:45:21 +0100 From: "Jon Shallow" To: , "Konda, Tirumaleswar Reddy" , References: <014f01d3cc19$2e3880e0$8aa982a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7E7B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <019901d3cc23$a93ff8e0$fbbfeaa0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8524@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <004e01d3ccb4$d505e7f0$7f11b7d0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF861C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <006e01d3ccbc$86539960$92facc20$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8650@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <007301d3ccc0$c61fb430$525f1c90$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8699@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DEF8699@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Thu, 5 Apr 2018 10:45:22 +0100 Message-ID: <008b01d3ccc2$d110d7a0$733286e0$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ5xX4UsK17va5Vv37fpNudI6+9awKIdnG+AkIt6UkCuIhgoQJj4oJpArGJQHwBTyE/FwGNdJ60AM+kxIIBh9jYzwLUo6hFogDwCoA= Content-Language: en-gb Archived-At: Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling 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, 05 Apr 2018 09:45:30 -0000 Yes -----Original Message----- From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 05 April 2018 10:34 To: Jon Shallow; Konda, Tirumaleswar Reddy; dots@ietf.org Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling Re-, ACKed.=20 I guess that this one is closed. Cheers, Med > -----Message d'origine----- > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > Envoy=E9=A0: jeudi 5 avril 2018 11:31 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy;=20 > dots@ietf.org Objet=A0: RE: [Dots] Signal Channel - 300 Redirected=20 > Signaling >=20 > Hi Med, >=20 > See inline [Jon1] >=20 > Regards >=20 > Jon >=20 >=20 > > > -----Message d'origine----- > > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > Envoy=E9=A0: jeudi 5 avril 2018 10:05 > > > =C0=A0: BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy;=20 > > > dots@ietf.org Objet=A0: RE: [Dots] Signal Channel - 300 Redirected = > > > Signaling > > > > > > Hi Med, > > > > > > Thanks for this refresh to 4.6 Redirected Signaling > > > > > > Some comments > > > > > > #1 > > > > > > The DOTS server can return the error response code 3.00 in = response > > > to a PUT request from the DOTS client or convey the error = response > > > code 3.00 in a unidirectional notification response from the = DOTS > > > server. > > > > > > Why is this limited to a PUT request and/or unidirectional=20 > > > notification response? > > > - Surely, any response, unsolicited or otherwise can contain a=20 > > > 3.00 > > > - If Observe is not in use, then any unsolicited notification=20 > > > response will potentially get rejected by the coap library layer,=20 > > > so a DOTS Server cannot signal maintenance outage other than by=20 > > > closing the > session. > > > - I missed this the last review - sorry > > > > > > > [Med] There is no restriction in the text: > > > > If a DOTS server wants to redirect a DOTS client to an = alternative > > DOTS server for a signal session, then the response code 3.00 > > (alternate server) will be returned in the response to the DOTS > > client. > > > > [Jon] Agreed this preceding paragraph is more generic (which is why=20 > > I possibly did not pick up on this), but then the para I quoted=20 > > implies it is restricted to a PUT request which is not the case. =20 > > Perhaps s/in response to a PUT request from/in response to any=20 > > request from/ which works for me. > > > > The text you quoted is about a case in which redirect is likely : " > > The DOTS server **can** return the error response code.." > > [Jon] but implied (not a MUST I agree) that it cannot be done if it=20 > > was a GET request > > >=20 > [Med] This is not what that text says. It only says that a typical=20 > usage is a response to PUT. This does not prevent a server to return=20 > for other requests. The example with PUT is more trivial compared to,=20 > for example GET/DELETE, which requires that the redirected server=20 > maintains the required information to process the request. >=20 > [Jon1] I would not be expecting the redirected server to maintain=20 > state / information, but would be expecting the DOTS client to treat=20 > the connection to the redirected Server as if the DOTS client was just = > starting up and both ends need to get synchronized (e.g. get Server's=20 > current mitigation state) before retrying any GET / PUT etc. >=20 > Anyway, to avoid misinterpreting the text, I changed it to: >=20 > The DOTS server can return the error response code 3.00 in response > to a request from the DOTS client or convey the error response code > 3.00 in a unidirectional notification response from the DOTS = server. > [Jon1] Thanks > ~jon1 >=20 > > > #2 > > > > > > If the DOTS client has been redirected to a DOTS server to = which it > > > has already sent the mitigation request within the last five = (5) > > > minutes, it MUST ignore the redirection and try to contact=20 > > > other DOTS > > > > > > s/ has already sent the mitigation request/ has already=20 > > > communicated with/ > > > > [Med] Fixed. > > [Jon] Thanks > > > > > > > > #3 > > > > > > A DOTS client MUST NOT use an alternate IP address to = contact its > > > DOTS server upon expiry of the associated TTL. > > > > > > To remove ambiguity over the use of FQDN, this could read > > > > > > A DOTS client MUST NOT use an alternate IP address to = contact its > > > DOTS server upon expiry of the associated TTL. Furthermore, = > > > a > DOTS > > > Client MUST NOT use the alt-server FQDN if all of the=20 > > > alt-server-records > > > have expired. > > > > > > > [Med] I can add this to remove ambiguity. > > [Jon} Please do > > ~jon > > > > > Or alternatively > > > > > > alt-server: FQDN of an alternate DOTS server. > > > > > > This could read > > > > > > alt-server: FQDN of an alternate DOTS server. This FQDN is=20 > > > not to be used for looking up IP addresses to use, but is there=20 > > > for the SNI extension (7.1. (D)TLS Protocol Profile) > > > > > > > > > Regards > > > > > > Jon > > > -----Original Message----- > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of=20 > > > mohamed.boucadair@orange.com > > > Sent: 05 April 2018 08:20 > > > To: Konda, Tirumaleswar Reddy; Jon Shallow; dots@ietf.org > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > Hi Tiru, > > > > > > Works for me. > > > > > > I updated the draft with the text additions that were discussed in = > > > this thread. The changes can be found at: > > > https://github.com/boucadair/draft-ietf-dots-signal-channel/blob/m > > > as > > > te > > > r/draf > > > t-ietf-dots-signal-channel.txt > > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De=A0: Konda, Tirumaleswar Reddy > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > Envoy=E9=A0: mercredi 4 avril 2018 17:40 =C0=A0: Jon Shallow; = BOUCADAIR=20 > > > > Mohamed IMT/OLN; dots@ietf.org Objet=A0: RE: > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > The TTL value returned under alt-server-record is equivalent to=20 > > > > the DNS TTL value. A DDoS mitigation provider with multiple DOTS = > > > > servers typically re-directs a DOTS client to a different DOTS=20 > > > > server only if the alternate DOTS server has the capacity to=20 > > > > handle the requests from the > > > DOTS client. > > > > > > > > We can add the following lines to avoid loops : > > > > > > > > If the DOTS client has been redirected to a DOTS server to which = > > > > it has already sent the mitigation request within the last five=20 > > > > minutes, it MUST ignore the redirection and try reaching others=20 > > > > servers listed in the local configuration or discovered using=20 > > > > dynamic means such as DHCP or SRV procedures. > > > > This prevents infinite ping-ponging between servers in case of=20 > > > > redirection loops. > > > > > > > > -Tiru > > > > > > > > > -----Original Message----- > > > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon=20 > > > > > Shallow > > > > > Sent: Wednesday, April 4, 2018 8:16 PM > > > > > To: mohamed.boucadair@orange.com; dots@ietf.org > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > Hi there, > > > > > > > > > > See inline [Jon] > > > > > > > > > > Regards > > > > > > > > > > Jon > > > > > > > > > > -----Original Message----- > > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of=20 > > > > > mohamed.boucadair@orange.com > > > > > Sent: 04 April 2018 15:07 > > > > > To: Jon Shallow; dots@ietf.org > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > Re-, > > > > > > > > > > Please see inline. > > > > > > > > > > Cheers, > > > > > Med > > > > > > > > > > > -----Message d'origine----- > > > > > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Jon = > > > > > > Shallow Envoy=E9=A0: mercredi 4 avril 2018 15:31 =C0=A0:=20 > > > > > > dots@ietf.org > > Objet=A0: > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > Hi there, > > > > > > > > > > > > I have implemented the 300 Redirected-Signal in my DOTS = code. > > > > > > This then raises some questions about usability. > > > > > > > > > > > > Usability #1 > > > > > > > > > > > > Architecture 3.2.2 Redirected Signalling > > > > > > > > > > > > 4. Having redirected the DOTS client, DOTS server A=20 > > > > > > ceases > > sending > > > > > > server signals. The DOTS client likewise stops=20 > > > > > > sending > > client > > > > > > signals to DOTS server A. DOTS session 1 is = terminated. > > > > > > > > > > > > Clearly indicates that the original session (Client to=20 > > > > > > Server > > > > > > A) is no more once redirected and only Client to Server B is = > > > > > > in > use. > > > > > > > > > > > > How is the traffic redirected back to Server A once=20 > > > > > > maintenance / overloading etc. has finished? My assumption=20 > > > > > > is that Server B sends a redirect to go back to Server A as=20 > > > > > > Server A has no way to say over a now non-existent session=20 > > > > > > to say > "come back". > > > > > > > > > > [Med] That's one possibility. This one does not require any=20 > > > > > update to the > > > > signal- > > > > > channel specification. > > > > > > > > > > Another approach would be to not require any redirect signal=20 > > > > > from server > > > B. > > > > > The client will remove server B's records upon the expiry of=20 > > > > > the TTL and > > > > will fall > > > > > back to the "base" DOTS servers configuration that was=20 > > > > > provisioned to the > > > > client > > > > > using DHCP or whatever mechanism. > > > > > [Jon] OK. The TTL is defined at, associated with the IP=20 > > > > > address level > > > > under alt- > > > > > server-record, not under > > > > > ietf-dots-signal-channel:redirected-signal. The ttl = definition is > > > > > ambiguous as to what it refers to and perhaps could be=20 > > > > > tightened up in the language (I read it as being associated=20 > > > > > with "addr" in the sense of a DNS > > > > TTL). > > > > > > > > > > > > > > > > > Do we need to keep the existing Client to Server A session=20 > > > > > > warm (or perhaps to probe periodically) to see if Server A=20 > > > > > > is capable of handling the Client again by a server response = > > > > > > extension to the protocol (e.g. a 3.01) > > > > > > > > > > [Med] Redirect was initially introduced to manage a server=20 > > > > > overload, so I > > > > don't > > > > > think it makes sense to probe or maintain a session with = server A. > > > > > [Jon] Agreed, but I needed to raise the question. > > > > > > > > > > > > > > > > > Should there be a retry period parameter added in to the=20 > > > > > > 3.00 protocol (as I read it, ttl only refers to the IP = address)? > > > > > > > > > > [Med] The client will automatically switch to Server A when=20 > > > > > all alternate > > > > records > > > > > expire. > > > > > [Jon] OK - again the 4.6 text needs to get tightened up to=20 > > > > > reflect this as > > > > the > > > > > intent. > > > > > > > > > > > > > > > > > > > > > > Usability #2 > > > > > > > > > > > > Server A says "Redirect to Server B" due to overloading. > > > > > > Server B accepts things for a while and then is=20 > > > > > > instructed/decides to redirect traffic back to A. Server A=20 > > > > > > is left still overload configured to redirect to B. How=20 > > > > > > should the client handle this as there is no suitable > > > > > Server? > > > > > > > > > > [Med] This is a service configuration problem. We may ask: > > > > > * the client to log the error and notify the administrator. > > > > > * and/or stop the redirection after n cycles. > > > > > > > > > > Still, this does not solve the problem. > > > > > [Jon] Agreed there is a problem here > > > > > > > > > > > > > > > > > I agree that there needs to be co-ordination between Server=20 > > > > > > A and Server B, but user error may creep in. > > > > > > > > > > > > Usability #3 > > > > > > > > > > > > Server A says "Redirect to Server B" as it going to be shut=20 > > > > > > down because of maintenance. Server B accepts things for a=20 > > > > > > while and then is instructed (in probable user error) to=20 > > > > > > redirect traffic back to A (perhaps because it has hit an=20 > > > > > > overload > condition). > > > > > > How should the client > > > > > handle this? > > > > > > > > > > [Med] Isn't this a sub-case or #2? > > > > > [Jon] Yes, but I wanted to bring in Server A being alive and=20 > > > > > able to > > > > respond > > > > > versus Server A down and not responding due to maintenance. > > > > > [Jon] With my better understanding of TTL we still have an=20 > > > > > issue if the TTL expires and Server A is having an extended outage. > > > > > How do we recover from that? > > > > > ~jon > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > Jon > > > > > > > > > > > > _______________________________________________ > > > > > > Dots mailing list > > > > > > Dots@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > _______________________________________________ > > > > > Dots mailing list > > > > > Dots@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > _______________________________________________ > > > > > Dots mailing list > > > > > Dots@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Thu Apr 5 03:06:47 2018 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 BA6D81270A0 for ; Thu, 5 Apr 2018 03:06:45 -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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 RUKPkOHPIRs5 for ; Thu, 5 Apr 2018 03:06:42 -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 6F8DA1200FC for ; Thu, 5 Apr 2018 03:06:42 -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=1522922801; 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: dlp-product:dlp-version:dlp-reaction: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-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-Network-Message-Id: 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=8 90yIdOhmwOHHzupuC4UdeTn5Sk9TQn7eSka/qle4O U=; b=PcrtMUOMhia6ztt82wBn3OKvVoJhxBtISugAF3npO9vK guSpNchrT63Imqrz7jdxkjyOoPWJhLGyMF41wN1nXWZ/6iLRJt UjwgRMmrbhAQes09DTuuPehGAn02gTddjA0GJIP/i6IGPhk2dZ ZGHoXBfTSqy/IiT8Jb1Ghgj7JRU= Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 68cc_190d_697f3008_6d17_4963_9e92_984fea187026; Thu, 05 Apr 2018 05:06:41 -0500 Received: from DNVEXUSR1N13.corpzone.internalzone.com (10.44.48.86) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 5 Apr 2018 04:06:25 -0600 Received: from DNVEXUSR1N13.corpzone.internalzone.com (10.44.48.86) by DNVEXUSR1N13.corpzone.internalzone.com (10.44.48.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 5 Apr 2018 04:06:24 -0600 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXUSR1N13.corpzone.internalzone.com (10.44.48.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Thu, 5 Apr 2018 04:06:24 -0600 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (10.44.176.240) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 5 Apr 2018 04:06:22 -0600 Received: from BN6PR16MB1425.namprd16.prod.outlook.com (10.172.207.19) by BN6PR16MB1668.namprd16.prod.outlook.com (10.172.27.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.653.12; Thu, 5 Apr 2018 10:06:21 +0000 Received: from BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d]) by BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d%2]) with mapi id 15.20.0653.012; Thu, 5 Apr 2018 10:06:21 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: [Dots] Signal Channel - 300 Redirected Signaling Thread-Index: AdPMGSyCaQQbv+vLSW+0gkDbU7HOEwAAo7xAAAH7T4AAARdqYAAhoxEAAAGQiwAAAKyNYA== Date: Thu, 5 Apr 2018 10:06:21 +0000 Message-ID: References: <014f01d3cc19$2e3880e0$8aa982a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7E7B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <019901d3cc23$a93ff8e0$fbbfeaa0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8524@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <004e01d3ccb4$d505e7f0$7f11b7d0$@jpshallow.com> In-Reply-To: <004e01d3ccb4$d505e7f0$7f11b7d0$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR16MB1668; 7:u1c77JgqIEVrm5JTWmrfIkkoy4tmpjj2QVNmZVnyOGT/jhuedj+6LinuF1lTfFKTU/9Ekapvw50ykBQiBquqaFW9VVMCeqbWoajQCOE5q23yangES6QNQ8/USc8Ywjbs5SXiCx43msMjaKHK0eQkY6kmjIZBWzeQWmf0++lGY7S7VbjdeNLXdygMbMfzdZ7Ri+GydM1rklHtoV61RNsOksMR2QtdHnnZ1UzMBn/x3/aLuNLI2+J7xdGgsLVCxxCj x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: de5462d6-3af1-47a8-28ef-08d59adce1e1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BN6PR16MB1668; x-ms-traffictypediagnostic: BN6PR16MB1668: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(166708455590820)(18271650672692)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231221)(944501327)(52105095)(10201501046)(93006095)(93001095)(3002001)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(20161123564045)(6072148)(201708071742011); SRVR:BN6PR16MB1668; BCL:0; PCL:0; RULEID:; SRVR:BN6PR16MB1668; x-forefront-prvs: 06339BAE63 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39380400002)(39860400002)(376002)(366004)(396003)(13464003)(32952001)(57704003)(189003)(199004)(55784002)(446003)(6506007)(80792005)(53546011)(229853002)(476003)(2501003)(7696005)(966005)(9686003)(14454004)(93886005)(2906002)(5250100002)(11346002)(6246003)(59450400001)(2201001)(3280700002)(110136005)(97736004)(486006)(478600001)(66066001)(86362001)(26005)(186003)(8936002)(102836004)(2900100001)(8676002)(6306002)(6436002)(5660300001)(7736002)(25786009)(81156014)(74316002)(3846002)(99286004)(106356001)(76176011)(72206003)(81166006)(33656002)(105586002)(316002)(68736007)(53936002)(305945005)(6116002)(3660700001)(55016002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR16MB1668; H:BN6PR16MB1425.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: SVD8wYRfAk6SMlldnbmkBDHopClHlpyOdfiOKTkg8UAz3ReRihQ3QJupU7M9ooidddDaHpJBHqZcR9HRYiqrsuD8/tPKG8OKoYQlrvPtSwBuZNkH7W5xY4jV1iSkPsBuQaF8f8sHtHEUZ9SNjyPg21HhUtganlbgI86MJgP+FQh6V9VBTMvVNtROfyo2CpJg9B9QU5sZm4EAvzYHYD0yWUzYfSdzLVjqPq744jvMBrcbdAyA24ds8x2YBHckxYfc5mQ+6FRCDvMKUSQUJSj3QVSYBIukvFzKay3vlZ9DZkq0o8E+eNy8KZe1BpvXDrHeIMLSfK65asgOdyrrQbD+vSSgPMwm/NKwv+XiKhEbRLC4wAucrhg+j0ASW5VIE1Quxzj1Ve/8LtbaPfYpAeR4ynyOygaK/U4IS1ll/Y0gC1w= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: de5462d6-3af1-47a8-28ef-08d59adce1e1 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Apr 2018 10:06:21.4754 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR16MB1668 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 <6257> : inlines <6548> : streams <1783258> : uri <2620815> Archived-At: Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling 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, 05 Apr 2018 10:06:46 -0000 > -----Original Message----- > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > Sent: Thursday, April 5, 2018 1:35 PM > To: mohamed.boucadair@orange.com; Konda, Tirumaleswar Reddy > ; dots@ietf.org > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling >=20 > Hi Med, >=20 > Thanks for this refresh to 4.6 Redirected Signaling >=20 > Some comments >=20 > #1 >=20 > The DOTS server can return the error response code 3.00 in response > to a PUT request from the DOTS client or convey the error response > code 3.00 in a unidirectional notification response from the DOTS > server. >=20 > Why is this limited to a PUT request and/or unidirectional notification r= esponse? > - Surely, any response, unsolicited or otherwise can contain a 3.00 > - If Observe is not in use, then any unsolicited notification response wi= ll > potentially get rejected by the coap library layer, so a DOTS Server cann= ot signal > maintenance outage other than by closing the session. > - I missed this the last review - sorry >=20 > #2 >=20 > If the DOTS client has been redirected to a DOTS server to which it > has already sent the mitigation request within the last five (5) > minutes, it MUST ignore the redirection and try to contact other DOTS >=20 > s/ has already sent the mitigation request/ has already communicated with= / >=20 > #3 >=20 > A DOTS client MUST NOT use an alternate IP address to contact its > DOTS server upon expiry of the associated TTL. >=20 > To remove ambiguity over the use of FQDN, this could read >=20 > A DOTS client MUST NOT use an alternate IP address to contact its > DOTS server upon expiry of the associated TTL. Furthermore, a DOTS > Client MUST NOT use the alt-server FQDN if all of the alt-server-re= cords > have expired. >=20 > Or alternatively >=20 > alt-server: FQDN of an alternate DOTS server. >=20 > This could read >=20 > alt-server: FQDN of an alternate DOTS server. This FQDN is not to be= used for > looking up IP addresses to use, but is there for the SNI extension (7.1. = (D)TLS > Protocol Profile) I don't think the above restriction is correct for the following reasons:=20 1) If the TTL value in the alt-server-record expires, DNS lookup can be per= formed by the DOTS client using the alternate DOTS server FQDN. 2) If the DNS server is reachable, the client may want to a DANE lookup to = get the IP addresses and certificate to validate the alternate DOTS server = certificate sent=20 in the DTLS handshake. -Tiru >=20 >=20 > Regards >=20 > Jon > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > mohamed.boucadair@orange.com > Sent: 05 April 2018 08:20 > To: Konda, Tirumaleswar Reddy; Jon Shallow; dots@ietf.org > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling >=20 > Hi Tiru, >=20 > Works for me. >=20 > I updated the draft with the text additions that were discussed in this > thread. The changes can be found at: > https://github.com/boucadair/draft-ietf-dots-signal-channel/blob/master/d= raf > t-ietf-dots-signal-channel.txt >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Konda, Tirumaleswar Reddy > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > Envoy=E9=A0: mercredi 4 avril 2018 17:40 > > =C0=A0: Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet=A0:= RE: > > [Dots] Signal Channel - 300 Redirected Signaling > > > > The TTL value returned under alt-server-record is equivalent to the > > DNS TTL value. A DDoS mitigation provider with multiple DOTS servers > > typically re-directs a DOTS client to a different DOTS server only if > > the alternate DOTS server has the capacity to handle the requests from > > the > DOTS client. > > > > We can add the following lines to avoid loops : > > > > If the DOTS client has been redirected to a DOTS server to which it > > has already sent the mitigation request within the last five minutes, > > it MUST ignore the redirection and try reaching others servers listed > > in the local configuration or discovered using dynamic means such as > > DHCP or SRV procedures. > > This prevents infinite ping-ponging between servers in case of > > redirection loops. > > > > -Tiru > > > > > -----Original Message----- > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow > > > Sent: Wednesday, April 4, 2018 8:16 PM > > > To: mohamed.boucadair@orange.com; dots@ietf.org > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > Hi there, > > > > > > See inline [Jon] > > > > > > Regards > > > > > > Jon > > > > > > -----Original Message----- > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > > mohamed.boucadair@orange.com > > > Sent: 04 April 2018 15:07 > > > To: Jon Shallow; dots@ietf.org > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > Re-, > > > > > > Please see inline. > > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallo= w > > > > Envoy=E9=A0: mercredi 4 avril 2018 15:31 =C0=A0: dots@ietf.org Obje= t=A0: > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > Hi there, > > > > > > > > I have implemented the 300 Redirected-Signal in my DOTS code. > > > > This then raises some questions about usability. > > > > > > > > Usability #1 > > > > > > > > Architecture 3.2.2 Redirected Signalling > > > > > > > > 4. Having redirected the DOTS client, DOTS server A ceases send= ing > > > > server signals. The DOTS client likewise stops sending clie= nt > > > > signals to DOTS server A. DOTS session 1 is terminated. > > > > > > > > Clearly indicates that the original session (Client to Server A) > > > > is no more once redirected and only Client to Server B is in use. > > > > > > > > How is the traffic redirected back to Server A once maintenance / > > > > overloading etc. has finished? My assumption is that Server B > > > > sends a redirect to go back to Server A as Server A has no way to > > > > say over a now non-existent session to say "come back". > > > > > > [Med] That's one possibility. This one does not require any update > > > to the > > signal- > > > channel specification. > > > > > > Another approach would be to not require any redirect signal from > > > server > B. > > > The client will remove server B's records upon the expiry of the TTL > > > and > > will fall > > > back to the "base" DOTS servers configuration that was provisioned > > > to the > > client > > > using DHCP or whatever mechanism. > > > [Jon] OK. The TTL is defined at, associated with the IP address > > > level > > under alt- > > > server-record, not under > > > ietf-dots-signal-channel:redirected-signal. The ttl definition is > > > ambiguous as to what it refers to and perhaps could be tightened up > > > in the language (I read it as being associated with "addr" in the > > > sense of a DNS > > TTL). > > > > > > > > > > > Do we need to keep the existing Client to Server A session warm > > > > (or perhaps to probe periodically) to see if Server A is capable > > > > of handling the Client again by a server response extension to the > > > > protocol (e.g. a 3.01) > > > > > > [Med] Redirect was initially introduced to manage a server overload, > > > so I > > don't > > > think it makes sense to probe or maintain a session with server A. > > > [Jon] Agreed, but I needed to raise the question. > > > > > > > > > > > Should there be a retry period parameter added in to the 3.00 > > > > protocol (as I read it, ttl only refers to the IP address)? > > > > > > [Med] The client will automatically switch to Server A when all > > > alternate > > records > > > expire. > > > [Jon] OK - again the 4.6 text needs to get tightened up to reflect > > > this as > > the > > > intent. > > > > > > > > > > > > > > Usability #2 > > > > > > > > Server A says "Redirect to Server B" due to overloading. Server B > > > > accepts things for a while and then is instructed/decides to > > > > redirect traffic back to A. Server A is left still overload > > > > configured to redirect to B. How should the client handle this as > > > > there is no suitable > > > Server? > > > > > > [Med] This is a service configuration problem. We may ask: > > > * the client to log the error and notify the administrator. > > > * and/or stop the redirection after n cycles. > > > > > > Still, this does not solve the problem. > > > [Jon] Agreed there is a problem here > > > > > > > > > > > I agree that there needs to be co-ordination between Server A and > > > > Server B, but user error may creep in. > > > > > > > > Usability #3 > > > > > > > > Server A says "Redirect to Server B" as it going to be shut down > > > > because of maintenance. Server B accepts things for a while and > > > > then is instructed (in probable user error) to redirect traffic > > > > back to A (perhaps because it has hit an overload condition). How > > > > should the client > > > handle this? > > > > > > [Med] Isn't this a sub-case or #2? > > > [Jon] Yes, but I wanted to bring in Server A being alive and able to > > respond > > > versus Server A down and not responding due to maintenance. > > > [Jon] With my better understanding of TTL we still have an issue if > > > the TTL expires and Server A is having an extended outage. How do > > > we recover from that? > > > ~jon > > > > > > > > > > > > Regards > > > > > > > > Jon > > > > > > > > _______________________________________________ > > > > Dots mailing list > > > > Dots@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Thu Apr 5 03:17:27 2018 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 567EC1270AE for ; Thu, 5 Apr 2018 03:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ePByjWst7IzS for ; Thu, 5 Apr 2018 03:17:22 -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 A21831201FA for ; Thu, 5 Apr 2018 03:17:22 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.90_1) (envelope-from ) id 1f41xI-0007Eb-C4; Thu, 05 Apr 2018 11:17:20 +0100 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , , References: <014f01d3cc19$2e3880e0$8aa982a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7E7B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <019901d3cc23$a93ff8e0$fbbfeaa0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8524@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <004e01d3ccb4$d505e7f0$7f11b7d0$@jpshallow.com> In-Reply-To: Date: Thu, 5 Apr 2018 11:17:20 +0100 Message-ID: <009001d3ccc7$48907020$d9b15060$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ5xX4UsK17va5Vv37fpNudI6+9awKIdnG+AkIt6UkCuIhgoQJj4oJpArGJQHwA3D0H4qI6W0hg Content-Language: en-gb Archived-At: Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling 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, 05 Apr 2018 10:17:25 -0000 See inline [Jon2] Regards Jon -----Original Message----- From: Konda, Tirumaleswar Reddy [mailto: = TirumaleswarReddy_Konda@mcafee.com] Sent: 05 April 2018 11:06 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > -----Original Message----- > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > Sent: Thursday, April 5, 2018 1:35 PM > To: mohamed.boucadair@orange.com; Konda, Tirumaleswar Reddy=20 > ; dots@ietf.org > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling >=20 > Hi Med, >=20 > Thanks for this refresh to 4.6 Redirected Signaling >=20 > Some comments >=20 > #1 >=20 > The DOTS server can return the error response code 3.00 in response > to a PUT request from the DOTS client or convey the error response > code 3.00 in a unidirectional notification response from the DOTS > server. >=20 > Why is this limited to a PUT request and/or unidirectional = notification response? > - Surely, any response, unsolicited or otherwise can contain a 3.00 > - If Observe is not in use, then any unsolicited notification response = > will potentially get rejected by the coap library layer, so a DOTS=20 > Server cannot signal maintenance outage other than by closing the = session. > - I missed this the last review - sorry >=20 > #2 >=20 > If the DOTS client has been redirected to a DOTS server to which it > has already sent the mitigation request within the last five (5) > minutes, it MUST ignore the redirection and try to contact other=20 > DOTS >=20 > s/ has already sent the mitigation request/ has already communicated=20 > with/ >=20 > #3 >=20 > A DOTS client MUST NOT use an alternate IP address to contact = its > DOTS server upon expiry of the associated TTL. >=20 > To remove ambiguity over the use of FQDN, this could read >=20 > A DOTS client MUST NOT use an alternate IP address to contact = its > DOTS server upon expiry of the associated TTL. Furthermore, a = DOTS > Client MUST NOT use the alt-server FQDN if all of the alt-server-records > have expired. >=20 > Or alternatively >=20 > alt-server: FQDN of an alternate DOTS server. >=20 > This could read >=20 > alt-server: FQDN of an alternate DOTS server. This FQDN is not to = > be used for looking up IP addresses to use, but is there for the SNI=20 > extension (7.1. (D)TLS Protocol Profile) I don't think the above restriction is correct for the following = reasons:=20 1) If the TTL value in the alt-server-record expires, DNS lookup can be performed by the DOTS client using the alternate DOTS server FQDN. 2) If the DNS server is reachable, the client may want to a DANE lookup = to get the IP addresses and certificate to validate the alternate DOTS = server certificate sent=20 in the DTLS handshake. -Tiru [Jon2] So, we are saying that TTL only refers to the IP addresses usage before they expire and then we do a FQDN lookup, or can we try to do the FQDN lookup immediately - and if that fails (DNS issues) then we can use = the IPs for the defined period of time. [I prefer to try the FQDN first]. [Jon2] Then we need a separate configurable usage lifetime entry for the alt-server before the client retries the original server (needs to be = more than 5 minutes to handle ping--pong scenario). ~jon2=20 >=20 >=20 > Regards >=20 > Jon > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of=20 > mohamed.boucadair@orange.com > Sent: 05 April 2018 08:20 > To: Konda, Tirumaleswar Reddy; Jon Shallow; dots@ietf.org > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling >=20 > Hi Tiru, >=20 > Works for me. >=20 > I updated the draft with the text additions that were discussed in=20 > this thread. The changes can be found at: > https://github.com/boucadair/draft-ietf-dots-signal-channel/blob/maste > r/draf > t-ietf-dots-signal-channel.txt >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Konda, Tirumaleswar Reddy > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > Envoy=E9=A0: mercredi 4 avril 2018 17:40 =C0=A0: Jon Shallow; = BOUCADAIR=20 > > Mohamed IMT/OLN; dots@ietf.org Objet=A0: RE: > > [Dots] Signal Channel - 300 Redirected Signaling > > > > The TTL value returned under alt-server-record is equivalent to the=20 > > DNS TTL value. A DDoS mitigation provider with multiple DOTS servers = > > typically re-directs a DOTS client to a different DOTS server only=20 > > if the alternate DOTS server has the capacity to handle the requests = > > from the > DOTS client. > > > > We can add the following lines to avoid loops : > > > > If the DOTS client has been redirected to a DOTS server to which it=20 > > has already sent the mitigation request within the last five=20 > > minutes, it MUST ignore the redirection and try reaching others=20 > > servers listed in the local configuration or discovered using=20 > > dynamic means such as DHCP or SRV procedures. > > This prevents infinite ping-ponging between servers in case of=20 > > redirection loops. > > > > -Tiru > > > > > -----Original Message----- > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow > > > Sent: Wednesday, April 4, 2018 8:16 PM > > > To: mohamed.boucadair@orange.com; dots@ietf.org > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > Hi there, > > > > > > See inline [Jon] > > > > > > Regards > > > > > > Jon > > > > > > -----Original Message----- > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of=20 > > > mohamed.boucadair@orange.com > > > Sent: 04 April 2018 15:07 > > > To: Jon Shallow; dots@ietf.org > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > Re-, > > > > > > Please see inline. > > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Jon=20 > > > > Shallow Envoy=E9=A0: mercredi 4 avril 2018 15:31 =C0=A0: = dots@ietf.org Objet=A0: > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > Hi there, > > > > > > > > I have implemented the 300 Redirected-Signal in my DOTS code. > > > > This then raises some questions about usability. > > > > > > > > Usability #1 > > > > > > > > Architecture 3.2.2 Redirected Signalling > > > > > > > > 4. Having redirected the DOTS client, DOTS server A ceases sending > > > > server signals. The DOTS client likewise stops sending client > > > > signals to DOTS server A. DOTS session 1 is terminated. > > > > > > > > Clearly indicates that the original session (Client to Server A) = > > > > is no more once redirected and only Client to Server B is in = use. > > > > > > > > How is the traffic redirected back to Server A once maintenance=20 > > > > / overloading etc. has finished? My assumption is that Server B = > > > > sends a redirect to go back to Server A as Server A has no way=20 > > > > to say over a now non-existent session to say "come back". > > > > > > [Med] That's one possibility. This one does not require any update = > > > to the > > signal- > > > channel specification. > > > > > > Another approach would be to not require any redirect signal from=20 > > > server > B. > > > The client will remove server B's records upon the expiry of the=20 > > > TTL and > > will fall > > > back to the "base" DOTS servers configuration that was provisioned = > > > to the > > client > > > using DHCP or whatever mechanism. > > > [Jon] OK. The TTL is defined at, associated with the IP address=20 > > > level > > under alt- > > > server-record, not under > > > ietf-dots-signal-channel:redirected-signal. The ttl definition = is > > > ambiguous as to what it refers to and perhaps could be tightened=20 > > > up in the language (I read it as being associated with "addr" in=20 > > > the sense of a DNS > > TTL). > > > > > > > > > > > Do we need to keep the existing Client to Server A session warm=20 > > > > (or perhaps to probe periodically) to see if Server A is capable = > > > > of handling the Client again by a server response extension to=20 > > > > the protocol (e.g. a 3.01) > > > > > > [Med] Redirect was initially introduced to manage a server=20 > > > overload, so I > > don't > > > think it makes sense to probe or maintain a session with server A. > > > [Jon] Agreed, but I needed to raise the question. > > > > > > > > > > > Should there be a retry period parameter added in to the 3.00=20 > > > > protocol (as I read it, ttl only refers to the IP address)? > > > > > > [Med] The client will automatically switch to Server A when all=20 > > > alternate > > records > > > expire. > > > [Jon] OK - again the 4.6 text needs to get tightened up to reflect = > > > this as > > the > > > intent. > > > > > > > > > > > > > > Usability #2 > > > > > > > > Server A says "Redirect to Server B" due to overloading. Server = > > > > B accepts things for a while and then is instructed/decides to=20 > > > > redirect traffic back to A. Server A is left still overload=20 > > > > configured to redirect to B. How should the client handle this=20 > > > > as there is no suitable > > > Server? > > > > > > [Med] This is a service configuration problem. We may ask: > > > * the client to log the error and notify the administrator. > > > * and/or stop the redirection after n cycles. > > > > > > Still, this does not solve the problem. > > > [Jon] Agreed there is a problem here > > > > > > > > > > > I agree that there needs to be co-ordination between Server A=20 > > > > and Server B, but user error may creep in. > > > > > > > > Usability #3 > > > > > > > > Server A says "Redirect to Server B" as it going to be shut down = > > > > because of maintenance. Server B accepts things for a while and = > > > > then is instructed (in probable user error) to redirect traffic=20 > > > > back to A (perhaps because it has hit an overload condition). =20 > > > > How should the client > > > handle this? > > > > > > [Med] Isn't this a sub-case or #2? > > > [Jon] Yes, but I wanted to bring in Server A being alive and able=20 > > > to > > respond > > > versus Server A down and not responding due to maintenance. > > > [Jon] With my better understanding of TTL we still have an issue=20 > > > if the TTL expires and Server A is having an extended outage. How = > > > do we recover from that? > > > ~jon > > > > > > > > > > > > Regards > > > > > > > > Jon > > > > > > > > _______________________________________________ > > > > Dots mailing list > > > > Dots@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Thu Apr 5 04:02:34 2018 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 A68801242F5 for ; Thu, 5 Apr 2018 04:02:32 -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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 RFVefQp2H6ho for ; Thu, 5 Apr 2018 04:02:27 -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 836A0124B18 for ; Thu, 5 Apr 2018 04:02:27 -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=1522926132; 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: dlp-product:dlp-version:dlp-reaction: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-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-Network-Message-Id: 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=Y YqBnzd7KAQQrORMO+PuQurq7WzDyI+qQteD9vYCwe w=; b=dkJprOvmfIk/yoN9/7qWStsQIRStI6G7c+KbMsviGFRv hnJOUnLOkqQ7E0wrv+1hx88TFimFlJa/R/Z24uvlHIb8T8UR8A 38YVkcUIXa85AiUP4yjcJx4H/tk8tE8SrAcCBXIs9DMn+DIPJr LGUoKWwH/bWx1Ou5pfu4TH7dil4= Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 68c8_4d44_45884db6_ba26_4b05_ba7d_dc4d3d99e550; Thu, 05 Apr 2018 06:02:11 -0500 Received: from DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 5 Apr 2018 05:01:53 -0600 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Thu, 5 Apr 2018 05:01:53 -0600 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (10.44.176.242) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 5 Apr 2018 05:01:52 -0600 Received: from BN6PR16MB1425.namprd16.prod.outlook.com (10.172.207.19) by BN6PR16MB1745.namprd16.prod.outlook.com (10.172.28.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.653.12; Thu, 5 Apr 2018 11:01:52 +0000 Received: from BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d]) by BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d%2]) with mapi id 15.20.0653.012; Thu, 5 Apr 2018 11:01:52 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: [Dots] Signal Channel - 300 Redirected Signaling Thread-Index: AdPMGSyCaQQbv+vLSW+0gkDbU7HOEwAAo7xAAAH7T4AAARdqYAAhoxEAAAGQiwAAAKyNYAAD8DgAAACDdzA= Date: Thu, 5 Apr 2018 11:01:51 +0000 Message-ID: References: <014f01d3cc19$2e3880e0$8aa982a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7E7B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <019901d3cc23$a93ff8e0$fbbfeaa0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8524@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <004e01d3ccb4$d505e7f0$7f11b7d0$@jpshallow.com> <009001d3ccc7$48907020$d9b15060$@jpshallow.com> In-Reply-To: <009001d3ccc7$48907020$d9b15060$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR16MB1745; 7:x+wkjx262EvkFVXamQtnkMiP7LmjrDUvyB9xISId3L1M1usZUT2jsPglXfuXNieexyw35ITDN132apJNI5t2CTRmExWE71sc4gZdb8wk0z8DsA5VymSbtjBYMa5qPCXHYfNwgvsH/TtkO3doW8F0DBfP1vpWfvyqgbV3kQGR61koGathmb5UxXGruPTB4Q9SFmV8eEG8BE79NLIQJ6QuROsdjXOknG0YW50UuXXrmAtamLM3mWZ6oCSPQ8BbDXwa x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 5ce757fa-e2e8-4102-44a5-08d59ae4a301 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BN6PR16MB1745; x-ms-traffictypediagnostic: BN6PR16MB1745: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(166708455590820)(18271650672692)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(3231221)(944501327)(52105095)(10201501046)(6041310)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011); SRVR:BN6PR16MB1745; BCL:0; PCL:0; RULEID:; SRVR:BN6PR16MB1745; x-forefront-prvs: 06339BAE63 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(39860400002)(376002)(39380400002)(346002)(57704003)(13464003)(55784002)(189003)(199004)(32952001)(7696005)(6306002)(7736002)(5250100002)(305945005)(2201001)(74316002)(6506007)(229853002)(68736007)(53546011)(6116002)(5660300001)(93886005)(186003)(486006)(478600001)(26005)(2501003)(86362001)(476003)(316002)(99286004)(14454004)(59450400001)(8676002)(8936002)(81166006)(81156014)(97736004)(106356001)(102836004)(11346002)(80792005)(25786009)(76176011)(33656002)(446003)(66066001)(3660700001)(110136005)(2906002)(55016002)(72206003)(966005)(105586002)(3846002)(9686003)(53936002)(3280700002)(6246003)(6436002)(2900100001)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR16MB1745; H:BN6PR16MB1425.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: lgSygklnU7DWn5msQhOeR7FRvS4WO9fHPZH6LHPW+7SvJB49XY4yU2l+QVoGoy6CHFgvhpnEw3HKISWfcwEK6M0Vnu4OgpH2+FcQ8BFJR899Y+EslvM8nCc+fJWddh29tZMJu5XKjTM2lkHYSch4OguybSou6PA5IFb8OCjze/luhpANHKPNuMMkW/s5E2n0o267IYC2ozbN3FPqIGhDFpmnHTL9HRupPtZVSeF6mIDwIU7ArlheKcNj9Buu0QStHqjwhkzaCIFG+Bx9cdrOE+M8e5Hn8Ps7nbGR0Q7suC2hZfgxdBIBQ1tTGLrrNt6xyCvt8yks4HlgoINA4StOz/Md2jUXFUSJJQaPmen+7EvoKjYuQJQg2IaS5DENtO6iNpvIvwRClV7P/eUbDD67rt2Xed3Z/ziE4ChpL2Jn5a0= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 5ce757fa-e2e8-4102-44a5-08d59ae4a301 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Apr 2018 11:01:51.9092 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR16MB1745 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 <6257> : inlines <6548> : streams <1783262> : uri <2620839> Archived-At: Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling 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, 05 Apr 2018 11:02:33 -0000 > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow > Sent: Thursday, April 5, 2018 3:47 PM > To: Konda, Tirumaleswar Reddy ; > mohamed.boucadair@orange.com; dots@ietf.org > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling >=20 > See inline [Jon2] >=20 > Regards >=20 > Jon >=20 > -----Original Message----- > From: Konda, Tirumaleswar Reddy [mailto: > TirumaleswarReddy_Konda@mcafee.com] >=20 > Sent: 05 April 2018 11:06 > To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling >=20 > > -----Original Message----- > > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > Sent: Thursday, April 5, 2018 1:35 PM > > To: mohamed.boucadair@orange.com; Konda, Tirumaleswar Reddy > > ; dots@ietf.org > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > Hi Med, > > > > Thanks for this refresh to 4.6 Redirected Signaling > > > > Some comments > > > > #1 > > > > The DOTS server can return the error response code 3.00 in response > > to a PUT request from the DOTS client or convey the error response > > code 3.00 in a unidirectional notification response from the DOTS > > server. > > > > Why is this limited to a PUT request and/or unidirectional > > notification > response? > > - Surely, any response, unsolicited or otherwise can contain a 3.00 > > - If Observe is not in use, then any unsolicited notification response > > will potentially get rejected by the coap library layer, so a DOTS > > Server cannot signal maintenance outage other than by closing the sessi= on. > > - I missed this the last review - sorry >=20 > > > > #2 > > > > If the DOTS client has been redirected to a DOTS server to which it > > has already sent the mitigation request within the last five (5) > > minutes, it MUST ignore the redirection and try to contact other > > DOTS > > > > s/ has already sent the mitigation request/ has already communicated > > with/ > > > > #3 > > > > A DOTS client MUST NOT use an alternate IP address to contact its > > DOTS server upon expiry of the associated TTL. > > > > To remove ambiguity over the use of FQDN, this could read > > > > A DOTS client MUST NOT use an alternate IP address to contact its > > DOTS server upon expiry of the associated TTL. Furthermore, a DO= TS > > Client MUST NOT use the alt-server FQDN if all of the > alt-server-records > > have expired. > > > > Or alternatively > > > > alt-server: FQDN of an alternate DOTS server. > > > > This could read > > > > alt-server: FQDN of an alternate DOTS server. This FQDN is not to > > be used for looking up IP addresses to use, but is there for the SNI > > extension (7.1. (D)TLS Protocol Profile) >=20 > I don't think the above restriction is correct for the following reasons: >=20 > 1) If the TTL value in the alt-server-record expires, DNS lookup can be p= erformed > by the DOTS client using the alternate DOTS server FQDN. > 2) If the DNS server is reachable, the client may want to a DANE lookup t= o get > the IP addresses and certificate to validate the alternate DOTS server ce= rtificate > sent > in the DTLS handshake. >=20 > -Tiru > [Jon2] So, we are saying that TTL only refers to the IP addresses usage b= efore > they expire and then we do a FQDN lookup, or can we try to do the FQDN > lookup immediately - and if that fails (DNS issues) then we can use the I= Ps for the > defined period of time. [I prefer to try the FQDN first]. Yes.=20 >=20 > [Jon2] Then we need a separate configurable usage lifetime entry for the = alt- > server before the client retries the original server (needs to be more th= an 5 > minutes to handle ping--pong scenario). What is the problem if a separate configurable usage lifetime is not provid= ed, and the client continues to use the alternate server ? Cheers, -Tiru > ~jon2 > > > > > > Regards > > > > Jon > > -----Original Message----- > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > mohamed.boucadair@orange.com > > Sent: 05 April 2018 08:20 > > To: Konda, Tirumaleswar Reddy; Jon Shallow; dots@ietf.org > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > Hi Tiru, > > > > Works for me. > > > > I updated the draft with the text additions that were discussed in > > this thread. The changes can be found at: > > https://github.com/boucadair/draft-ietf-dots-signal-channel/blob/maste > > r/draf > > t-ietf-dots-signal-channel.txt > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: Konda, Tirumaleswar Reddy > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > Envoy=E9=A0: mercredi 4 avril 2018 17:40 =C0=A0: Jon Shallow; BOUCADA= IR > > > Mohamed IMT/OLN; dots@ietf.org Objet=A0: RE: > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > The TTL value returned under alt-server-record is equivalent to the > > > DNS TTL value. A DDoS mitigation provider with multiple DOTS servers > > > typically re-directs a DOTS client to a different DOTS server only > > > if the alternate DOTS server has the capacity to handle the requests > > > from the > > DOTS client. > > > > > > We can add the following lines to avoid loops : > > > > > > If the DOTS client has been redirected to a DOTS server to which it > > > has already sent the mitigation request within the last five > > > minutes, it MUST ignore the redirection and try reaching others > > > servers listed in the local configuration or discovered using > > > dynamic means such as DHCP or SRV procedures. > > > This prevents infinite ping-ponging between servers in case of > > > redirection loops. > > > > > > -Tiru > > > > > > > -----Original Message----- > > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow > > > > Sent: Wednesday, April 4, 2018 8:16 PM > > > > To: mohamed.boucadair@orange.com; dots@ietf.org > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > Hi there, > > > > > > > > See inline [Jon] > > > > > > > > Regards > > > > > > > > Jon > > > > > > > > -----Original Message----- > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > > > mohamed.boucadair@orange.com > > > > Sent: 04 April 2018 15:07 > > > > To: Jon Shallow; dots@ietf.org > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > Re-, > > > > > > > > Please see inline. > > > > > > > > Cheers, > > > > Med > > > > > > > > > -----Message d'origine----- > > > > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Jon > > > > > Shallow Envoy=E9=A0: mercredi 4 avril 2018 15:31 =C0=A0: dots@iet= f.org > Objet=A0: > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > Hi there, > > > > > > > > > > I have implemented the 300 Redirected-Signal in my DOTS code. > > > > > This then raises some questions about usability. > > > > > > > > > > Usability #1 > > > > > > > > > > Architecture 3.2.2 Redirected Signalling > > > > > > > > > > 4. Having redirected the DOTS client, DOTS server A ceases > sending > > > > > server signals. The DOTS client likewise stops sending > client > > > > > signals to DOTS server A. DOTS session 1 is terminated. > > > > > > > > > > Clearly indicates that the original session (Client to Server A) > > > > > is no more once redirected and only Client to Server B is in use. > > > > > > > > > > How is the traffic redirected back to Server A once maintenance > > > > > / overloading etc. has finished? My assumption is that Server B > > > > > sends a redirect to go back to Server A as Server A has no way > > > > > to say over a now non-existent session to say "come back". > > > > > > > > [Med] That's one possibility. This one does not require any update > > > > to the > > > signal- > > > > channel specification. > > > > > > > > Another approach would be to not require any redirect signal from > > > > server > > B. > > > > The client will remove server B's records upon the expiry of the > > > > TTL and > > > will fall > > > > back to the "base" DOTS servers configuration that was provisioned > > > > to the > > > client > > > > using DHCP or whatever mechanism. > > > > [Jon] OK. The TTL is defined at, associated with the IP address > > > > level > > > under alt- > > > > server-record, not under > > > > ietf-dots-signal-channel:redirected-signal. The ttl definition is > > > > ambiguous as to what it refers to and perhaps could be tightened > > > > up in the language (I read it as being associated with "addr" in > > > > the sense of a DNS > > > TTL). > > > > > > > > > > > > > > Do we need to keep the existing Client to Server A session warm > > > > > (or perhaps to probe periodically) to see if Server A is capable > > > > > of handling the Client again by a server response extension to > > > > > the protocol (e.g. a 3.01) > > > > > > > > [Med] Redirect was initially introduced to manage a server > > > > overload, so I > > > don't > > > > think it makes sense to probe or maintain a session with server A. > > > > [Jon] Agreed, but I needed to raise the question. > > > > > > > > > > > > > > Should there be a retry period parameter added in to the 3.00 > > > > > protocol (as I read it, ttl only refers to the IP address)? > > > > > > > > [Med] The client will automatically switch to Server A when all > > > > alternate > > > records > > > > expire. > > > > [Jon] OK - again the 4.6 text needs to get tightened up to reflect > > > > this as > > > the > > > > intent. > > > > > > > > > > > > > > > > > > Usability #2 > > > > > > > > > > Server A says "Redirect to Server B" due to overloading. Server > > > > > B accepts things for a while and then is instructed/decides to > > > > > redirect traffic back to A. Server A is left still overload > > > > > configured to redirect to B. How should the client handle this > > > > > as there is no suitable > > > > Server? > > > > > > > > [Med] This is a service configuration problem. We may ask: > > > > * the client to log the error and notify the administrator. > > > > * and/or stop the redirection after n cycles. > > > > > > > > Still, this does not solve the problem. > > > > [Jon] Agreed there is a problem here > > > > > > > > > > > > > > I agree that there needs to be co-ordination between Server A > > > > > and Server B, but user error may creep in. > > > > > > > > > > Usability #3 > > > > > > > > > > Server A says "Redirect to Server B" as it going to be shut down > > > > > because of maintenance. Server B accepts things for a while and > > > > > then is instructed (in probable user error) to redirect traffic > > > > > back to A (perhaps because it has hit an overload condition). > > > > > How should the client > > > > handle this? > > > > > > > > [Med] Isn't this a sub-case or #2? > > > > [Jon] Yes, but I wanted to bring in Server A being alive and able > > > > to > > > respond > > > > versus Server A down and not responding due to maintenance. > > > > [Jon] With my better understanding of TTL we still have an issue > > > > if the TTL expires and Server A is having an extended outage. How > > > > do we recover from that? > > > > ~jon > > > > > > > > > > > > > > > Regards > > > > > > > > > > Jon > > > > > > > > > > _______________________________________________ > > > > > Dots mailing list > > > > > Dots@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > _______________________________________________ > > > > Dots mailing list > > > > Dots@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > _______________________________________________ > > > > Dots mailing list > > > > Dots@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots >=20 >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Thu Apr 5 04:20:15 2018 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 8183112D87F for ; Thu, 5 Apr 2018 04:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 TwDE2Amob3At for ; Thu, 5 Apr 2018 04:20:11 -0700 (PDT) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD96512711A for ; Thu, 5 Apr 2018 04:20:10 -0700 (PDT) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 2C4481202DD; Thu, 5 Apr 2018 13:20:09 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.60]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 0C3EF1600A0; Thu, 5 Apr 2018 13:20:09 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7F.corporate.adroot.infra.ftgroup ([fe80::c1d7:e278:e357:11ad%19]) with mapi id 14.03.0382.000; Thu, 5 Apr 2018 13:20:08 +0200 From: To: "Konda, Tirumaleswar Reddy" , "Jon Shallow" , "dots@ietf.org" Thread-Topic: [Dots] Signal Channel - 300 Redirected Signaling Thread-Index: AdPMGSyCaQQbv+vLSW+0gkDbU7HOEwAAo7xAAAH7T4AAARdqYAAhoxEAAAGQiwAAAKyNYAAF3e1Q Date: Thu, 5 Apr 2018 11:20:08 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DEF8758@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <014f01d3cc19$2e3880e0$8aa982a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7E7B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <019901d3cc23$a93ff8e0$fbbfeaa0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8524@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <004e01d3ccb4$d505e7f0$7f11b7d0$@jpshallow.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling 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, 05 Apr 2018 11:20:13 -0000 Tiru,=20 I don't see the NEW text as a restriction but as a simplification of the cl= ient's behavior. I don't want to over-specify the redirect behavior.=20 Adding another yet layer of resolution will raise other issues such as the = need to associate a TTL with the name itself.=20 Cheers, Med > -----Message d'origine----- > De=A0: Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.c= om] > Envoy=E9=A0: jeudi 5 avril 2018 12:06 > =C0=A0: Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org > Objet=A0: RE: [Dots] Signal Channel - 300 Redirected Signaling >=20 > > -----Original Message----- > > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > Sent: Thursday, April 5, 2018 1:35 PM > > To: mohamed.boucadair@orange.com; Konda, Tirumaleswar Reddy > > ; dots@ietf.org > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > Hi Med, > > > > Thanks for this refresh to 4.6 Redirected Signaling > > > > Some comments > > > > #1 > > > > The DOTS server can return the error response code 3.00 in response > > to a PUT request from the DOTS client or convey the error response > > code 3.00 in a unidirectional notification response from the DOTS > > server. > > > > Why is this limited to a PUT request and/or unidirectional notification > response? > > - Surely, any response, unsolicited or otherwise can contain a 3.00 > > - If Observe is not in use, then any unsolicited notification response = will > > potentially get rejected by the coap library layer, so a DOTS Server ca= nnot > signal > > maintenance outage other than by closing the session. > > - I missed this the last review - sorry >=20 > > > > #2 > > > > If the DOTS client has been redirected to a DOTS server to which it > > has already sent the mitigation request within the last five (5) > > minutes, it MUST ignore the redirection and try to contact other DOT= S > > > > s/ has already sent the mitigation request/ has already communicated wi= th/ > > > > #3 > > > > A DOTS client MUST NOT use an alternate IP address to contact its > > DOTS server upon expiry of the associated TTL. > > > > To remove ambiguity over the use of FQDN, this could read > > > > A DOTS client MUST NOT use an alternate IP address to contact its > > DOTS server upon expiry of the associated TTL. Furthermore, a DO= TS > > Client MUST NOT use the alt-server FQDN if all of the alt-server- > records > > have expired. > > > > Or alternatively > > > > alt-server: FQDN of an alternate DOTS server. > > > > This could read > > > > alt-server: FQDN of an alternate DOTS server. This FQDN is not to = be > used for > > looking up IP addresses to use, but is there for the SNI extension (7.1= . > (D)TLS > > Protocol Profile) >=20 > I don't think the above restriction is correct for the following reasons: >=20 > 1) If the TTL value in the alt-server-record expires, DNS lookup can be > performed by the DOTS client using the alternate DOTS server FQDN. > 2) If the DNS server is reachable, the client may want to a DANE lookup t= o > get the IP addresses and certificate to validate the alternate DOTS serve= r > certificate sent > in the DTLS handshake. >=20 > -Tiru >=20 > > > > > > Regards > > > > Jon > > -----Original Message----- > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > mohamed.boucadair@orange.com > > Sent: 05 April 2018 08:20 > > To: Konda, Tirumaleswar Reddy; Jon Shallow; dots@ietf.org > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > Hi Tiru, > > > > Works for me. > > > > I updated the draft with the text additions that were discussed in this > > thread. The changes can be found at: > > https://github.com/boucadair/draft-ietf-dots-signal- > channel/blob/master/draf > > t-ietf-dots-signal-channel.txt > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: Konda, Tirumaleswar Reddy > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > Envoy=E9=A0: mercredi 4 avril 2018 17:40 > > > =C0=A0: Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet= =A0: RE: > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > The TTL value returned under alt-server-record is equivalent to the > > > DNS TTL value. A DDoS mitigation provider with multiple DOTS servers > > > typically re-directs a DOTS client to a different DOTS server only if > > > the alternate DOTS server has the capacity to handle the requests fro= m > > > the > > DOTS client. > > > > > > We can add the following lines to avoid loops : > > > > > > If the DOTS client has been redirected to a DOTS server to which it > > > has already sent the mitigation request within the last five minutes, > > > it MUST ignore the redirection and try reaching others servers listed > > > in the local configuration or discovered using dynamic means such as > > > DHCP or SRV procedures. > > > This prevents infinite ping-ponging between servers in case of > > > redirection loops. > > > > > > -Tiru > > > > > > > -----Original Message----- > > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow > > > > Sent: Wednesday, April 4, 2018 8:16 PM > > > > To: mohamed.boucadair@orange.com; dots@ietf.org > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > Hi there, > > > > > > > > See inline [Jon] > > > > > > > > Regards > > > > > > > > Jon > > > > > > > > -----Original Message----- > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > > > mohamed.boucadair@orange.com > > > > Sent: 04 April 2018 15:07 > > > > To: Jon Shallow; dots@ietf.org > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > Re-, > > > > > > > > Please see inline. > > > > > > > > Cheers, > > > > Med > > > > > > > > > -----Message d'origine----- > > > > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shal= low > > > > > Envoy=E9=A0: mercredi 4 avril 2018 15:31 =C0=A0: dots@ietf.org Ob= jet=A0: > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > Hi there, > > > > > > > > > > I have implemented the 300 Redirected-Signal in my DOTS code. > > > > > This then raises some questions about usability. > > > > > > > > > > Usability #1 > > > > > > > > > > Architecture 3.2.2 Redirected Signalling > > > > > > > > > > 4. Having redirected the DOTS client, DOTS server A ceases > sending > > > > > server signals. The DOTS client likewise stops sending cl= ient > > > > > signals to DOTS server A. DOTS session 1 is terminated. > > > > > > > > > > Clearly indicates that the original session (Client to Server A) > > > > > is no more once redirected and only Client to Server B is in use. > > > > > > > > > > How is the traffic redirected back to Server A once maintenance / > > > > > overloading etc. has finished? My assumption is that Server B > > > > > sends a redirect to go back to Server A as Server A has no way to > > > > > say over a now non-existent session to say "come back". > > > > > > > > [Med] That's one possibility. This one does not require any update > > > > to the > > > signal- > > > > channel specification. > > > > > > > > Another approach would be to not require any redirect signal from > > > > server > > B. > > > > The client will remove server B's records upon the expiry of the TT= L > > > > and > > > will fall > > > > back to the "base" DOTS servers configuration that was provisioned > > > > to the > > > client > > > > using DHCP or whatever mechanism. > > > > [Jon] OK. The TTL is defined at, associated with the IP address > > > > level > > > under alt- > > > > server-record, not under > > > > ietf-dots-signal-channel:redirected-signal. The ttl definition is > > > > ambiguous as to what it refers to and perhaps could be tightened up > > > > in the language (I read it as being associated with "addr" in the > > > > sense of a DNS > > > TTL). > > > > > > > > > > > > > > Do we need to keep the existing Client to Server A session warm > > > > > (or perhaps to probe periodically) to see if Server A is capable > > > > > of handling the Client again by a server response extension to th= e > > > > > protocol (e.g. a 3.01) > > > > > > > > [Med] Redirect was initially introduced to manage a server overload= , > > > > so I > > > don't > > > > think it makes sense to probe or maintain a session with server A. > > > > [Jon] Agreed, but I needed to raise the question. > > > > > > > > > > > > > > Should there be a retry period parameter added in to the 3.00 > > > > > protocol (as I read it, ttl only refers to the IP address)? > > > > > > > > [Med] The client will automatically switch to Server A when all > > > > alternate > > > records > > > > expire. > > > > [Jon] OK - again the 4.6 text needs to get tightened up to reflect > > > > this as > > > the > > > > intent. > > > > > > > > > > > > > > > > > > Usability #2 > > > > > > > > > > Server A says "Redirect to Server B" due to overloading. Server = B > > > > > accepts things for a while and then is instructed/decides to > > > > > redirect traffic back to A. Server A is left still overload > > > > > configured to redirect to B. How should the client handle this a= s > > > > > there is no suitable > > > > Server? > > > > > > > > [Med] This is a service configuration problem. We may ask: > > > > * the client to log the error and notify the administrator. > > > > * and/or stop the redirection after n cycles. > > > > > > > > Still, this does not solve the problem. > > > > [Jon] Agreed there is a problem here > > > > > > > > > > > > > > I agree that there needs to be co-ordination between Server A and > > > > > Server B, but user error may creep in. > > > > > > > > > > Usability #3 > > > > > > > > > > Server A says "Redirect to Server B" as it going to be shut down > > > > > because of maintenance. Server B accepts things for a while and > > > > > then is instructed (in probable user error) to redirect traffic > > > > > back to A (perhaps because it has hit an overload condition). Ho= w > > > > > should the client > > > > handle this? > > > > > > > > [Med] Isn't this a sub-case or #2? > > > > [Jon] Yes, but I wanted to bring in Server A being alive and able t= o > > > respond > > > > versus Server A down and not responding due to maintenance. > > > > [Jon] With my better understanding of TTL we still have an issue if > > > > the TTL expires and Server A is having an extended outage. How do > > > > we recover from that? > > > > ~jon > > > > > > > > > > > > > > > Regards > > > > > > > > > > Jon > > > > > > > > > > _______________________________________________ > > > > > Dots mailing list > > > > > Dots@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > _______________________________________________ > > > > Dots mailing list > > > > Dots@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > _______________________________________________ > > > > Dots mailing list > > > > Dots@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots From nobody Thu Apr 5 17:45:54 2018 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 26BF6126C2F for ; Thu, 5 Apr 2018 17:45:52 -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, 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=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 TqSSqkOL5Ort for ; Thu, 5 Apr 2018 17:45:50 -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 46180126B6E for ; Thu, 5 Apr 2018 17:45:50 -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 w360jnnD009672 for ; Thu, 5 Apr 2018 20:45:49 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu w360jnnD009672 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1522975549; bh=SziysiVnTQ+TFwWqHxTCTQb60k+eJSzyg0kd4cV/MmU=; h=From:To:Subject:Date:References:In-Reply-To:From; b=pWMqH2JQgXYFA9OJ+P5m62bC1gp63SUDgpzIiq/ljVrxuGje1MKJo/nuWL5pI6SRM lE6mBsU7JxuNaQyq8uQYLBFt4LojH+I+M19GDDBc9q66mfqezrxhZx5AkkL9ZJTlZ2 SMEu5cfcxmGFDAzBE8lK9wmbbs3t30MncsGrOGzg= 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 w360jkeZ023488 for ; Thu, 5 Apr 2018 20:45:46 -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.0361.001; Thu, 5 Apr 2018 20:45:46 -0400 From: Roman Danyliw To: "dots@ietf.org" Thread-Topic: Second WGLC on DOTS Requirements Thread-Index: AdPA+oGkaVa8XBIIQ8eK5rKDFxYNQAMRfJrg Date: Fri, 6 Apr 2018 00:45:45 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC014C37BE3A@marathon> References: <359EC4B99E040048A7131E0F4E113AFC014C36B7BB@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC014C36B7BB@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: Re: [Dots] Second WGLC on DOTS Requirements 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, 06 Apr 2018 00:45:52 -0000 Hello! The WGLC for draft-ietf-dots-requirements is now closed. Thank you for you= r input. Roman > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Roman Danyliw > Sent: Wednesday, March 21, 2018 6:16 AM > To: dots@ietf.org > Subject: [Dots] Second WGLC on DOTS Requirements >=20 > Hello! >=20 > Consistent with our discussion at the London meeting, we are starting a > second working group last call (WGLC) for the DOTS Requirements draft: >=20 > Distributed Denial of Service (DDoS) Open Threat Signaling Requirements > draft-ietf-dots-requirements-14 > https://tools.ietf.org/html/draft-ietf-dots-requirements-14 >=20 > Please send comments to the DOTS mailing list. The WG welcomes feedback > on needed changes as well as endorsements that this draft is ready. >=20 > This second WGLC will end on April 4, 2018. >=20 > Thanks, > Roman >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Thu Apr 5 22:06:52 2018 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 CCF8712E885 for ; Thu, 5 Apr 2018 22:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 VAFiwEWAKCKi for ; Thu, 5 Apr 2018 22:06:48 -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 2668312783A for ; Thu, 5 Apr 2018 22:06:48 -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=1522991196; 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: dlp-product:dlp-version:dlp-reaction: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-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-Network-Message-Id: 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=qHjj1N4GTXdjxKMiKkcaKW47CVmVJ8Blrt/EZ7 t6SC4=; b=T2JZS0SD8XIXH+uOlFLfprx4oJsgiHIOyRCGw4xT LvzOTGXoIbSDuX15aoya0cQwEDfLuAa/T00iFVoQYuTlWPjjX4 MUu6fzkMTmBWtb/f467IJ5c5pmELeUVCxD4MesHxySpe3scb5z jVgj70uLEnE6kUkUNLF1VahBVHJ10GA= Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 3b68_299d_e37cce65_7e97_4ac5_8d1b_8604a608b28d; Fri, 06 Apr 2018 00:06:35 -0500 Received: from DNVEXUSR1N11.corpzone.internalzone.com (10.44.48.84) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 5 Apr 2018 23:06:34 -0600 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXUSR1N11.corpzone.internalzone.com (10.44.48.84) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Thu, 5 Apr 2018 23:06:34 -0600 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 5 Apr 2018 23:06:34 -0600 Received: from BN6PR16MB1425.namprd16.prod.outlook.com (10.172.207.19) by BN6PR16MB1379.namprd16.prod.outlook.com (10.172.207.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.653.12; Fri, 6 Apr 2018 05:06:32 +0000 Received: from BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d]) by BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d%2]) with mapi id 15.20.0653.012; Fri, 6 Apr 2018 05:06:32 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Signal Channel - 300 Redirected Signaling Thread-Index: AdPMGSyCaQQbv+vLSW+0gkDbU7HOEwAAo7xAAAH7T4AAARdqYAAhoxEAAAGQiwAAAKyNYAAF3e1QACUKCFA= Date: Fri, 6 Apr 2018 05:06:32 +0000 Message-ID: References: <014f01d3cc19$2e3880e0$8aa982a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7E7B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <019901d3cc23$a93ff8e0$fbbfeaa0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8524@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <004e01d3ccb4$d505e7f0$7f11b7d0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8758@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DEF8758@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR16MB1379; 7:wqxjYuny+f4QuNiCYMBHM+Sm7yaeBhJYzUfB9W7Ts6EDXXY2e1IaxJYqwg5imquf3hbgee1nPdZ5Ue6qta1hwDHiwF2cWrg/vuQmIe11G0yt74Q9Jp6kJ3vgW/YtxHgPu5cBNxnh7nluoHDeko+2Q8KtxFGZF/9sZ9tyBb/lyYVL5UsUUcd1baUtsHZ24JitNV8AltGWIeND/TSIHr3Clr+fmGuwCl5FaAzAbXtMfNV8pfmvFqqbfpbXAxnNU1mH x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: e654ca40-13c8-480c-9c6c-08d59b7c2a05 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BN6PR16MB1379; x-ms-traffictypediagnostic: BN6PR16MB1379: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(166708455590820)(18271650672692)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(3231221)(944501327)(52105095)(6041310)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(6072148)(201708071742011); SRVR:BN6PR16MB1379; BCL:0; PCL:0; RULEID:; SRVR:BN6PR16MB1379; x-forefront-prvs: 0634F37BFF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39380400002)(376002)(39860400002)(366004)(346002)(396003)(32952001)(55784002)(57704003)(199004)(13464003)(189003)(25786009)(6246003)(476003)(86362001)(74316002)(99286004)(5660300001)(33656002)(186003)(9686003)(26005)(76176011)(5250100002)(229853002)(486006)(68736007)(102836004)(2906002)(80792005)(97736004)(59450400001)(6436002)(305945005)(110136005)(3280700002)(2900100001)(6306002)(7696005)(55016002)(3660700001)(2501003)(11346002)(316002)(105586002)(106356001)(6116002)(72206003)(81166006)(966005)(93886005)(3846002)(478600001)(81156014)(6506007)(66066001)(446003)(8936002)(14454004)(7736002)(8676002)(53936002)(53546011)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR16MB1379; H:BN6PR16MB1425.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: MNiSHeTUm7GK+dsk4H93/MkoTigfrpeEiBzDiJCBCPkKCeQCYky14DscaBhX2EdIebsyL8jqesvbC6Rlr0bSRQKQdn2FK8nOSeD0G7JCe00bE3cgbob0yF2ZDNY7+BhcjvSRKdFBh7GIsXU/WLpXHXStTamxhZ7uVA/Oz2TV95IWDvD7oC7cJizmmT6lLBgGJbbMP0tqyn0fARIV/W8LZ7EzUARR2KzGuXRLgTYV+24XMTnAfQc5MiMb8iqo23WOjfHlXwqzbrgWirZq6RPIrGdg369r2BlbWx7L0srwGm4kr1vyJOxPWhKaaTpJJLHf7P4YeC5qpMWeg+JA1nTXM+nTfSsNhAI4T+uBiaxbZXwoflsYIxHPhulf1n4yU0QBZIBIh6AxHcjUNAMAAXXvKZlm+C1StxVJJDfVTzjJ/xQ= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e654ca40-13c8-480c-9c6c-08d59b7c2a05 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2018 05:06:32.4242 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR16MB1379 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6258> : inlines <6551> : streams <1783333> : uri <2621252> Archived-At: Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling 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, 06 Apr 2018 05:06:51 -0000 Hi Med, The proposed update restricts the client no to do a DNS lookup using the al= ternate FQDN, further associating a TTL with the name complicates the funct= ionality on the DOTS client to re-establish (D)TLS session with the primary= DOTS server after the TTL expires. My suggestion is to let the DOTS clien= t continue to use the alternate DOTS server till it gets re-directed. I don= 't think the DOTS mitigation provider will know ahead-of-time the TTL value= after which the DOTS client should disconnect communicating with the alter= nate DOTS server and re-establish=20 (D)TLS session with the primary DOTS server.=20 Cheers, -Tiru > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of > mohamed.boucadair@orange.com > Sent: Thursday, April 5, 2018 4:50 PM > To: Konda, Tirumaleswar Reddy ; > Jon Shallow ; dots@ietf.org > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling >=20 > Tiru, >=20 > I don't see the NEW text as a restriction but as a simplification of the = client's > behavior. I don't want to over-specify the redirect behavior. >=20 > Adding another yet layer of resolution will raise other issues such as th= e need to > associate a TTL with the name itself. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Konda, Tirumaleswar Reddy > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > Envoy=E9=A0: jeudi 5 avril 2018 12:06 > > =C0=A0: Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet=A0:= RE: > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > -----Original Message----- > > > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > Sent: Thursday, April 5, 2018 1:35 PM > > > To: mohamed.boucadair@orange.com; Konda, Tirumaleswar Reddy > > > ; dots@ietf.org > > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > Hi Med, > > > > > > Thanks for this refresh to 4.6 Redirected Signaling > > > > > > Some comments > > > > > > #1 > > > > > > The DOTS server can return the error response code 3.00 in respons= e > > > to a PUT request from the DOTS client or convey the error response > > > code 3.00 in a unidirectional notification response from the DOTS > > > server. > > > > > > Why is this limited to a PUT request and/or unidirectional > > > notification > > response? > > > - Surely, any response, unsolicited or otherwise can contain a 3.00 > > > - If Observe is not in use, then any unsolicited notification > > > response will potentially get rejected by the coap library layer, so > > > a DOTS Server cannot > > signal > > > maintenance outage other than by closing the session. > > > - I missed this the last review - sorry > > > > > > > > #2 > > > > > > If the DOTS client has been redirected to a DOTS server to which i= t > > > has already sent the mitigation request within the last five (5) > > > minutes, it MUST ignore the redirection and try to contact other > > > DOTS > > > > > > s/ has already sent the mitigation request/ has already communicated > > > with/ > > > > > > #3 > > > > > > A DOTS client MUST NOT use an alternate IP address to contact i= ts > > > DOTS server upon expiry of the associated TTL. > > > > > > To remove ambiguity over the use of FQDN, this could read > > > > > > A DOTS client MUST NOT use an alternate IP address to contact i= ts > > > DOTS server upon expiry of the associated TTL. Furthermore, a = DOTS > > > Client MUST NOT use the alt-server FQDN if all of the > > > alt-server- > > records > > > have expired. > > > > > > Or alternatively > > > > > > alt-server: FQDN of an alternate DOTS server. > > > > > > This could read > > > > > > alt-server: FQDN of an alternate DOTS server. This FQDN is not > > > to be > > used for > > > looking up IP addresses to use, but is there for the SNI extension (7= .1. > > (D)TLS > > > Protocol Profile) > > > > I don't think the above restriction is correct for the following reason= s: > > > > 1) If the TTL value in the alt-server-record expires, DNS lookup can > > be performed by the DOTS client using the alternate DOTS server FQDN. > > 2) If the DNS server is reachable, the client may want to a DANE > > lookup to get the IP addresses and certificate to validate the > > alternate DOTS server certificate sent > > in the DTLS handshake. > > > > -Tiru > > > > > > > > > > > Regards > > > > > > Jon > > > -----Original Message----- > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > > mohamed.boucadair@orange.com > > > Sent: 05 April 2018 08:20 > > > To: Konda, Tirumaleswar Reddy; Jon Shallow; dots@ietf.org > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > Hi Tiru, > > > > > > Works for me. > > > > > > I updated the draft with the text additions that were discussed in > > > this thread. The changes can be found at: > > > https://github.com/boucadair/draft-ietf-dots-signal- > > channel/blob/master/draf > > > t-ietf-dots-signal-channel.txt > > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De=A0: Konda, Tirumaleswar Reddy > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > Envoy=E9=A0: mercredi 4 avril 2018 17:40 =C0=A0: Jon Shallow; BOUCA= DAIR > > > > Mohamed IMT/OLN; dots@ietf.org Objet=A0: RE: > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > The TTL value returned under alt-server-record is equivalent to > > > > the DNS TTL value. A DDoS mitigation provider with multiple DOTS > > > > servers typically re-directs a DOTS client to a different DOTS > > > > server only if the alternate DOTS server has the capacity to > > > > handle the requests from the > > > DOTS client. > > > > > > > > We can add the following lines to avoid loops : > > > > > > > > If the DOTS client has been redirected to a DOTS server to which > > > > it has already sent the mitigation request within the last five > > > > minutes, it MUST ignore the redirection and try reaching others > > > > servers listed in the local configuration or discovered using > > > > dynamic means such as DHCP or SRV procedures. > > > > This prevents infinite ping-ponging between servers in case of > > > > redirection loops. > > > > > > > > -Tiru > > > > > > > > > -----Original Message----- > > > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon > > > > > Shallow > > > > > Sent: Wednesday, April 4, 2018 8:16 PM > > > > > To: mohamed.boucadair@orange.com; dots@ietf.org > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > Hi there, > > > > > > > > > > See inline [Jon] > > > > > > > > > > Regards > > > > > > > > > > Jon > > > > > > > > > > -----Original Message----- > > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > > > > mohamed.boucadair@orange.com > > > > > Sent: 04 April 2018 15:07 > > > > > To: Jon Shallow; dots@ietf.org > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > Re-, > > > > > > > > > > Please see inline. > > > > > > > > > > Cheers, > > > > > Med > > > > > > > > > > > -----Message d'origine----- > > > > > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Jon > > > > > > Shallow Envoy=E9=A0: mercredi 4 avril 2018 15:31 =C0=A0: dots@i= etf.org Objet=A0: > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > Hi there, > > > > > > > > > > > > I have implemented the 300 Redirected-Signal in my DOTS code. > > > > > > This then raises some questions about usability. > > > > > > > > > > > > Usability #1 > > > > > > > > > > > > Architecture 3.2.2 Redirected Signalling > > > > > > > > > > > > 4. Having redirected the DOTS client, DOTS server A ceases > > sending > > > > > > server signals. The DOTS client likewise stops sending = client > > > > > > signals to DOTS server A. DOTS session 1 is terminated. > > > > > > > > > > > > Clearly indicates that the original session (Client to Server > > > > > > A) is no more once redirected and only Client to Server B is in= use. > > > > > > > > > > > > How is the traffic redirected back to Server A once > > > > > > maintenance / overloading etc. has finished? My assumption is > > > > > > that Server B sends a redirect to go back to Server A as > > > > > > Server A has no way to say over a now non-existent session to s= ay > "come back". > > > > > > > > > > [Med] That's one possibility. This one does not require any > > > > > update to the > > > > signal- > > > > > channel specification. > > > > > > > > > > Another approach would be to not require any redirect signal > > > > > from server > > > B. > > > > > The client will remove server B's records upon the expiry of the > > > > > TTL and > > > > will fall > > > > > back to the "base" DOTS servers configuration that was > > > > > provisioned to the > > > > client > > > > > using DHCP or whatever mechanism. > > > > > [Jon] OK. The TTL is defined at, associated with the IP > > > > > address level > > > > under alt- > > > > > server-record, not under > > > > > ietf-dots-signal-channel:redirected-signal. The ttl definition = is > > > > > ambiguous as to what it refers to and perhaps could be tightened > > > > > up in the language (I read it as being associated with "addr" in > > > > > the sense of a DNS > > > > TTL). > > > > > > > > > > > > > > > > > Do we need to keep the existing Client to Server A session > > > > > > warm (or perhaps to probe periodically) to see if Server A is > > > > > > capable of handling the Client again by a server response > > > > > > extension to the protocol (e.g. a 3.01) > > > > > > > > > > [Med] Redirect was initially introduced to manage a server > > > > > overload, so I > > > > don't > > > > > think it makes sense to probe or maintain a session with server A= . > > > > > [Jon] Agreed, but I needed to raise the question. > > > > > > > > > > > > > > > > > Should there be a retry period parameter added in to the 3.00 > > > > > > protocol (as I read it, ttl only refers to the IP address)? > > > > > > > > > > [Med] The client will automatically switch to Server A when all > > > > > alternate > > > > records > > > > > expire. > > > > > [Jon] OK - again the 4.6 text needs to get tightened up to > > > > > reflect this as > > > > the > > > > > intent. > > > > > > > > > > > > > > > > > > > > > > Usability #2 > > > > > > > > > > > > Server A says "Redirect to Server B" due to overloading. > > > > > > Server B accepts things for a while and then is > > > > > > instructed/decides to redirect traffic back to A. Server A is > > > > > > left still overload configured to redirect to B. How should > > > > > > the client handle this as there is no suitable > > > > > Server? > > > > > > > > > > [Med] This is a service configuration problem. We may ask: > > > > > * the client to log the error and notify the administrator. > > > > > * and/or stop the redirection after n cycles. > > > > > > > > > > Still, this does not solve the problem. > > > > > [Jon] Agreed there is a problem here > > > > > > > > > > > > > > > > > I agree that there needs to be co-ordination between Server A > > > > > > and Server B, but user error may creep in. > > > > > > > > > > > > Usability #3 > > > > > > > > > > > > Server A says "Redirect to Server B" as it going to be shut > > > > > > down because of maintenance. Server B accepts things for a > > > > > > while and then is instructed (in probable user error) to > > > > > > redirect traffic back to A (perhaps because it has hit an > > > > > > overload condition). How should the client > > > > > handle this? > > > > > > > > > > [Med] Isn't this a sub-case or #2? > > > > > [Jon] Yes, but I wanted to bring in Server A being alive and > > > > > able to > > > > respond > > > > > versus Server A down and not responding due to maintenance. > > > > > [Jon] With my better understanding of TTL we still have an issue > > > > > if the TTL expires and Server A is having an extended outage. > > > > > How do we recover from that? > > > > > ~jon > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > Jon > > > > > > > > > > > > _______________________________________________ > > > > > > Dots mailing list > > > > > > Dots@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > _______________________________________________ > > > > > Dots mailing list > > > > > Dots@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > _______________________________________________ > > > > > Dots mailing list > > > > > Dots@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Thu Apr 5 22:40:20 2018 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 5FDE512E890 for ; Thu, 5 Apr 2018 22:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65RcPjQdiN8g for ; Thu, 5 Apr 2018 22:40:16 -0700 (PDT) Received: from guri.nttv6.jp (guri.nttv6.jp [IPv6:2402:c800:ff06:136::140]) by ietfa.amsl.com (Postfix) with ESMTP id CA6A712E883 for ; Thu, 5 Apr 2018 22:40:15 -0700 (PDT) Received: from z.nttv6.jp (z.nttv6.jp [192.168.8.15]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id 6838625F68C; Fri, 6 Apr 2018 14:40:14 +0900 (JST) Received: from [IPv6:::1] (fujiko.nttv6.jp [115.69.228.141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 2EB677634FC; Fri, 6 Apr 2018 14:40:14 +0900 (JST) To: mohamed.boucadair@orange.com, "dots@ietf.org" References: <359EC4B99E040048A7131E0F4E113AFC014C36B932@marathon> <68904f77-3cef-4c77-4cfa-3aeaacf95133@nttv6.jp> <787AE7BB302AE849A7480A190F8B93302DEF7927@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7277ba5c-436b-9027-8be0-49c8a53dbde2@nttv6.jp> <787AE7BB302AE849A7480A190F8B93302DEF79C9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEF7B45@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: kaname nishizuka Message-ID: <69de4e41-1761-d02a-616d-85bc340601b4@nttv6.jp> Date: Fri, 6 Apr 2018 14:40:13 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DEF7B45@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Dots] WGLC on DOTS Signal Channel 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, 06 Apr 2018 05:40:19 -0000 Hi Med, Please see inline. thanks, Kaname On 2018/04/04 18:28, mohamed.boucadair@orange.com wrote: > Re-, > > Thank you for the comments. > > Please see inline. > > Cheers, > Med > >> -----Message d'origine----- >> De : kaname nishizuka [mailto:kaname@nttv6.jp] >> Envoyé : mercredi 4 avril 2018 10:20 >> À : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org >> Objet : Re: [Dots] WGLC on DOTS Signal Channel >> >> Hi Med, >> >> Thank you for the clarification and the proper reference. >> I can not assume that my DOTS client will do Out-of-Order Configuration >> Requests, but... I got understand that 'sid' is the solution to out of order >> configuration requests. >> >> 2 more questions: >> >> 1. GET with sid >> On the slide 12, it is written in the table that 'sid' URI Parameter MUST NOT >> exist in GET. > [Med] Actually, the GET in that slide refers to the case to discover configuration parameters when, for example, a client bootstraps. In such case, there is no 'sid' to play with. > >> However, In RFC7252: >> 5.8.1. GET >>  The GET method retrieves a representation for the information that >>  currently corresponds to the resource identified by the request URI. >> >> So, I think the resource made by PUT in the exact URI path may be retrieved >> by GET. > [Med] Agree. The signal channel specification does not change the RFC7252 behavior. > >> I and Jon got consensus that the expected response of GET with sid is a >> "Figure 18: GET Configuration Response Body" like response with current value >> of that sid at the interop testing. >> The current draft is not clear about this behavior. > [Med] As I mentioned above, we are not changing the 7252 behavior. I can add this NEW text if it helps: > > A DOTS client may issue a GET message with or without 'sid' parameter > to retrieve the configuration parameters. The response message body > is the same as the one depicted in Figure 18. > [kaname] Referring to Figure 18 was not precise, sorry. The GET with sid will include sid in response body according to YANG module(5.1, 5.2) So, this would be more precise. A DOTS client may issue a GET message with or without 'sid' parameter to retrieve the configuration parameters. The response message body follows the YANG module "ietf-dots-signal-channel" (Section 5.2). >> 2. how to get default values after several negotiations >> GET without sid returns the current values. >> The default values can be retrieved only just after bootsrapping or sending >> DELETE request. >> (a DOTS client MAY send a DELETE request to set the configuration parameters >> to default values.) >> I'd like to get the default values even after negotiations. Is there any way >> to get them? > [Med] Default values are known to DOTS agents by design. That is a DOTS agent assumes the following default values: > > The RECOMMENDED values of transmission parameter > values are ack-timeout (2 seconds), max-retransmit (3), ack-random- > factor (1.5). In addition to those parameters, the RECOMMENDED > specific DOTS transmission parameter values are 'heartbeat-interval' > (30 seconds) and 'missing-hb-allowed' (5). [Kaname] I thought each DOTS server could have its own default values because the default values by design is just a recommendation. > When DOTS agents negotiate a given parameter, the negotiated value is used to override the default one. Otherwise, the default value is used. > > A DOTS client maintains a state whether a value was negotiated. As such, a DOTS client does not need to discover default values. [Kaname] Yes, that's true. What I thought was, from operational perspective, an operator may want to know the default values of the DOTS server before deleting the negotiated values. But, I agree that is out of DOTS spec. > Did I missed something? >> thanks, >> Kaname >> >> >> >> On 2018/04/04 16:31, mohamed.boucadair@orange.com wrote: >>> Re-, >>> >>> Please see inline. >>> >>> Cheers, >>> Med >>> >>>> -----Message d'origine----- >>>> De : kaname nishizuka [mailto:kaname@nttv6.jp] >>>> Envoyé : mercredi 4 avril 2018 08:57 >>>> À : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org >>>> Objet : Re: [Dots] WGLC on DOTS Signal Channel >>>> >>>> Hi Med, >>>> >>>> >>>> On 2018/04/04 15:22, mohamed.boucadair@orange.com wrote: >>>>> Hi Kaname, >>>>> >>>>> Please see inline. >>>>> >>>>> Cheers, >>>>> Med >>>>> >>>>>> -----Message d'origine----- >>>>>> De : Dots [mailto:dots-bounces@ietf.org] De la part de kaname nishizuka >>>>>> Envoyé : mercredi 4 avril 2018 02:27 >>>>>> À : dots@ietf.org >>>>>> Objet : Re: [Dots] WGLC on DOTS Signal Channel >>>>>> >>>>>> Hi, >>>>>> >>>>>> I have one clarification questions about sid in signal channel session >>>>>> configuration. >>>>>> >>>>>> The draft says: >>>>>>  At least one of the attributes ’heartbeat-interval’, ’missing-hb >>>>>> allowed’, ’max-retransmit’, ’ack-timeout’, ’ack-random-factor’, and >>>>>>  ’trigger-mitigation’ MUST be present in the PUT request. >>>>>>  (snip) >>>>>>  The PUT request with a higher numeric ’sid’ value overrides the DOTS >>>>>>  signal channel session configuration data installed by a PUT request >>>>>>  with a lower numeric ’sid’ value. >>>>>> >>>>>> assuming these are default values of a DOTS server: >>>>>>  'heartbeat-interval'=30 >>>>>>  ’max-retransmit’=3 >>>>>> >>>>>> if these messages came to the DOTS server consecutively, >>>>>>  1. sid=123, "heartbeat-interval"=10 >>>>>>  2. sid=456, ’max-retransmit’=5 >>>>>> in the final state, the first change should be discarded?: >>>>>>  'heartbeat-interval'=30 >>>>>>  ’max-retransmit’=5 >>>>>> or accumulated?: >>>>>>  'heartbeat-interval'=10 >>>>>>  ’max-retransmit’=5 >>>>>> >>>>>> so, the question is: should they be overridden by default values even if >>>> it >>>>>> is not specified? >>>>> [Med] The behavior to follow is covered by this text: >>>>> >>>>> The PUT request with a higher numeric 'sid' value overrides the DOTS >>>>> signal channel session configuration data installed by a PUT request >>>>> with a lower numeric 'sid' value. To avoid maintaining a long list >>>>> of 'sid' requests from a DOTS client, the lower numeric 'sid' MUST >> be >>>>> automatically deleted and no longer available at the DOTS server. >>>>> >>>>> And >>>>> >>>>> The DOTS agents MUST use the negotiated >>>>> values for message transmission parameters and default values for >>>>> non-negotiated message transmission parameters. >>>> Thanks, so, in my example, final state is >>>>   'heartbeat-interval'=30 (reverted to default value) >>>>   ’max-retransmit’=5 >>>> and the lower numeric 'sid' no longer exist in the DOTS server, right? >>>> >>> [Med] Exactly. >>> >>>>>> I think the former is ideal behavior. >>>>>> However, if so, the DOTS server is only required to keep the latest >>>> resource >>>>>> of the highest sid, >>>>>> then there should be no difference between DELETE message with and >> without >>>>>> sid. >>>>>> >>>>> [Med] To delete a configuration, a client may send a DELETE with a valid >>>> 'sid' or a DELETE without supplying a 'sid'. >>>>> Both are considered as valid in Section 4.5.4. >>>>> >>>> both are OK and have the same effect on DOTS server, right? >>> [Med] Yes. >>> >>>> A DOTS server always keeps the latest sid only. >>> [Med] Not the "latest" received sid...but the request with the higher sid. >>> >>> A DOTS client always attempt >>>> to update it. >>>> So there is no reason to use PUT, GET, DELETE with sid. >>>> Why sid does exist is confusing me. >>> [Med] 'sid' is there to solve out of order configuration requests. The >> rationale is explained in slide 12 of >> https://datatracker.ietf.org/meeting/interim-2018-dots-01/materials/slides- >> interim-2018-dots-01-sessa-signal-channel-00.pdf >>>> I'm afraid it was discussed on the ML but I'd like to know the rational of >>>> existence of sid. >>>> ``` >>>>  sid: Session Identifier is an identifier for the DOTS signal channel >>>>  session configuration data represented as an integer. This >>>>  identifier MUST be generated by DOTS clients. ’sid’ values MUST >>>>  increase monotonically. >>>> ``` >>>> this is not convincing because always only one configuration is registered >> on >>>> DOTS server. >>>> it will completely work without sid. >>>> >>>> thanks, >>>> Kaname >>>> >>>> >>>>>> regards, >>>>>> Kaname >>>>>> >>>>>> >>>>>> On 2018/03/21 19:32, Roman Danyliw wrote: >>>>>>> Hello! >>>>>>> >>>>>>> Consistent with our discussion at the London meeting, we are starting a >>>>>> working group last call (WGLC) for the DOTS Signal Channel draft: >>>>>>> DOTS Signal Channel Specification >>>>>>> draft-ietf-dots-signal-channel-18 >>>>>>> https://tools.ietf.org/html/draft-ietf-dots-signal-channel-18 >>>>>>> >>>>>>> Please send comments to the DOTS mailing list -- feedback on remaining >>>>>> issues or needed changes; as well as endorsements that this draft is >>>> ready. >>>>>>> This WGLC will end on April 6, 2018. >>>>>>> >>>>>>> Thanks, >>>>>>> Roman >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Dots mailing list >>>>>>> Dots@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/dots >>>>>> _______________________________________________ >>>>>> Dots mailing list >>>>>> Dots@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dots >>>>> _______________________________________________ >>>>> Dots mailing list >>>>> Dots@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dots >>> _______________________________________________ >>> Dots mailing list >>> Dots@ietf.org >>> https://www.ietf.org/mailman/listinfo/dots > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Thu Apr 5 22:56:18 2018 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 5A1C012E894 for ; Thu, 5 Apr 2018 22:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21aEXBys0dLz for ; Thu, 5 Apr 2018 22:56:14 -0700 (PDT) Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D11612E883 for ; Thu, 5 Apr 2018 22:56:14 -0700 (PDT) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 5020C120A36; Fri, 6 Apr 2018 07:56:12 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.17]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 32C9B180078; Fri, 6 Apr 2018 07:56:12 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM24.corporate.adroot.infra.ftgroup ([fe80::a1e6:3e6a:1f68:5f7e%18]) with mapi id 14.03.0382.000; Fri, 6 Apr 2018 07:56:12 +0200 From: To: "Konda, Tirumaleswar Reddy" , "Jon Shallow" , "dots@ietf.org" Thread-Topic: [Dots] Signal Channel - 300 Redirected Signaling Thread-Index: AdPMGSyCaQQbv+vLSW+0gkDbU7HOEwAAo7xAAAH7T4AAARdqYAAhoxEAAAGQiwAAAKyNYAAF3e1QACUKCFAAAZEMQA== Date: Fri, 6 Apr 2018 05:56:11 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DEF912A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <014f01d3cc19$2e3880e0$8aa982a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7E7B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <019901d3cc23$a93ff8e0$fbbfeaa0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8524@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <004e01d3ccb4$d505e7f0$7f11b7d0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8758@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling 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, 06 Apr 2018 05:56:17 -0000 Hi Tiru, Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.c= om] > Envoy=E9=A0: vendredi 6 avril 2018 07:07 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org > Objet=A0: RE: [Dots] Signal Channel - 300 Redirected Signaling >=20 > Hi Med, >=20 > The proposed update restricts the client no to do a DNS lookup using the > alternate FQDN, further associating a TTL with the name complicates the > functionality on the DOTS client to re-establish (D)TLS session with the > primary DOTS server after the TTL expires. My suggestion is to let the D= OTS > client continue to use the alternate DOTS server till it gets re-directed= . [Med] This is possible with the current spec.=20 Triggers for redirect and for falling back to the nominal configuration are= deployment-specific. The current spec allows for almost all the cases disc= ussed so far: (1) Redirect for the request in progress: A server does so by returning TTL= =3D0. (2) The alternate server is not involved in fall back to the nominal server= : upon expiry of ttl of all alternate IP addresses, then fall back automati= cally to the nominal server.=20 (3) Redirect to an alternate server, which in turn will instruct the client= to redirect to the "base" configuration: a TTL is provided and the altern= ate server can reply with a redirect code any time before the expiry of the= TTL. A long TTL can be returned if the alternate server will be responsibl= e for coordinating fall back to the base server. =20 (4) Stop infinite redirects I > don't think the DOTS mitigation provider will know ahead-of-time the TTL > value after which the DOTS client should disconnect communicating with th= e > alternate DOTS server and re-establish > (D)TLS session with the primary DOTS server. [Med] It depends on the nature of the redirect: overload, planned maintenan= ce, etc. For planned maintenance, the TTL is known in general. =20 >=20 > Cheers, > -Tiru >=20 > > -----Original Message----- > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of > > mohamed.boucadair@orange.com > > Sent: Thursday, April 5, 2018 4:50 PM > > To: Konda, Tirumaleswar Reddy ; > > Jon Shallow ; dots@ietf.org > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > Tiru, > > > > I don't see the NEW text as a restriction but as a simplification of th= e > client's > > behavior. I don't want to over-specify the redirect behavior. > > > > Adding another yet layer of resolution will raise other issues such as = the > need to > > associate a TTL with the name itself. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: Konda, Tirumaleswar Reddy > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > Envoy=E9=A0: jeudi 5 avril 2018 12:06 > > > =C0=A0: Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet= =A0: RE: > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > -----Original Message----- > > > > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > Sent: Thursday, April 5, 2018 1:35 PM > > > > To: mohamed.boucadair@orange.com; Konda, Tirumaleswar Reddy > > > > ; dots@ietf.org > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > Hi Med, > > > > > > > > Thanks for this refresh to 4.6 Redirected Signaling > > > > > > > > Some comments > > > > > > > > #1 > > > > > > > > The DOTS server can return the error response code 3.00 in respo= nse > > > > to a PUT request from the DOTS client or convey the error respon= se > > > > code 3.00 in a unidirectional notification response from the DOT= S > > > > server. > > > > > > > > Why is this limited to a PUT request and/or unidirectional > > > > notification > > > response? > > > > - Surely, any response, unsolicited or otherwise can contain a 3.00 > > > > - If Observe is not in use, then any unsolicited notification > > > > response will potentially get rejected by the coap library layer, s= o > > > > a DOTS Server cannot > > > signal > > > > maintenance outage other than by closing the session. > > > > - I missed this the last review - sorry > > > > > > > > > > > #2 > > > > > > > > If the DOTS client has been redirected to a DOTS server to which= it > > > > has already sent the mitigation request within the last five (5) > > > > minutes, it MUST ignore the redirection and try to contact other > > > > DOTS > > > > > > > > s/ has already sent the mitigation request/ has already communicate= d > > > > with/ > > > > > > > > #3 > > > > > > > > A DOTS client MUST NOT use an alternate IP address to contact= its > > > > DOTS server upon expiry of the associated TTL. > > > > > > > > To remove ambiguity over the use of FQDN, this could read > > > > > > > > A DOTS client MUST NOT use an alternate IP address to contact= its > > > > DOTS server upon expiry of the associated TTL. Furthermore, = a > DOTS > > > > Client MUST NOT use the alt-server FQDN if all of the > > > > alt-server- > > > records > > > > have expired. > > > > > > > > Or alternatively > > > > > > > > alt-server: FQDN of an alternate DOTS server. > > > > > > > > This could read > > > > > > > > alt-server: FQDN of an alternate DOTS server. This FQDN is not > > > > to be > > > used for > > > > looking up IP addresses to use, but is there for the SNI extension > (7.1. > > > (D)TLS > > > > Protocol Profile) > > > > > > I don't think the above restriction is correct for the following reas= ons: > > > > > > 1) If the TTL value in the alt-server-record expires, DNS lookup can > > > be performed by the DOTS client using the alternate DOTS server FQDN. > > > 2) If the DNS server is reachable, the client may want to a DANE > > > lookup to get the IP addresses and certificate to validate the > > > alternate DOTS server certificate sent > > > in the DTLS handshake. > > > > > > -Tiru > > > > > > > > > > > > > > > Regards > > > > > > > > Jon > > > > -----Original Message----- > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > > > mohamed.boucadair@orange.com > > > > Sent: 05 April 2018 08:20 > > > > To: Konda, Tirumaleswar Reddy; Jon Shallow; dots@ietf.org > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > Hi Tiru, > > > > > > > > Works for me. > > > > > > > > I updated the draft with the text additions that were discussed in > > > > this thread. The changes can be found at: > > > > https://github.com/boucadair/draft-ietf-dots-signal- > > > channel/blob/master/draf > > > > t-ietf-dots-signal-channel.txt > > > > > > > > Cheers, > > > > Med > > > > > > > > > -----Message d'origine----- > > > > > De=A0: Konda, Tirumaleswar Reddy > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > Envoy=E9=A0: mercredi 4 avril 2018 17:40 =C0=A0: Jon Shallow; BOU= CADAIR > > > > > Mohamed IMT/OLN; dots@ietf.org Objet=A0: RE: > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > The TTL value returned under alt-server-record is equivalent to > > > > > the DNS TTL value. A DDoS mitigation provider with multiple DOTS > > > > > servers typically re-directs a DOTS client to a different DOTS > > > > > server only if the alternate DOTS server has the capacity to > > > > > handle the requests from the > > > > DOTS client. > > > > > > > > > > We can add the following lines to avoid loops : > > > > > > > > > > If the DOTS client has been redirected to a DOTS server to which > > > > > it has already sent the mitigation request within the last five > > > > > minutes, it MUST ignore the redirection and try reaching others > > > > > servers listed in the local configuration or discovered using > > > > > dynamic means such as DHCP or SRV procedures. > > > > > This prevents infinite ping-ponging between servers in case of > > > > > redirection loops. > > > > > > > > > > -Tiru > > > > > > > > > > > -----Original Message----- > > > > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon > > > > > > Shallow > > > > > > Sent: Wednesday, April 4, 2018 8:16 PM > > > > > > To: mohamed.boucadair@orange.com; dots@ietf.org > > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > Hi there, > > > > > > > > > > > > See inline [Jon] > > > > > > > > > > > > Regards > > > > > > > > > > > > Jon > > > > > > > > > > > > -----Original Message----- > > > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > > > > > mohamed.boucadair@orange.com > > > > > > Sent: 04 April 2018 15:07 > > > > > > To: Jon Shallow; dots@ietf.org > > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > Re-, > > > > > > > > > > > > Please see inline. > > > > > > > > > > > > Cheers, > > > > > > Med > > > > > > > > > > > > > -----Message d'origine----- > > > > > > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Jon > > > > > > > Shallow Envoy=E9=A0: mercredi 4 avril 2018 15:31 =C0=A0: dots= @ietf.org > Objet=A0: > > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > Hi there, > > > > > > > > > > > > > > I have implemented the 300 Redirected-Signal in my DOTS code. > > > > > > > This then raises some questions about usability. > > > > > > > > > > > > > > Usability #1 > > > > > > > > > > > > > > Architecture 3.2.2 Redirected Signalling > > > > > > > > > > > > > > 4. Having redirected the DOTS client, DOTS server A cease= s > > > sending > > > > > > > server signals. The DOTS client likewise stops sendin= g > client > > > > > > > signals to DOTS server A. DOTS session 1 is terminate= d. > > > > > > > > > > > > > > Clearly indicates that the original session (Client to Server > > > > > > > A) is no more once redirected and only Client to Server B is = in > use. > > > > > > > > > > > > > > How is the traffic redirected back to Server A once > > > > > > > maintenance / overloading etc. has finished? My assumption i= s > > > > > > > that Server B sends a redirect to go back to Server A as > > > > > > > Server A has no way to say over a now non-existent session to= say > > "come back". > > > > > > > > > > > > [Med] That's one possibility. This one does not require any > > > > > > update to the > > > > > signal- > > > > > > channel specification. > > > > > > > > > > > > Another approach would be to not require any redirect signal > > > > > > from server > > > > B. > > > > > > The client will remove server B's records upon the expiry of th= e > > > > > > TTL and > > > > > will fall > > > > > > back to the "base" DOTS servers configuration that was > > > > > > provisioned to the > > > > > client > > > > > > using DHCP or whatever mechanism. > > > > > > [Jon] OK. The TTL is defined at, associated with the IP > > > > > > address level > > > > > under alt- > > > > > > server-record, not under > > > > > > ietf-dots-signal-channel:redirected-signal. The ttl definitio= n is > > > > > > ambiguous as to what it refers to and perhaps could be tightene= d > > > > > > up in the language (I read it as being associated with "addr" i= n > > > > > > the sense of a DNS > > > > > TTL). > > > > > > > > > > > > > > > > > > > > Do we need to keep the existing Client to Server A session > > > > > > > warm (or perhaps to probe periodically) to see if Server A is > > > > > > > capable of handling the Client again by a server response > > > > > > > extension to the protocol (e.g. a 3.01) > > > > > > > > > > > > [Med] Redirect was initially introduced to manage a server > > > > > > overload, so I > > > > > don't > > > > > > think it makes sense to probe or maintain a session with server= A. > > > > > > [Jon] Agreed, but I needed to raise the question. > > > > > > > > > > > > > > > > > > > > Should there be a retry period parameter added in to the 3.00 > > > > > > > protocol (as I read it, ttl only refers to the IP address)? > > > > > > > > > > > > [Med] The client will automatically switch to Server A when all > > > > > > alternate > > > > > records > > > > > > expire. > > > > > > [Jon] OK - again the 4.6 text needs to get tightened up to > > > > > > reflect this as > > > > > the > > > > > > intent. > > > > > > > > > > > > > > > > > > > > > > > > > > Usability #2 > > > > > > > > > > > > > > Server A says "Redirect to Server B" due to overloading. > > > > > > > Server B accepts things for a while and then is > > > > > > > instructed/decides to redirect traffic back to A. Server A i= s > > > > > > > left still overload configured to redirect to B. How should > > > > > > > the client handle this as there is no suitable > > > > > > Server? > > > > > > > > > > > > [Med] This is a service configuration problem. We may ask: > > > > > > * the client to log the error and notify the administrator. > > > > > > * and/or stop the redirection after n cycles. > > > > > > > > > > > > Still, this does not solve the problem. > > > > > > [Jon] Agreed there is a problem here > > > > > > > > > > > > > > > > > > > > I agree that there needs to be co-ordination between Server A > > > > > > > and Server B, but user error may creep in. > > > > > > > > > > > > > > Usability #3 > > > > > > > > > > > > > > Server A says "Redirect to Server B" as it going to be shut > > > > > > > down because of maintenance. Server B accepts things for a > > > > > > > while and then is instructed (in probable user error) to > > > > > > > redirect traffic back to A (perhaps because it has hit an > > > > > > > overload condition). How should the client > > > > > > handle this? > > > > > > > > > > > > [Med] Isn't this a sub-case or #2? > > > > > > [Jon] Yes, but I wanted to bring in Server A being alive and > > > > > > able to > > > > > respond > > > > > > versus Server A down and not responding due to maintenance. > > > > > > [Jon] With my better understanding of TTL we still have an issu= e > > > > > > if the TTL expires and Server A is having an extended outage. > > > > > > How do we recover from that? > > > > > > ~jon > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Dots mailing list > > > > > > > Dots@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > _______________________________________________ > > > > > > Dots mailing list > > > > > > Dots@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > _______________________________________________ > > > > > > Dots mailing list > > > > > > Dots@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > _______________________________________________ > > > > Dots mailing list > > > > Dots@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots From nobody Fri Apr 6 00:23:02 2018 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 A96F2128961 for ; Fri, 6 Apr 2018 00:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ns3o4_nTdpl for ; Fri, 6 Apr 2018 00:22:59 -0700 (PDT) Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2964126CE8 for ; Fri, 6 Apr 2018 00:22:58 -0700 (PDT) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 64A3340464; Fri, 6 Apr 2018 09:22:57 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.31]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 40F921A007D; Fri, 6 Apr 2018 09:22:57 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1%19]) with mapi id 14.03.0382.000; Fri, 6 Apr 2018 09:22:56 +0200 From: To: kaname nishizuka , "dots@ietf.org" Thread-Topic: [Dots] WGLC on DOTS Signal Channel Thread-Index: AQHTzWm//vyUYLMSU02Uh6eqiJtZMaPzRQNQ Date: Fri, 6 Apr 2018 07:22:56 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DEF91CB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <359EC4B99E040048A7131E0F4E113AFC014C36B932@marathon> <68904f77-3cef-4c77-4cfa-3aeaacf95133@nttv6.jp> <787AE7BB302AE849A7480A190F8B93302DEF7927@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7277ba5c-436b-9027-8be0-49c8a53dbde2@nttv6.jp> <787AE7BB302AE849A7480A190F8B93302DEF79C9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEF7B45@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <69de4e41-1761-d02a-616d-85bc340601b4@nttv6.jp> In-Reply-To: <69de4e41-1761-d02a-616d-85bc340601b4@nttv6.jp> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] WGLC on DOTS Signal Channel 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, 06 Apr 2018 07:23:01 -0000 SGkgS2FuYW1lLCANCg0KUGxlYXNlIHNlZSBpbmxpbmUuIA0KDQpDaGVlcnMsDQpNZWQNCg0KPiAt LS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDoga2FuYW1lIG5pc2hpenVrYSBbbWFp bHRvOmthbmFtZUBudHR2Ni5qcF0NCj4gRW52b3nDqcKgOiB2ZW5kcmVkaSA2IGF2cmlsIDIwMTgg MDc6NDANCj4gw4DCoDogQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTjsgZG90c0BpZXRmLm9yZw0K PiBPYmpldMKgOiBSZTogW0RvdHNdIFdHTEMgb24gRE9UUyBTaWduYWwgQ2hhbm5lbA0KPiANCj4g SGkgTWVkLA0KPiANCj4gUGxlYXNlIHNlZSBpbmxpbmUuDQo+IA0KPiB0aGFua3MsDQo+IEthbmFt ZQ0KPiANCj4gT24gMjAxOC8wNC8wNCAxODoyOCwgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNv bSB3cm90ZToNCj4gPiBSZS0sDQo+ID4NCj4gPiBUaGFuayB5b3UgZm9yICB0aGUgY29tbWVudHMu DQo+ID4NCj4gPiBQbGVhc2Ugc2VlIGlubGluZS4NCj4gPg0KPiA+IENoZWVycywNCj4gPiBNZWQN Cj4gPg0KPiA+PiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gPj4gRGXCoDoga2FuYW1l IG5pc2hpenVrYSBbbWFpbHRvOmthbmFtZUBudHR2Ni5qcF0NCj4gPj4gRW52b3nDqcKgOiBtZXJj cmVkaSA0IGF2cmlsIDIwMTggMTA6MjANCj4gPj4gw4DCoDogQk9VQ0FEQUlSIE1vaGFtZWQgSU1U L09MTjsgZG90c0BpZXRmLm9yZw0KPiA+PiBPYmpldMKgOiBSZTogW0RvdHNdIFdHTEMgb24gRE9U UyBTaWduYWwgQ2hhbm5lbA0KPiA+Pg0KPiA+PiBIaSBNZWQsDQo+ID4+DQo+ID4+IFRoYW5rIHlv dSBmb3IgdGhlIGNsYXJpZmljYXRpb24gYW5kIHRoZSBwcm9wZXIgcmVmZXJlbmNlLg0KPiA+PiBJ IGNhbiBub3QgYXNzdW1lIHRoYXQgbXkgRE9UUyBjbGllbnQgd2lsbCBkbyBPdXQtb2YtT3JkZXIg Q29uZmlndXJhdGlvbg0KPiA+PiBSZXF1ZXN0cywgYnV0Li4uIEkgZ290IHVuZGVyc3RhbmQgdGhh dCAnc2lkJyBpcyB0aGUgc29sdXRpb24gdG8gb3V0IG9mDQo+IG9yZGVyDQo+ID4+IGNvbmZpZ3Vy YXRpb24gcmVxdWVzdHMuDQo+ID4+DQo+ID4+IDIgbW9yZSBxdWVzdGlvbnM6DQo+ID4+DQo+ID4+ IDEuIEdFVCB3aXRoIHNpZA0KPiA+PiBPbiB0aGUgc2xpZGUgMTIsIGl0IGlzIHdyaXR0ZW4gaW4g dGhlIHRhYmxlIHRoYXQgJ3NpZCcgVVJJIFBhcmFtZXRlciBNVVNUDQo+IE5PVA0KPiA+PiBleGlz dCBpbiBHRVQuDQo+ID4gW01lZF0gQWN0dWFsbHksIHRoZSBHRVQgaW4gdGhhdCBzbGlkZSByZWZl cnMgdG8gdGhlIGNhc2UgdG8gZGlzY292ZXINCj4gY29uZmlndXJhdGlvbiBwYXJhbWV0ZXJzIHdo ZW4sIGZvciBleGFtcGxlLCBhIGNsaWVudCBib290c3RyYXBzLiBJbiBzdWNoDQo+IGNhc2UsIHRo ZXJlIGlzIG5vICdzaWQnIHRvIHBsYXkgd2l0aC4NCj4gPg0KPiA+PiBIb3dldmVyLCBJbiBSRkM3 MjUyOg0KPiA+PiA1LjguMS4gR0VUDQo+ID4+ICAgwqBUaGUgR0VUIG1ldGhvZCByZXRyaWV2ZXMg YSByZXByZXNlbnRhdGlvbiBmb3IgdGhlIGluZm9ybWF0aW9uIHRoYXQNCj4gPj4gICDCoGN1cnJl bnRseSBjb3JyZXNwb25kcyB0byB0aGUgcmVzb3VyY2UgaWRlbnRpZmllZCBieSB0aGUgcmVxdWVz dCBVUkkuDQo+ID4+DQo+ID4+IFNvLCBJIHRoaW5rIHRoZSByZXNvdXJjZSBtYWRlIGJ5IFBVVCBp biB0aGUgZXhhY3QgVVJJIHBhdGggbWF5IGJlDQo+IHJldHJpZXZlZA0KPiA+PiBieSBHRVQuDQo+ ID4gW01lZF0gQWdyZWUuIFRoZSBzaWduYWwgY2hhbm5lbCBzcGVjaWZpY2F0aW9uIGRvZXMgbm90 IGNoYW5nZSB0aGUgUkZDNzI1Mg0KPiBiZWhhdmlvci4NCj4gPg0KPiA+PiBJIGFuZCBKb24gZ290 IGNvbnNlbnN1cyB0aGF0IHRoZSBleHBlY3RlZCByZXNwb25zZSBvZiBHRVQgd2l0aCBzaWQgaXMg YQ0KPiA+PiAiRmlndXJlIDE4OiBHRVQgQ29uZmlndXJhdGlvbiBSZXNwb25zZSBCb2R5IiBsaWtl IHJlc3BvbnNlIHdpdGggY3VycmVudA0KPiB2YWx1ZQ0KPiA+PiBvZiB0aGF0IHNpZCBhdCB0aGUg aW50ZXJvcCB0ZXN0aW5nLg0KPiA+PiBUaGUgY3VycmVudCBkcmFmdCBpcyBub3QgY2xlYXIgYWJv dXQgdGhpcyBiZWhhdmlvci4NCj4gPiBbTWVkXSBBcyBJIG1lbnRpb25lZCBhYm92ZSwgd2UgYXJl IG5vdCBjaGFuZ2luZyB0aGUgNzI1MiBiZWhhdmlvci4gSSBjYW4NCj4gYWRkIHRoaXMgTkVXIHRl eHQgaWYgaXQgaGVscHM6DQo+ID4NCj4gPiAgICAgQSBET1RTIGNsaWVudCBtYXkgaXNzdWUgYSBH RVQgbWVzc2FnZSB3aXRoIG9yIHdpdGhvdXQgJ3NpZCcgcGFyYW1ldGVyDQo+ID4gICAgIHRvIHJl dHJpZXZlIHRoZSBjb25maWd1cmF0aW9uIHBhcmFtZXRlcnMuICBUaGUgcmVzcG9uc2UgbWVzc2Fn ZSBib2R5DQo+ID4gICAgIGlzIHRoZSBzYW1lIGFzIHRoZSBvbmUgZGVwaWN0ZWQgaW4gRmlndXJl IDE4Lg0KPiA+DQo+IFtrYW5hbWVdDQo+IFJlZmVycmluZyB0byBGaWd1cmUgMTggd2FzIG5vdCBw cmVjaXNlLCBzb3JyeS4NCj4gVGhlIEdFVCB3aXRoIHNpZCB3aWxsIGluY2x1ZGUgc2lkIGluIHJl c3BvbnNlIGJvZHkgYWNjb3JkaW5nIHRvIFlBTkcNCj4gbW9kdWxlKDUuMSwgNS4yKQ0KPiANCj4g U28sIHRoaXMgd291bGQgYmUgbW9yZSBwcmVjaXNlLg0KPiANCj4gICAgIEEgRE9UUyBjbGllbnQg bWF5IGlzc3VlIGEgR0VUIG1lc3NhZ2Ugd2l0aCBvciB3aXRob3V0ICdzaWQnIHBhcmFtZXRlcg0K PiAgICAgdG8gcmV0cmlldmUgdGhlIGNvbmZpZ3VyYXRpb24gcGFyYW1ldGVycy4gIFRoZSByZXNw b25zZSBtZXNzYWdlIGJvZHkNCj4gICAgIGZvbGxvd3MgdGhlIFlBTkcgbW9kdWxlICJpZXRmLWRv dHMtc2lnbmFsLWNoYW5uZWwiIChTZWN0aW9uIDUuMikuDQo+IA0KDQpbTWVkXSBJIHN1Z2dlc3Qg dG8gZGVsZXRlICJvciB3aXRob3V0IiBiZWNhdXNlIHRoaXMgaXMgYWxyZWFkeSBkaXNjdXNzZWQg aW4gNC41LjEuDQoNCiJBIERPVFMgY2xpZW50IG1heSBpc3N1ZSBhIEdFVCBtZXNzYWdlIHdpdGgg J3NpZCcgcGFyYW1ldGVyIHRvIHJldHJpZXZlIHRoZSBjb25maWd1cmF0aW9uIHBhcmFtZXRlcnMu IiAgDQoNCklmIHdlIGFyZSBzaWxlbnQgYWJvdXQgdGhlIHJlc3BvbnNlLCB0aGlzIG1lYW5zIHRo YXQgdGhlIGNsaWVudCBzaG91bGQgYWNjZXB0IGJvdGggcmVzcG9uc2VzIHdpdGggb3Igd2l0aG91 dCAnc2lkJyBpbiB0aGUgYm9keS4gDQoNCkRvIHlvdSB3YW50IHRoZSB0ZXh0IHRvIGJlIG1vcmUg c3BlY2lmaWMsIGUuZy46DQooMSkgYWx3YXlzIHJldHVybiBzaWQgaW4gdGhlIHJlc3BvbnNlPyBJ ZiBzbywgZG9lcyB0aGUgY2xpZW50IHVzZXMgdGhhdCBpbmZvcm1hdGlvbiBmb3Igc29tZSBwcm9j ZXNzaW5nPw0KKDIpIGZvcmJpZCB0byByZXR1cm4gdGhlIHNpZD8gVGhlIGNsaWVudCB3aWxsIGFz c3VtZSB0aGF0IHRoZSByZXNwb25zZSBtYXRjaGVzIHRoZSBzaWQgaW5jbHVkZWQgaW4gdGhlIHJl cXVlc3QuDQooMykgYWxsb3cgZm9yIGJvdGggY2FzZXMuIA0KDQo+IA0KPiA+PiAyLiBob3cgdG8g Z2V0IGRlZmF1bHQgdmFsdWVzIGFmdGVyIHNldmVyYWwgbmVnb3RpYXRpb25zDQo+ID4+IEdFVCB3 aXRob3V0IHNpZCByZXR1cm5zIHRoZSBjdXJyZW50IHZhbHVlcy4NCj4gPj4gVGhlIGRlZmF1bHQg dmFsdWVzIGNhbiBiZSByZXRyaWV2ZWQgb25seSBqdXN0IGFmdGVyIGJvb3RzcmFwcGluZyBvcg0K PiBzZW5kaW5nDQo+ID4+IERFTEVURSByZXF1ZXN0Lg0KPiA+PiAoYSBET1RTIGNsaWVudCBNQVkg c2VuZCBhIERFTEVURSByZXF1ZXN0IHRvIHNldCB0aGUgY29uZmlndXJhdGlvbg0KPiBwYXJhbWV0 ZXJzDQo+ID4+IHRvIGRlZmF1bHQgdmFsdWVzLikNCj4gPj4gSSdkIGxpa2UgdG8gZ2V0IHRoZSBk ZWZhdWx0IHZhbHVlcyBldmVuIGFmdGVyIG5lZ290aWF0aW9ucy4gSXMgdGhlcmUgYW55DQo+IHdh eQ0KPiA+PiB0byBnZXQgdGhlbT8NCj4gPiBbTWVkXSBEZWZhdWx0IHZhbHVlcyBhcmUga25vd24g dG8gRE9UUyBhZ2VudHMgYnkgZGVzaWduLiBUaGF0IGlzIGEgRE9UUw0KPiBhZ2VudCBhc3N1bWVz IHRoZSBmb2xsb3dpbmcgZGVmYXVsdCB2YWx1ZXM6DQo+ID4NCj4gPiBUaGUgUkVDT01NRU5ERUQg dmFsdWVzIG9mIHRyYW5zbWlzc2lvbiBwYXJhbWV0ZXINCj4gPiAgICAgdmFsdWVzIGFyZSBhY2st dGltZW91dCAoMiBzZWNvbmRzKSwgbWF4LXJldHJhbnNtaXQgKDMpLCBhY2stcmFuZG9tLQ0KPiA+ ICAgICBmYWN0b3IgKDEuNSkuICBJbiBhZGRpdGlvbiB0byB0aG9zZSBwYXJhbWV0ZXJzLCB0aGUg UkVDT01NRU5ERUQNCj4gPiAgICAgc3BlY2lmaWMgRE9UUyB0cmFuc21pc3Npb24gcGFyYW1ldGVy IHZhbHVlcyBhcmUgJ2hlYXJ0YmVhdC1pbnRlcnZhbCcNCj4gPiAgICAgKDMwIHNlY29uZHMpIGFu ZCAnbWlzc2luZy1oYi1hbGxvd2VkJyAoNSkuDQo+IA0KPiBbS2FuYW1lXQ0KPiBJIHRob3VnaHQg ZWFjaCBET1RTIHNlcnZlciBjb3VsZCBoYXZlIGl0cyBvd24gZGVmYXVsdCB2YWx1ZXMgYmVjYXVz ZSB0aGUNCj4gZGVmYXVsdCB2YWx1ZXMgYnkgZGVzaWduIGlzIGp1c3QgYSByZWNvbW1lbmRhdGlv bi4NCj4gDQoNCltNZWRdIE9uZSB3YXkgdG8gZGlzY292ZXIgd2hldGhlciBhIHNldmVyIHVzZXMg bm9uLXJlY29tbWVuZGVkIHZhbHVlcyBhcyBkZWZhdWx0IGlzIHRvIGlzc3VlIGEgR0VUIGF0IGJv b3RzdHJhcCBvciBhZnRlciBhIERFTFRFVEUuDQoNCj4gPiBXaGVuIERPVFMgYWdlbnRzIG5lZ290 aWF0ZSBhIGdpdmVuIHBhcmFtZXRlciwgdGhlIG5lZ290aWF0ZWQgdmFsdWUgaXMgdXNlZA0KPiB0 byBvdmVycmlkZSB0aGUgZGVmYXVsdCBvbmUuIE90aGVyd2lzZSwgdGhlIGRlZmF1bHQgdmFsdWUg aXMgdXNlZC4NCj4gPg0KPiA+IEEgRE9UUyBjbGllbnQgbWFpbnRhaW5zIGEgc3RhdGUgd2hldGhl ciBhIHZhbHVlIHdhcyBuZWdvdGlhdGVkLiBBcyBzdWNoLCBhDQo+IERPVFMgY2xpZW50IGRvZXMg bm90IG5lZWQgdG8gZGlzY292ZXIgZGVmYXVsdCB2YWx1ZXMuDQo+IFtLYW5hbWVdDQo+IFllcywg dGhhdCdzIHRydWUuDQo+IFdoYXQgSSB0aG91Z2h0IHdhcywgZnJvbSBvcGVyYXRpb25hbCBwZXJz cGVjdGl2ZSwgYW4gb3BlcmF0b3IgbWF5IHdhbnQgdG8NCj4ga25vdyB0aGUgZGVmYXVsdCB2YWx1 ZXMgb2YgdGhlIERPVFMgc2VydmVyIGJlZm9yZSBkZWxldGluZyB0aGUgbmVnb3RpYXRlZA0KPiB2 YWx1ZXMuDQo+IEJ1dCwgSSBhZ3JlZSB0aGF0IGlzIG91dCBvZiBET1RTIHNwZWMuDQo+IA0KPiA+ IERpZCBJIG1pc3NlZCBzb21ldGhpbmc/DQo+IA0KPiANCj4gPj4gdGhhbmtzLA0KPiA+PiBLYW5h bWUNCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4gT24gMjAxOC8wNC8wNCAxNjozMSwgbW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbSB3cm90ZToNCj4gPj4+IFJlLSwNCj4gPj4+DQo+ID4+PiBQbGVh c2Ugc2VlIGlubGluZS4NCj4gPj4+DQo+ID4+PiBDaGVlcnMsDQo+ID4+PiBNZWQNCj4gPj4+DQo+ ID4+Pj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ID4+Pj4gRGXCoDoga2FuYW1lIG5p c2hpenVrYSBbbWFpbHRvOmthbmFtZUBudHR2Ni5qcF0NCj4gPj4+PiBFbnZvecOpwqA6IG1lcmNy ZWRpIDQgYXZyaWwgMjAxOCAwODo1Nw0KPiA+Pj4+IMOAwqA6IEJPVUNBREFJUiBNb2hhbWVkIElN VC9PTE47IGRvdHNAaWV0Zi5vcmcNCj4gPj4+PiBPYmpldMKgOiBSZTogW0RvdHNdIFdHTEMgb24g RE9UUyBTaWduYWwgQ2hhbm5lbA0KPiA+Pj4+DQo+ID4+Pj4gSGkgTWVkLA0KPiA+Pj4+DQo+ID4+ Pj4NCj4gPj4+PiBPbiAyMDE4LzA0LzA0IDE1OjIyLCBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2Uu Y29tIHdyb3RlOg0KPiA+Pj4+PiBIaSBLYW5hbWUsDQo+ID4+Pj4+DQo+ID4+Pj4+IFBsZWFzZSBz ZWUgaW5saW5lLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBDaGVlcnMsDQo+ID4+Pj4+IE1lZA0KPiA+Pj4+ Pg0KPiA+Pj4+Pj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ID4+Pj4+PiBEZcKgOiBE b3RzIFttYWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIGthbmFtZQ0K PiBuaXNoaXp1a2ENCj4gPj4+Pj4+IEVudm95w6nCoDogbWVyY3JlZGkgNCBhdnJpbCAyMDE4IDAy OjI3DQo+ID4+Pj4+PiDDgMKgOiBkb3RzQGlldGYub3JnDQo+ID4+Pj4+PiBPYmpldMKgOiBSZTog W0RvdHNdIFdHTEMgb24gRE9UUyBTaWduYWwgQ2hhbm5lbA0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IEhp LA0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IEkgaGF2ZSBvbmUgY2xhcmlmaWNhdGlvbiBxdWVzdGlvbnMg YWJvdXQgc2lkIGluIHNpZ25hbCBjaGFubmVsIHNlc3Npb24NCj4gPj4+Pj4+IGNvbmZpZ3VyYXRp b24uDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gVGhlIGRyYWZ0IHNheXM6DQo+ID4+Pj4+PiAgICAgwqBB dCBsZWFzdCBvbmUgb2YgdGhlIGF0dHJpYnV0ZXMg4oCZaGVhcnRiZWF0LWludGVydmFs4oCZLCDi gJltaXNzaW5nLWhiDQo+ID4+Pj4+PiBhbGxvd2Vk4oCZLCDigJltYXgtcmV0cmFuc21pdOKAmSwg 4oCZYWNrLXRpbWVvdXTigJksIOKAmWFjay1yYW5kb20tZmFjdG9y4oCZLCBhbmQNCj4gPj4+Pj4+ ICAgICDCoOKAmXRyaWdnZXItbWl0aWdhdGlvbuKAmSBNVVNUIGJlIHByZXNlbnQgaW4gdGhlIFBV VCByZXF1ZXN0Lg0KPiA+Pj4+Pj4gICAgIMKgKHNuaXApDQo+ID4+Pj4+PiAgICAgwqBUaGUgUFVU IHJlcXVlc3Qgd2l0aCBhIGhpZ2hlciBudW1lcmljIOKAmXNpZOKAmSB2YWx1ZSBvdmVycmlkZXMg dGhlDQo+IERPVFMNCj4gPj4+Pj4+ICAgICDCoHNpZ25hbCBjaGFubmVsIHNlc3Npb24gY29uZmln dXJhdGlvbiBkYXRhIGluc3RhbGxlZCBieSBhIFBVVA0KPiByZXF1ZXN0DQo+ID4+Pj4+PiAgICAg wqB3aXRoIGEgbG93ZXIgbnVtZXJpYyDigJlzaWTigJkgdmFsdWUuDQo+ID4+Pj4+Pg0KPiA+Pj4+ Pj4gYXNzdW1pbmcgdGhlc2UgYXJlIGRlZmF1bHQgdmFsdWVzIG9mIGEgRE9UUyBzZXJ2ZXI6DQo+ ID4+Pj4+PiAgICAgwqAnaGVhcnRiZWF0LWludGVydmFsJz0zMA0KPiA+Pj4+Pj4gICAgIMKg4oCZ bWF4LXJldHJhbnNtaXTigJk9Mw0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IGlmIHRoZXNlIG1lc3NhZ2Vz IGNhbWUgdG8gdGhlIERPVFMgc2VydmVyIGNvbnNlY3V0aXZlbHksDQo+ID4+Pj4+PiAgICAgwqAx LiBzaWQ9MTIzLCAiaGVhcnRiZWF0LWludGVydmFsIj0xMA0KPiA+Pj4+Pj4gICAgIMKgMi4gc2lk PTQ1Niwg4oCZbWF4LXJldHJhbnNtaXTigJk9NQ0KPiA+Pj4+Pj4gaW4gdGhlIGZpbmFsIHN0YXRl LCB0aGUgZmlyc3QgY2hhbmdlIHNob3VsZCBiZSBkaXNjYXJkZWQ/Og0KPiA+Pj4+Pj4gICAgIMKg J2hlYXJ0YmVhdC1pbnRlcnZhbCc9MzANCj4gPj4+Pj4+ICAgICDCoOKAmW1heC1yZXRyYW5zbWl0 4oCZPTUNCj4gPj4+Pj4+IG9yIGFjY3VtdWxhdGVkPzoNCj4gPj4+Pj4+ICAgICDCoCdoZWFydGJl YXQtaW50ZXJ2YWwnPTEwDQo+ID4+Pj4+PiAgICAgwqDigJltYXgtcmV0cmFuc21pdOKAmT01DQo+ ID4+Pj4+Pg0KPiA+Pj4+Pj4gc28sIHRoZSBxdWVzdGlvbiBpczogc2hvdWxkIHRoZXkgYmUgb3Zl cnJpZGRlbiBieSBkZWZhdWx0IHZhbHVlcyBldmVuDQo+IGlmDQo+ID4+Pj4gaXQNCj4gPj4+Pj4+ IGlzIG5vdCBzcGVjaWZpZWQ/DQo+ID4+Pj4+IFtNZWRdIFRoZSBiZWhhdmlvciB0byBmb2xsb3cg aXMgY292ZXJlZCBieSB0aGlzIHRleHQ6DQo+ID4+Pj4+DQo+ID4+Pj4+ICAgICAgIFRoZSBQVVQg cmVxdWVzdCB3aXRoIGEgaGlnaGVyIG51bWVyaWMgJ3NpZCcgdmFsdWUgb3ZlcnJpZGVzIHRoZQ0K PiBET1RTDQo+ID4+Pj4+ICAgICAgIHNpZ25hbCBjaGFubmVsIHNlc3Npb24gY29uZmlndXJhdGlv biBkYXRhIGluc3RhbGxlZCBieSBhIFBVVA0KPiByZXF1ZXN0DQo+ID4+Pj4+ICAgICAgIHdpdGgg YSBsb3dlciBudW1lcmljICdzaWQnIHZhbHVlLiAgVG8gYXZvaWQgbWFpbnRhaW5pbmcgYSBsb25n DQo+IGxpc3QNCj4gPj4+Pj4gICAgICAgb2YgJ3NpZCcgcmVxdWVzdHMgZnJvbSBhIERPVFMgY2xp ZW50LCB0aGUgbG93ZXIgbnVtZXJpYyAnc2lkJw0KPiBNVVNUDQo+ID4+IGJlDQo+ID4+Pj4+ICAg ICAgIGF1dG9tYXRpY2FsbHkgZGVsZXRlZCBhbmQgbm8gbG9uZ2VyIGF2YWlsYWJsZSBhdCB0aGUg RE9UUyBzZXJ2ZXIuDQo+ID4+Pj4+DQo+ID4+Pj4+IEFuZA0KPiA+Pj4+Pg0KPiA+Pj4+PiAgICAg ICBUaGUgRE9UUyBhZ2VudHMgTVVTVCB1c2UgdGhlIG5lZ290aWF0ZWQNCj4gPj4+Pj4gICAgICAg dmFsdWVzIGZvciBtZXNzYWdlIHRyYW5zbWlzc2lvbiBwYXJhbWV0ZXJzIGFuZCBkZWZhdWx0IHZh bHVlcyBmb3INCj4gPj4+Pj4gICAgICAgbm9uLW5lZ290aWF0ZWQgbWVzc2FnZSB0cmFuc21pc3Np b24gcGFyYW1ldGVycy4NCj4gPj4+PiBUaGFua3MsIHNvLCBpbiBteSBleGFtcGxlLCBmaW5hbCBz dGF0ZSBpcw0KPiA+Pj4+ICAgIMKgICdoZWFydGJlYXQtaW50ZXJ2YWwnPTMwIChyZXZlcnRlZCB0 byBkZWZhdWx0IHZhbHVlKQ0KPiA+Pj4+ICAgIMKgIOKAmW1heC1yZXRyYW5zbWl04oCZPTUNCj4g Pj4+PiBhbmQgdGhlIGxvd2VyIG51bWVyaWMgJ3NpZCcgbm8gbG9uZ2VyIGV4aXN0IGluIHRoZSBE T1RTIHNlcnZlciwgcmlnaHQ/DQo+ID4+Pj4NCj4gPj4+IFtNZWRdIEV4YWN0bHkuDQo+ID4+Pg0K PiA+Pj4+Pj4gSSB0aGluayB0aGUgZm9ybWVyIGlzIGlkZWFsIGJlaGF2aW9yLg0KPiA+Pj4+Pj4g SG93ZXZlciwgaWYgc28sIHRoZSBET1RTIHNlcnZlciBpcyBvbmx5IHJlcXVpcmVkIHRvIGtlZXAg dGhlIGxhdGVzdA0KPiA+Pj4+IHJlc291cmNlDQo+ID4+Pj4+PiBvZiB0aGUgaGlnaGVzdCBzaWQs DQo+ID4+Pj4+PiB0aGVuIHRoZXJlIHNob3VsZCBiZSBubyBkaWZmZXJlbmNlIGJldHdlZW4gREVM RVRFIG1lc3NhZ2Ugd2l0aCBhbmQNCj4gPj4gd2l0aG91dA0KPiA+Pj4+Pj4gc2lkLg0KPiA+Pj4+ Pj4NCj4gPj4+Pj4gW01lZF0gVG8gZGVsZXRlIGEgY29uZmlndXJhdGlvbiwgYSBjbGllbnQgbWF5 IHNlbmQgYSBERUxFVEUgd2l0aCBhDQo+IHZhbGlkDQo+ID4+Pj4gJ3NpZCcgb3IgYSBERUxFVEUg d2l0aG91dCBzdXBwbHlpbmcgYSAnc2lkJy4NCj4gPj4+Pj4gQm90aCBhcmUgY29uc2lkZXJlZCBh cyB2YWxpZCBpbiBTZWN0aW9uIDQuNS40Lg0KPiA+Pj4+Pg0KPiA+Pj4+IGJvdGggYXJlIE9LIGFu ZCBoYXZlIHRoZSBzYW1lIGVmZmVjdCBvbiBET1RTIHNlcnZlciwgcmlnaHQ/DQo+ID4+PiBbTWVk XSBZZXMuDQo+ID4+Pg0KPiA+Pj4+IEEgRE9UUyBzZXJ2ZXIgYWx3YXlzIGtlZXBzIHRoZSBsYXRl c3Qgc2lkIG9ubHkuDQo+ID4+PiBbTWVkXSBOb3QgdGhlICJsYXRlc3QiIHJlY2VpdmVkIHNpZC4u LmJ1dCB0aGUgcmVxdWVzdCB3aXRoIHRoZSBoaWdoZXINCj4gc2lkLg0KPiA+Pj4NCj4gPj4+ICAg IEEgRE9UUyBjbGllbnQgYWx3YXlzIGF0dGVtcHQNCj4gPj4+PiB0byB1cGRhdGUgaXQuDQo+ID4+ Pj4gU28gdGhlcmUgaXMgbm8gcmVhc29uIHRvIHVzZSBQVVQsIEdFVCwgREVMRVRFIHdpdGggc2lk Lg0KPiA+Pj4+IFdoeSBzaWQgZG9lcyBleGlzdCBpcyBjb25mdXNpbmcgbWUuDQo+ID4+PiBbTWVk XSAnc2lkJyBpcyB0aGVyZSB0byBzb2x2ZSBvdXQgb2Ygb3JkZXIgY29uZmlndXJhdGlvbiByZXF1 ZXN0cy4gVGhlDQo+ID4+IHJhdGlvbmFsZSBpcyBleHBsYWluZWQgaW4gc2xpZGUgMTIgb2YNCj4g Pj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nL2ludGVyaW0tMjAxOC1kb3Rz LQ0KPiAwMS9tYXRlcmlhbHMvc2xpZGVzLQ0KPiA+PiBpbnRlcmltLTIwMTgtZG90cy0wMS1zZXNz YS1zaWduYWwtY2hhbm5lbC0wMC5wZGYNCj4gPj4+PiBJJ20gYWZyYWlkIGl0IHdhcyBkaXNjdXNz ZWQgb24gdGhlIE1MIGJ1dCBJJ2QgbGlrZSB0byBrbm93IHRoZSByYXRpb25hbA0KPiBvZg0KPiA+ Pj4+IGV4aXN0ZW5jZSBvZiBzaWQuDQo+ID4+Pj4gYGBgDQo+ID4+Pj4gICAgwqBzaWQ6IFNlc3Np b24gSWRlbnRpZmllciBpcyBhbiBpZGVudGlmaWVyIGZvciB0aGUgRE9UUyBzaWduYWwgY2hhbm5l bA0KPiA+Pj4+ICAgIMKgc2Vzc2lvbiBjb25maWd1cmF0aW9uIGRhdGEgcmVwcmVzZW50ZWQgYXMg YW4gaW50ZWdlci4gVGhpcw0KPiA+Pj4+ICAgIMKgaWRlbnRpZmllciBNVVNUIGJlIGdlbmVyYXRl ZCBieSBET1RTIGNsaWVudHMuIOKAmXNpZOKAmSB2YWx1ZXMgTVVTVA0KPiA+Pj4+ICAgIMKgaW5j cmVhc2UgbW9ub3RvbmljYWxseS4NCj4gPj4+PiBgYGANCj4gPj4+PiB0aGlzIGlzIG5vdCBjb252 aW5jaW5nIGJlY2F1c2UgYWx3YXlzIG9ubHkgb25lIGNvbmZpZ3VyYXRpb24gaXMNCj4gcmVnaXN0 ZXJlZA0KPiA+PiBvbg0KPiA+Pj4+IERPVFMgc2VydmVyLg0KPiA+Pj4+IGl0IHdpbGwgY29tcGxl dGVseSB3b3JrIHdpdGhvdXQgc2lkLg0KPiA+Pj4+DQo+ID4+Pj4gdGhhbmtzLA0KPiA+Pj4+IEth bmFtZQ0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+Pj4+IHJlZ2FyZHMsDQo+ID4+Pj4+PiBLYW5hbWUN Cj4gPj4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gT24gMjAxOC8wMy8yMSAxOTozMiwgUm9tYW4g RGFueWxpdyB3cm90ZToNCj4gPj4+Pj4+PiBIZWxsbyENCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IENv bnNpc3RlbnQgd2l0aCBvdXIgZGlzY3Vzc2lvbiBhdCB0aGUgTG9uZG9uIG1lZXRpbmcsIHdlIGFy ZSBzdGFydGluZw0KPiBhDQo+ID4+Pj4+PiB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCAoV0dMQykg Zm9yIHRoZSBET1RTIFNpZ25hbCBDaGFubmVsIGRyYWZ0Og0KPiA+Pj4+Pj4+IERPVFMgU2lnbmFs IENoYW5uZWwgU3BlY2lmaWNhdGlvbg0KPiA+Pj4+Pj4+IGRyYWZ0LWlldGYtZG90cy1zaWduYWwt Y2hhbm5lbC0xOA0KPiA+Pj4+Pj4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLWRvdHMtc2lnbmFsLWNoYW5uZWwtMTgNCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IFBsZWFzZSBz ZW5kIGNvbW1lbnRzIHRvIHRoZSBET1RTIG1haWxpbmcgbGlzdCAtLSBmZWVkYmFjayBvbg0KPiBy ZW1haW5pbmcNCj4gPj4+Pj4+IGlzc3VlcyBvciBuZWVkZWQgY2hhbmdlczsgYXMgd2VsbCBhcyBl bmRvcnNlbWVudHMgdGhhdCB0aGlzIGRyYWZ0IGlzDQo+ID4+Pj4gcmVhZHkuDQo+ID4+Pj4+Pj4g VGhpcyBXR0xDIHdpbGwgZW5kIG9uIEFwcmlsIDYsIDIwMTguDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+ PiBUaGFua3MsDQo+ID4+Pj4+Pj4gUm9tYW4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+Pj4+Pj4gRG90cyBt YWlsaW5nIGxpc3QNCj4gPj4+Pj4+PiBEb3RzQGlldGYub3JnDQo+ID4+Pj4+Pj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3RzDQo+ID4+Pj4+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4+Pj4gRG90cyBtYWlsaW5n IGxpc3QNCj4gPj4+Pj4+IERvdHNAaWV0Zi5vcmcNCj4gPj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vZG90cw0KPiA+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4+PiBEb3RzIG1haWxpbmcgbGlzdA0KPiA+ Pj4+PiBEb3RzQGlldGYub3JnDQo+ID4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vZG90cw0KPiA+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gPj4+IERvdHMgbWFpbGluZyBsaXN0DQo+ID4+PiBEb3RzQGlldGYub3Jn DQo+ID4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHMNCj4gPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IERvdHMg bWFpbGluZyBsaXN0DQo+ID4gRG90c0BpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vZG90cw0KDQo= From nobody Fri Apr 6 02:59:12 2018 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 5C1911241F3 for ; Fri, 6 Apr 2018 02:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 JYY4kNON7iyx for ; Fri, 6 Apr 2018 02:59:07 -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 60F30120725 for ; Fri, 6 Apr 2018 02:59: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=1523008746; 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: dlp-product:dlp-version:dlp-reaction: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-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-Network-Message-Id: 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=P /uxESJK6eUMnKIjKKr8d0hjlGh1uwwqYbk7yVHRHl 0=; b=E5MzA8h6X9m/Q15b+vDNVy69ug/AezXWkudBf+v1wW20 8G7X/zeL9UZ9QNKh6jga6P27Ab2PasXTWmW0nlthKqFxhMhjpA xit5w7Mn+XekRqDEzYur174URxT0BUMDpefoiwqh0nOnlY/KJq uiDxABgZTPr65wALtJxpQyKjHEQ= Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 3b64_3c19_889d7d6b_3b78_4007_add2_5c466d15d37c; Fri, 06 Apr 2018 04:59:05 -0500 Received: from DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 6 Apr 2018 03:58:56 -0600 Received: from DNVEXUSR1N10.corpzone.internalzone.com (10.44.48.83) by DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 6 Apr 2018 03:58:55 -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; Fri, 6 Apr 2018 03:58:55 -0600 Received: from NAM01-SN1-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.1347.2; Fri, 6 Apr 2018 03:58:53 -0600 Received: from BN6PR16MB1425.namprd16.prod.outlook.com (10.172.207.19) by BN6PR16MB1586.namprd16.prod.outlook.com (10.172.208.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.653.12; Fri, 6 Apr 2018 09:58:52 +0000 Received: from BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d]) by BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d%2]) with mapi id 15.20.0653.012; Fri, 6 Apr 2018 09:58:52 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Signal Channel - 300 Redirected Signaling Thread-Index: AdPMGSyCaQQbv+vLSW+0gkDbU7HOEwAAo7xAAAH7T4AAARdqYAAhoxEAAAGQiwAAAKyNYAAF3e1QACUKCFAAAZEMQAAIeXTg Date: Fri, 6 Apr 2018 09:58:52 +0000 Message-ID: References: <014f01d3cc19$2e3880e0$8aa982a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7E7B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <019901d3cc23$a93ff8e0$fbbfeaa0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8524@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <004e01d3ccb4$d505e7f0$7f11b7d0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8758@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEF912A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DEF912A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR16MB1586; 7:iuHEf3HTUuXjduhHBajmj/IGRiiqyN7lpcCdMSpJ+CwjQWxjfdZRTN9Vx1bXy1Gw5J+YRwmolFuF6w/Ucus9dd+++87cerfrBVw5EEtkBEaxxwwoPpGqTYJ2FdLO5U3NkhsEl/7g0zppkOOkvlOyD6nbtzC7jLl9l6DhXm1k7Py5+Mb9iYv2OC/+8NKeF9rnGdQLhVoQvZOqs3B0wIWvFFaG3CE06DDSHo2n7mGalm6XCRJ58CBiT+tm+kAJ4jAU x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 0d071bf2-cccf-4298-e233-08d59ba500a4 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BN6PR16MB1586; x-ms-traffictypediagnostic: BN6PR16MB1586: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(166708455590820)(18271650672692)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231221)(944501327)(52105095)(93006095)(93001095)(10201501046)(3002001)(6041310)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123560045)(6072148)(201708071742011); SRVR:BN6PR16MB1586; BCL:0; PCL:0; RULEID:; SRVR:BN6PR16MB1586; x-forefront-prvs: 0634F37BFF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(396003)(39380400002)(366004)(346002)(39860400002)(32952001)(189003)(199004)(13464003)(57704003)(55784002)(74316002)(3660700001)(446003)(80792005)(14454004)(53936002)(476003)(11346002)(53946003)(9686003)(486006)(97736004)(3280700002)(6306002)(2906002)(26005)(81156014)(8676002)(186003)(68736007)(2900100001)(5660300001)(229853002)(7736002)(55016002)(81166006)(966005)(305945005)(8936002)(6116002)(99286004)(478600001)(59450400001)(3846002)(25786009)(106356001)(105586002)(93886005)(7696005)(316002)(76176011)(72206003)(2501003)(102836004)(5250100002)(86362001)(6246003)(6506007)(110136005)(6436002)(53546011)(33656002)(66066001)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR16MB1586; H:BN6PR16MB1425.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: gXFEfH59PQLsGV2NWEfARyHgrvMu6/vHzWFoRzX5xc1XJMKZR09Mi5SxMtAwRn1KJTksdUGyW6dgoF+fwQsZJ1b7U95xsBXJn51iQ5jsgEDKmgA28DkWxiKcXGRMiRvnZhmZmVpQWGeYl8ENSXenlFf7ZJJdSh0/Iz1thr76Q8Kkxh07GeEPYPjk6hO5L58lB7rE6xAVhr8JZYODt6MVQz/t5cRnDMqOoxj78jf7V6u8NPljrTyXZ0QriUH7fYE0oN5K658RIVNJnYsJCzzkxTKIjo9xzy9fxG5jFpi9WW5BHrTVfXunQz0Lg6eywijArvqo8pfFWR8sUOxQ13zuyLeTACnFQH7S1x1lxLcIyPeGjlXWolK/VbQO8Wjugj8Qch9ZztgbzbtKFXzSYCpcnYTjTDx7U82SRpUH6I1LgRU= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 0d071bf2-cccf-4298-e233-08d59ba500a4 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2018 09:58:52.3666 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR16MB1586 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 <6258> : inlines <6551> : streams <1783353> : uri <2621365> Archived-At: Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling 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, 06 Apr 2018 09:59:10 -0000 > -----Original Message----- > From: mohamed.boucadair@orange.com > [mailto:mohamed.boucadair@orange.com] > Sent: Friday, April 6, 2018 11:26 AM > To: Konda, Tirumaleswar Reddy ; > Jon Shallow ; dots@ietf.org > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling >=20 > Hi Tiru, >=20 > Please see inline. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Konda, Tirumaleswar Reddy > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > Envoy=E9=A0: vendredi 6 avril 2018 07:07 > > =C0=A0: BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet=A0:= RE: > > [Dots] Signal Channel - 300 Redirected Signaling > > > > Hi Med, > > > > The proposed update restricts the client no to do a DNS lookup using > > the alternate FQDN, further associating a TTL with the name > > complicates the functionality on the DOTS client to re-establish > > (D)TLS session with the primary DOTS server after the TTL expires. My > > suggestion is to let the DOTS client continue to use the alternate DOTS= server > till it gets re-directed. >=20 > [Med] This is possible with the current spec. >=20 > Triggers for redirect and for falling back to the nominal configuration a= re > deployment-specific. The current spec allows for almost all the cases dis= cussed > so far: >=20 > (1) Redirect for the request in progress: A server does so by returning T= TL=3D0. > (2) The alternate server is not involved in fall back to the nominal serv= er: upon > expiry of ttl of all alternate IP addresses, then fall back automatically= to the > nominal server. > (3) Redirect to an alternate server, which in turn will instruct the clie= nt to > redirect to the "base" configuration: a TTL is provided and the alternat= e server > can reply with a redirect code any time before the expiry of the TTL. A l= ong TTL > can be returned if the alternate server will be responsible for coordinat= ing fall > back to the base server. > (4) Stop infinite redirects Yes, but (1) and (2) complicate the functionality of the DOTS client. The = only reason for adding alt-server-record in the response is DNS server may = not be reachable by the DOTS server=20 because of a DDoS attack. >=20 >=20 > I > > don't think the DOTS mitigation provider will know ahead-of-time the > > TTL value after which the DOTS client should disconnect communicating > > with the alternate DOTS server and re-establish (D)TLS session with > > the primary DOTS server. >=20 > [Med] It depends on the nature of the redirect: overload, planned mainten= ance, > etc. For planned maintenance, the TTL is known in general. It's the primary DOTS server responsibility to point the DOTS client to an = optimal alternate server, where the client can continue to send migration r= equests without a frequent ping-pong between servers.=20 I have seen TURN servers being deployed for several years with re-direction= but without the need for TTL (see ALTERNATE-SERVER in https://tools.ietf.o= rg/html/draft-ietf-tram-turnbis-11)=20 -Tiru >=20 > > > > Cheers, > > -Tiru > > > > > -----Original Message----- > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of > > > mohamed.boucadair@orange.com > > > Sent: Thursday, April 5, 2018 4:50 PM > > > To: Konda, Tirumaleswar Reddy ; > > > Jon Shallow ; dots@ietf.org > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > Tiru, > > > > > > I don't see the NEW text as a restriction but as a simplification of > > > the > > client's > > > behavior. I don't want to over-specify the redirect behavior. > > > > > > Adding another yet layer of resolution will raise other issues such > > > as the > > need to > > > associate a TTL with the name itself. > > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De=A0: Konda, Tirumaleswar Reddy > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > Envoy=E9=A0: jeudi 5 avril 2018 12:06 > > > > =C0=A0: Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet= =A0: RE: > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > -----Original Message----- > > > > > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > > Sent: Thursday, April 5, 2018 1:35 PM > > > > > To: mohamed.boucadair@orange.com; Konda, Tirumaleswar Reddy > > > > > ; dots@ietf.org > > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > Hi Med, > > > > > > > > > > Thanks for this refresh to 4.6 Redirected Signaling > > > > > > > > > > Some comments > > > > > > > > > > #1 > > > > > > > > > > The DOTS server can return the error response code 3.00 in res= ponse > > > > > to a PUT request from the DOTS client or convey the error resp= onse > > > > > code 3.00 in a unidirectional notification response from the D= OTS > > > > > server. > > > > > > > > > > Why is this limited to a PUT request and/or unidirectional > > > > > notification > > > > response? > > > > > - Surely, any response, unsolicited or otherwise can contain a > > > > > 3.00 > > > > > - If Observe is not in use, then any unsolicited notification > > > > > response will potentially get rejected by the coap library > > > > > layer, so a DOTS Server cannot > > > > signal > > > > > maintenance outage other than by closing the session. > > > > > - I missed this the last review - sorry > > > > > > > > > > > > > > #2 > > > > > > > > > > If the DOTS client has been redirected to a DOTS server to whi= ch it > > > > > has already sent the mitigation request within the last five (= 5) > > > > > minutes, it MUST ignore the redirection and try to contact > > > > > other DOTS > > > > > > > > > > s/ has already sent the mitigation request/ has already > > > > > communicated with/ > > > > > > > > > > #3 > > > > > > > > > > A DOTS client MUST NOT use an alternate IP address to conta= ct its > > > > > DOTS server upon expiry of the associated TTL. > > > > > > > > > > To remove ambiguity over the use of FQDN, this could read > > > > > > > > > > A DOTS client MUST NOT use an alternate IP address to conta= ct its > > > > > DOTS server upon expiry of the associated TTL. > > > > > Furthermore, a > > DOTS > > > > > Client MUST NOT use the alt-server FQDN if all of the > > > > > alt-server- > > > > records > > > > > have expired. > > > > > > > > > > Or alternatively > > > > > > > > > > alt-server: FQDN of an alternate DOTS server. > > > > > > > > > > This could read > > > > > > > > > > alt-server: FQDN of an alternate DOTS server. This FQDN is > > > > > not to be > > > > used for > > > > > looking up IP addresses to use, but is there for the SNI > > > > > extension > > (7.1. > > > > (D)TLS > > > > > Protocol Profile) > > > > > > > > I don't think the above restriction is correct for the following re= asons: > > > > > > > > 1) If the TTL value in the alt-server-record expires, DNS lookup > > > > can be performed by the DOTS client using the alternate DOTS server= FQDN. > > > > 2) If the DNS server is reachable, the client may want to a DANE > > > > lookup to get the IP addresses and certificate to validate the > > > > alternate DOTS server certificate sent > > > > in the DTLS handshake. > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > Jon > > > > > -----Original Message----- > > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > > > > mohamed.boucadair@orange.com > > > > > Sent: 05 April 2018 08:20 > > > > > To: Konda, Tirumaleswar Reddy; Jon Shallow; dots@ietf.org > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > Hi Tiru, > > > > > > > > > > Works for me. > > > > > > > > > > I updated the draft with the text additions that were discussed > > > > > in this thread. The changes can be found at: > > > > > https://github.com/boucadair/draft-ietf-dots-signal- > > > > channel/blob/master/draf > > > > > t-ietf-dots-signal-channel.txt > > > > > > > > > > Cheers, > > > > > Med > > > > > > > > > > > -----Message d'origine----- > > > > > > De=A0: Konda, Tirumaleswar Reddy > > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > Envoy=E9=A0: mercredi 4 avril 2018 17:40 =C0=A0: Jon Shallow; > > > > > > BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet=A0: RE: > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > The TTL value returned under alt-server-record is equivalent > > > > > > to the DNS TTL value. A DDoS mitigation provider with multiple > > > > > > DOTS servers typically re-directs a DOTS client to a different > > > > > > DOTS server only if the alternate DOTS server has the capacity > > > > > > to handle the requests from the > > > > > DOTS client. > > > > > > > > > > > > We can add the following lines to avoid loops : > > > > > > > > > > > > If the DOTS client has been redirected to a DOTS server to > > > > > > which it has already sent the mitigation request within the > > > > > > last five minutes, it MUST ignore the redirection and try > > > > > > reaching others servers listed in the local configuration or > > > > > > discovered using dynamic means such as DHCP or SRV procedures. > > > > > > This prevents infinite ping-ponging between servers in case of > > > > > > redirection loops. > > > > > > > > > > > > -Tiru > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon > > > > > > > Shallow > > > > > > > Sent: Wednesday, April 4, 2018 8:16 PM > > > > > > > To: mohamed.boucadair@orange.com; dots@ietf.org > > > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected > > > > > > > Signaling > > > > > > > > > > > > > > Hi there, > > > > > > > > > > > > > > See inline [Jon] > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > > > > > > mohamed.boucadair@orange.com > > > > > > > Sent: 04 April 2018 15:07 > > > > > > > To: Jon Shallow; dots@ietf.org > > > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected > > > > > > > Signaling > > > > > > > > > > > > > > Re-, > > > > > > > > > > > > > > Please see inline. > > > > > > > > > > > > > > Cheers, > > > > > > > Med > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Dots > > > > > > > > [mailto:dots-bounces@ietf.org] De la part de Jon Shallow > > > > > > > > Envoy=E9=A0: mercredi 4 avril 2018 15:31 =C0=A0: dots@ietf.= org > > Objet=A0: > > > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > > Hi there, > > > > > > > > > > > > > > > > I have implemented the 300 Redirected-Signal in my DOTS cod= e. > > > > > > > > This then raises some questions about usability. > > > > > > > > > > > > > > > > Usability #1 > > > > > > > > > > > > > > > > Architecture 3.2.2 Redirected Signalling > > > > > > > > > > > > > > > > 4. Having redirected the DOTS client, DOTS server A > > > > > > > > ceases > > > > sending > > > > > > > > server signals. The DOTS client likewise stops > > > > > > > > sending > > client > > > > > > > > signals to DOTS server A. DOTS session 1 is termina= ted. > > > > > > > > > > > > > > > > Clearly indicates that the original session (Client to > > > > > > > > Server > > > > > > > > A) is no more once redirected and only Client to Server B > > > > > > > > is in > > use. > > > > > > > > > > > > > > > > How is the traffic redirected back to Server A once > > > > > > > > maintenance / overloading etc. has finished? My > > > > > > > > assumption is that Server B sends a redirect to go back to > > > > > > > > Server A as Server A has no way to say over a now > > > > > > > > non-existent session to say > > > "come back". > > > > > > > > > > > > > > [Med] That's one possibility. This one does not require any > > > > > > > update to the > > > > > > signal- > > > > > > > channel specification. > > > > > > > > > > > > > > Another approach would be to not require any redirect signal > > > > > > > from server > > > > > B. > > > > > > > The client will remove server B's records upon the expiry of > > > > > > > the TTL and > > > > > > will fall > > > > > > > back to the "base" DOTS servers configuration that was > > > > > > > provisioned to the > > > > > > client > > > > > > > using DHCP or whatever mechanism. > > > > > > > [Jon] OK. The TTL is defined at, associated with the IP > > > > > > > address level > > > > > > under alt- > > > > > > > server-record, not under > > > > > > > ietf-dots-signal-channel:redirected-signal. The ttl definit= ion is > > > > > > > ambiguous as to what it refers to and perhaps could be > > > > > > > tightened up in the language (I read it as being associated > > > > > > > with "addr" in the sense of a DNS > > > > > > TTL). > > > > > > > > > > > > > > > > > > > > > > > Do we need to keep the existing Client to Server A session > > > > > > > > warm (or perhaps to probe periodically) to see if Server A > > > > > > > > is capable of handling the Client again by a server > > > > > > > > response extension to the protocol (e.g. a 3.01) > > > > > > > > > > > > > > [Med] Redirect was initially introduced to manage a server > > > > > > > overload, so I > > > > > > don't > > > > > > > think it makes sense to probe or maintain a session with serv= er A. > > > > > > > [Jon] Agreed, but I needed to raise the question. > > > > > > > > > > > > > > > > > > > > > > > Should there be a retry period parameter added in to the > > > > > > > > 3.00 protocol (as I read it, ttl only refers to the IP addr= ess)? > > > > > > > > > > > > > > [Med] The client will automatically switch to Server A when > > > > > > > all alternate > > > > > > records > > > > > > > expire. > > > > > > > [Jon] OK - again the 4.6 text needs to get tightened up to > > > > > > > reflect this as > > > > > > the > > > > > > > intent. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Usability #2 > > > > > > > > > > > > > > > > Server A says "Redirect to Server B" due to overloading. > > > > > > > > Server B accepts things for a while and then is > > > > > > > > instructed/decides to redirect traffic back to A. Server > > > > > > > > A is left still overload configured to redirect to B. How > > > > > > > > should the client handle this as there is no suitable > > > > > > > Server? > > > > > > > > > > > > > > [Med] This is a service configuration problem. We may ask: > > > > > > > * the client to log the error and notify the administrator. > > > > > > > * and/or stop the redirection after n cycles. > > > > > > > > > > > > > > Still, this does not solve the problem. > > > > > > > [Jon] Agreed there is a problem here > > > > > > > > > > > > > > > > > > > > > > > I agree that there needs to be co-ordination between > > > > > > > > Server A and Server B, but user error may creep in. > > > > > > > > > > > > > > > > Usability #3 > > > > > > > > > > > > > > > > Server A says "Redirect to Server B" as it going to be > > > > > > > > shut down because of maintenance. Server B accepts things > > > > > > > > for a while and then is instructed (in probable user > > > > > > > > error) to redirect traffic back to A (perhaps because it > > > > > > > > has hit an overload condition). How should the client > > > > > > > handle this? > > > > > > > > > > > > > > [Med] Isn't this a sub-case or #2? > > > > > > > [Jon] Yes, but I wanted to bring in Server A being alive and > > > > > > > able to > > > > > > respond > > > > > > > versus Server A down and not responding due to maintenance. > > > > > > > [Jon] With my better understanding of TTL we still have an > > > > > > > issue if the TTL expires and Server A is having an extended o= utage. > > > > > > > How do we recover from that? > > > > > > > ~jon > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Dots mailing list > > > > > > > > Dots@ietf.org > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Dots mailing list > > > > > > > Dots@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Dots mailing list > > > > > > > Dots@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > _______________________________________________ > > > > > Dots mailing list > > > > > Dots@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots From nobody Fri Apr 6 05:07:28 2018 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 3646C126BF3 for ; Fri, 6 Apr 2018 05:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7wvRiNTs6Ptg for ; Fri, 6 Apr 2018 05:07:25 -0700 (PDT) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE4D21201FA for ; Fri, 6 Apr 2018 05:07:24 -0700 (PDT) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 76D7E180DC6; Fri, 6 Apr 2018 14:07:23 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.27]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 50FB61A0084; Fri, 6 Apr 2018 14:07:23 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7C.corporate.adroot.infra.ftgroup ([fe80::8007:17b:c3b4:d68b%19]) with mapi id 14.03.0382.000; Fri, 6 Apr 2018 14:07:23 +0200 From: To: "Konda, Tirumaleswar Reddy" , "Jon Shallow" , "dots@ietf.org" Thread-Topic: [Dots] Signal Channel - 300 Redirected Signaling Thread-Index: AdPMGSyCaQQbv+vLSW+0gkDbU7HOEwAAo7xAAAH7T4AAARdqYAAhoxEAAAGQiwAAAKyNYAAF3e1QACUKCFAAAZEMQAAIeXTgAARcGhA= Date: Fri, 6 Apr 2018 12:07:22 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DEF93EE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <014f01d3cc19$2e3880e0$8aa982a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7E7B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <019901d3cc23$a93ff8e0$fbbfeaa0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8524@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <004e01d3ccb4$d505e7f0$7f11b7d0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8758@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEF912A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling 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, 06 Apr 2018 12:07:27 -0000 Re-, Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumales= war > Reddy > Envoy=E9=A0: vendredi 6 avril 2018 11:59 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org > Objet=A0: Re: [Dots] Signal Channel - 300 Redirected Signaling >=20 > > -----Original Message----- > > From: mohamed.boucadair@orange.com > > [mailto:mohamed.boucadair@orange.com] > > Sent: Friday, April 6, 2018 11:26 AM > > To: Konda, Tirumaleswar Reddy ; > > Jon Shallow ; dots@ietf.org > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > Hi Tiru, > > > > Please see inline. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: Konda, Tirumaleswar Reddy > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > Envoy=E9=A0: vendredi 6 avril 2018 07:07 > > > =C0=A0: BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet= =A0: RE: > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > Hi Med, > > > > > > The proposed update restricts the client no to do a DNS lookup using > > > the alternate FQDN, further associating a TTL with the name > > > complicates the functionality on the DOTS client to re-establish > > > (D)TLS session with the primary DOTS server after the TTL expires. M= y > > > suggestion is to let the DOTS client continue to use the alternate DO= TS > server > > till it gets re-directed. > > > > [Med] This is possible with the current spec. > > > > Triggers for redirect and for falling back to the nominal configuration= are > > deployment-specific. The current spec allows for almost all the cases > discussed > > so far: > > > > (1) Redirect for the request in progress: A server does so by returning > TTL=3D0. > > (2) The alternate server is not involved in fall back to the nominal > server: upon > > expiry of ttl of all alternate IP addresses, then fall back automatical= ly > to the > > nominal server. > > (3) Redirect to an alternate server, which in turn will instruct the cl= ient > to > > redirect to the "base" configuration: a TTL is provided and the altern= ate > server > > can reply with a redirect code any time before the expiry of the TTL. A > long TTL > > can be returned if the alternate server will be responsible for > coordinating fall > > back to the base server. > > (4) Stop infinite redirects >=20 > Yes, but (1) and (2) complicate the functionality of the DOTS client. [Med] (1) and (2) is exactly the same functionality required for caching DN= S replies. The > only reason for adding alt-server-record in the response is DNS server ma= y > not be reachable by the DOTS server > because of a DDoS attack. >=20 [Med] Yes. Note that even if the name resolution was allowed, the client ha= s to deal with the TTL indicated in the response...which is exactly the sam= e as (1) and (2). =20 > > > > > > I > > > don't think the DOTS mitigation provider will know ahead-of-time the > > > TTL value after which the DOTS client should disconnect communicating > > > with the alternate DOTS server and re-establish (D)TLS session with > > > the primary DOTS server. > > > > [Med] It depends on the nature of the redirect: overload, planned > maintenance, > > etc. For planned maintenance, the TTL is known in general. >=20 > It's the primary DOTS server responsibility to point the DOTS client to a= n > optimal alternate server, where the client can continue to send migration > requests without a frequent ping-pong between servers. [Med] Agree. This is a service configuration problem.=20 > I have seen TURN servers being deployed for several years with re-directi= on > but without the need for TTL (see ALTERNATE-SERVER in > https://tools.ietf.org/html/draft-ietf-tram-turnbis-11) >=20 > -Tiru >=20 > > > > > > > > Cheers, > > > -Tiru > > > > > > > -----Original Message----- > > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of > > > > mohamed.boucadair@orange.com > > > > Sent: Thursday, April 5, 2018 4:50 PM > > > > To: Konda, Tirumaleswar Reddy ; > > > > Jon Shallow ; dots@ietf.org > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > Tiru, > > > > > > > > I don't see the NEW text as a restriction but as a simplification o= f > > > > the > > > client's > > > > behavior. I don't want to over-specify the redirect behavior. > > > > > > > > Adding another yet layer of resolution will raise other issues such > > > > as the > > > need to > > > > associate a TTL with the name itself. > > > > > > > > Cheers, > > > > Med > > > > > > > > > -----Message d'origine----- > > > > > De=A0: Konda, Tirumaleswar Reddy > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > Envoy=E9=A0: jeudi 5 avril 2018 12:06 > > > > > =C0=A0: Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Obj= et=A0: RE: > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > -----Original Message----- > > > > > > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > > > Sent: Thursday, April 5, 2018 1:35 PM > > > > > > To: mohamed.boucadair@orange.com; Konda, Tirumaleswar Reddy > > > > > > ; dots@ietf.org > > > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > Hi Med, > > > > > > > > > > > > Thanks for this refresh to 4.6 Redirected Signaling > > > > > > > > > > > > Some comments > > > > > > > > > > > > #1 > > > > > > > > > > > > The DOTS server can return the error response code 3.00 in > response > > > > > > to a PUT request from the DOTS client or convey the error > response > > > > > > code 3.00 in a unidirectional notification response from the > DOTS > > > > > > server. > > > > > > > > > > > > Why is this limited to a PUT request and/or unidirectional > > > > > > notification > > > > > response? > > > > > > - Surely, any response, unsolicited or otherwise can contain a > > > > > > 3.00 > > > > > > - If Observe is not in use, then any unsolicited notification > > > > > > response will potentially get rejected by the coap library > > > > > > layer, so a DOTS Server cannot > > > > > signal > > > > > > maintenance outage other than by closing the session. > > > > > > - I missed this the last review - sorry > > > > > > > > > > > > > > > > > #2 > > > > > > > > > > > > If the DOTS client has been redirected to a DOTS server to w= hich > it > > > > > > has already sent the mitigation request within the last five= (5) > > > > > > minutes, it MUST ignore the redirection and try to contact > > > > > > other DOTS > > > > > > > > > > > > s/ has already sent the mitigation request/ has already > > > > > > communicated with/ > > > > > > > > > > > > #3 > > > > > > > > > > > > A DOTS client MUST NOT use an alternate IP address to con= tact > its > > > > > > DOTS server upon expiry of the associated TTL. > > > > > > > > > > > > To remove ambiguity over the use of FQDN, this could read > > > > > > > > > > > > A DOTS client MUST NOT use an alternate IP address to con= tact > its > > > > > > DOTS server upon expiry of the associated TTL. > > > > > > Furthermore, a > > > DOTS > > > > > > Client MUST NOT use the alt-server FQDN if all of the > > > > > > alt-server- > > > > > records > > > > > > have expired. > > > > > > > > > > > > Or alternatively > > > > > > > > > > > > alt-server: FQDN of an alternate DOTS server. > > > > > > > > > > > > This could read > > > > > > > > > > > > alt-server: FQDN of an alternate DOTS server. This FQDN is > > > > > > not to be > > > > > used for > > > > > > looking up IP addresses to use, but is there for the SNI > > > > > > extension > > > (7.1. > > > > > (D)TLS > > > > > > Protocol Profile) > > > > > > > > > > I don't think the above restriction is correct for the following > reasons: > > > > > > > > > > 1) If the TTL value in the alt-server-record expires, DNS lookup > > > > > can be performed by the DOTS client using the alternate DOTS serv= er > FQDN. > > > > > 2) If the DNS server is reachable, the client may want to a DANE > > > > > lookup to get the IP addresses and certificate to validate the > > > > > alternate DOTS server certificate sent > > > > > in the DTLS handshake. > > > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > Jon > > > > > > -----Original Message----- > > > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > > > > > mohamed.boucadair@orange.com > > > > > > Sent: 05 April 2018 08:20 > > > > > > To: Konda, Tirumaleswar Reddy; Jon Shallow; dots@ietf.org > > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > Hi Tiru, > > > > > > > > > > > > Works for me. > > > > > > > > > > > > I updated the draft with the text additions that were discussed > > > > > > in this thread. The changes can be found at: > > > > > > https://github.com/boucadair/draft-ietf-dots-signal- > > > > > channel/blob/master/draf > > > > > > t-ietf-dots-signal-channel.txt > > > > > > > > > > > > Cheers, > > > > > > Med > > > > > > > > > > > > > -----Message d'origine----- > > > > > > > De=A0: Konda, Tirumaleswar Reddy > > > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > > Envoy=E9=A0: mercredi 4 avril 2018 17:40 =C0=A0: Jon Shallow; > > > > > > > BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet=A0: RE: > > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > The TTL value returned under alt-server-record is equivalent > > > > > > > to the DNS TTL value. A DDoS mitigation provider with multipl= e > > > > > > > DOTS servers typically re-directs a DOTS client to a differen= t > > > > > > > DOTS server only if the alternate DOTS server has the capacit= y > > > > > > > to handle the requests from the > > > > > > DOTS client. > > > > > > > > > > > > > > We can add the following lines to avoid loops : > > > > > > > > > > > > > > If the DOTS client has been redirected to a DOTS server to > > > > > > > which it has already sent the mitigation request within the > > > > > > > last five minutes, it MUST ignore the redirection and try > > > > > > > reaching others servers listed in the local configuration or > > > > > > > discovered using dynamic means such as DHCP or SRV procedures= . > > > > > > > This prevents infinite ping-ponging between servers in case o= f > > > > > > > redirection loops. > > > > > > > > > > > > > > -Tiru > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon > > > > > > > > Shallow > > > > > > > > Sent: Wednesday, April 4, 2018 8:16 PM > > > > > > > > To: mohamed.boucadair@orange.com; dots@ietf.org > > > > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected > > > > > > > > Signaling > > > > > > > > > > > > > > > > Hi there, > > > > > > > > > > > > > > > > See inline [Jon] > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > > > > > > > mohamed.boucadair@orange.com > > > > > > > > Sent: 04 April 2018 15:07 > > > > > > > > To: Jon Shallow; dots@ietf.org > > > > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected > > > > > > > > Signaling > > > > > > > > > > > > > > > > Re-, > > > > > > > > > > > > > > > > Please see inline. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Med > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Dots > > > > > > > > > [mailto:dots-bounces@ietf.org] De la part de Jon Shallow > > > > > > > > > Envoy=E9=A0: mercredi 4 avril 2018 15:31 =C0=A0: dots@iet= f.org > > > Objet=A0: > > > > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > > > > Hi there, > > > > > > > > > > > > > > > > > > I have implemented the 300 Redirected-Signal in my DOTS c= ode. > > > > > > > > > This then raises some questions about usability. > > > > > > > > > > > > > > > > > > Usability #1 > > > > > > > > > > > > > > > > > > Architecture 3.2.2 Redirected Signalling > > > > > > > > > > > > > > > > > > 4. Having redirected the DOTS client, DOTS server A > > > > > > > > > ceases > > > > > sending > > > > > > > > > server signals. The DOTS client likewise stops > > > > > > > > > sending > > > client > > > > > > > > > signals to DOTS server A. DOTS session 1 is > terminated. > > > > > > > > > > > > > > > > > > Clearly indicates that the original session (Client to > > > > > > > > > Server > > > > > > > > > A) is no more once redirected and only Client to Server B > > > > > > > > > is in > > > use. > > > > > > > > > > > > > > > > > > How is the traffic redirected back to Server A once > > > > > > > > > maintenance / overloading etc. has finished? My > > > > > > > > > assumption is that Server B sends a redirect to go back t= o > > > > > > > > > Server A as Server A has no way to say over a now > > > > > > > > > non-existent session to say > > > > "come back". > > > > > > > > > > > > > > > > [Med] That's one possibility. This one does not require any > > > > > > > > update to the > > > > > > > signal- > > > > > > > > channel specification. > > > > > > > > > > > > > > > > Another approach would be to not require any redirect signa= l > > > > > > > > from server > > > > > > B. > > > > > > > > The client will remove server B's records upon the expiry o= f > > > > > > > > the TTL and > > > > > > > will fall > > > > > > > > back to the "base" DOTS servers configuration that was > > > > > > > > provisioned to the > > > > > > > client > > > > > > > > using DHCP or whatever mechanism. > > > > > > > > [Jon] OK. The TTL is defined at, associated with the IP > > > > > > > > address level > > > > > > > under alt- > > > > > > > > server-record, not under > > > > > > > > ietf-dots-signal-channel:redirected-signal. The ttl > definition is > > > > > > > > ambiguous as to what it refers to and perhaps could be > > > > > > > > tightened up in the language (I read it as being associated > > > > > > > > with "addr" in the sense of a DNS > > > > > > > TTL). > > > > > > > > > > > > > > > > > > > > > > > > > > Do we need to keep the existing Client to Server A sessio= n > > > > > > > > > warm (or perhaps to probe periodically) to see if Server = A > > > > > > > > > is capable of handling the Client again by a server > > > > > > > > > response extension to the protocol (e.g. a 3.01) > > > > > > > > > > > > > > > > [Med] Redirect was initially introduced to manage a server > > > > > > > > overload, so I > > > > > > > don't > > > > > > > > think it makes sense to probe or maintain a session with se= rver > A. > > > > > > > > [Jon] Agreed, but I needed to raise the question. > > > > > > > > > > > > > > > > > > > > > > > > > > Should there be a retry period parameter added in to the > > > > > > > > > 3.00 protocol (as I read it, ttl only refers to the IP > address)? > > > > > > > > > > > > > > > > [Med] The client will automatically switch to Server A when > > > > > > > > all alternate > > > > > > > records > > > > > > > > expire. > > > > > > > > [Jon] OK - again the 4.6 text needs to get tightened up to > > > > > > > > reflect this as > > > > > > > the > > > > > > > > intent. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Usability #2 > > > > > > > > > > > > > > > > > > Server A says "Redirect to Server B" due to overloading. > > > > > > > > > Server B accepts things for a while and then is > > > > > > > > > instructed/decides to redirect traffic back to A. Server > > > > > > > > > A is left still overload configured to redirect to B. Ho= w > > > > > > > > > should the client handle this as there is no suitable > > > > > > > > Server? > > > > > > > > > > > > > > > > [Med] This is a service configuration problem. We may ask: > > > > > > > > * the client to log the error and notify the administrator. > > > > > > > > * and/or stop the redirection after n cycles. > > > > > > > > > > > > > > > > Still, this does not solve the problem. > > > > > > > > [Jon] Agreed there is a problem here > > > > > > > > > > > > > > > > > > > > > > > > > > I agree that there needs to be co-ordination between > > > > > > > > > Server A and Server B, but user error may creep in. > > > > > > > > > > > > > > > > > > Usability #3 > > > > > > > > > > > > > > > > > > Server A says "Redirect to Server B" as it going to be > > > > > > > > > shut down because of maintenance. Server B accepts thing= s > > > > > > > > > for a while and then is instructed (in probable user > > > > > > > > > error) to redirect traffic back to A (perhaps because it > > > > > > > > > has hit an overload condition). How should the client > > > > > > > > handle this? > > > > > > > > > > > > > > > > [Med] Isn't this a sub-case or #2? > > > > > > > > [Jon] Yes, but I wanted to bring in Server A being alive an= d > > > > > > > > able to > > > > > > > respond > > > > > > > > versus Server A down and not responding due to maintenance. > > > > > > > > [Jon] With my better understanding of TTL we still have an > > > > > > > > issue if the TTL expires and Server A is having an extended > outage. > > > > > > > > How do we recover from that? > > > > > > > > ~jon > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > Dots mailing list > > > > > > > > > Dots@ietf.org > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Dots mailing list > > > > > > > > Dots@ietf.org > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Dots mailing list > > > > > > > > Dots@ietf.org > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > _______________________________________________ > > > > > > Dots mailing list > > > > > > Dots@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > _______________________________________________ > > > > Dots mailing list > > > > Dots@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Fri Apr 6 06:28:09 2018 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 54F7112702E for ; Fri, 6 Apr 2018 06:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJDw9RGZDkAm for ; Fri, 6 Apr 2018 06:28:05 -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 4E41D1201FA for ; Fri, 6 Apr 2018 06:28:05 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.90_1) (envelope-from ) id 1f4RPM-0001Og-Ia; Fri, 06 Apr 2018 14:28:00 +0100 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , , References: <008401d3c4fd$216d0840$644718c0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF1067@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <014801d3c5b7$94c67f00$be537d00$@jpshallow.com> In-Reply-To: Date: Fri, 6 Apr 2018 14:27:59 +0100 Message-ID: <009a01d3cdab$150b4c40$3f21e4c0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_009B_01D3CDB3.76D1B010" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGlexwLZckIYJuvKwEmwuQr1rXL6AKpdMHOAgMRKpIBsBKRFgKXgqsdpAi9G9A= Content-Language: en-gb Archived-At: Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 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, 06 Apr 2018 13:28:08 -0000 This is a multipart message in MIME format. ------=_NextPart_000_009B_01D3CDB3.76D1B010 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi there, =20 There is no current way to request of a DOTS Server as to what is the = set of IP networks that a DOTS client can use either within a mitigation = request or to set up an ACL other than by =93testing for ok or not ok=94 with lots = of different IP addresses. =20 There is a reasonable likelihood of the scope of valid IPs from the = Server=92s perspective will change over time. So, unless a DOTS client wants to control a specific destination network, then my suggestion would be to = leave the ACE destination network empty and for the DOTS Server / DOTS = mitigator (how is out of scope) to fill it in at time of ACE instantiation. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 27 March 2018 13:49 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 =20 Please see inline [TR] =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Tuesday, March 27, 2018 4:07 PM To: Konda, Tirumaleswar Reddy ; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 =20 Hi Tiru / Med =20 See inline [Jon] =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 27 March 2018 09:47 To: mohamed.boucadair@orange.com; Jon Shallow; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 =20 I also support to mandate destination-network for immediately enforced filtering rules. [Jon] This can be enforced / inserted by the DOTS Server for all the destination networks of the domain that the DOTS client =91belongs=92 = to. That said, it would be good to always have the destination network in an ACL = as it can be validated and cross-checked whenever the legitimate set of = domain protected IPs are updated. [Jon] However, what happens to the Destination network in the case of a = call home DOTS client that becomes a quasi DOTS server and the Destination networks are somewhere out on the Internet? =20 [TR] DDOS is a targeted attack, so the DOTS client can specify the destination network targeted by devices in the DOTS server domain and = the DOTS server can validate if the destination network is indeed targeted = by its devices. =20 -Tiru =20 From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed..boucadair@orange.com =20 Sent: Tuesday, March 27, 2018 1:09 PM To: Jon Shallow ; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 =20 Hi Jon,=20 =20 Thank you for the comments. =20 Please see inline. =20 Cheers, Med =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : lundi 26 mars 2018 14:23 =C0 : dots@ietf.org Objet : [Dots] IETF 101 Presentation Data Channel Issue #4 =20 Hi there, =20 As per Med=92s presentation to the IETF 101 =20 Issue #4: Per-Domain or Per-client Filters? =20 =95 Conclusion =96 Filters that are activated only during mitigation time are on a = per-client basis =95 Filters are per-domain when are immediately applied =20 =93Filters are per-domain when are immediately applied=94 is what I have = an challenge with. =20 If we have a compromised or rogue DOTS client, the simple use of = something like curl, along with the client certificates etc. can be used to = generate any ACL with activation-type :=3D =91immediate=92 which is then = immediately applied for all traffic within the domain as per the above. =20 [Med] Yes. FWIW, this attack is called out in the security = considerations section:=20 =20 =93Nevertheless, an attacker who can access a DOTS client is technically capable of launching various attacks, such as: =20 ..; =20 o Set invalid ACL entries, which may prevent legitimate traffic from being forwarded. Likewise, invalid ACL entries may lead to forward DDoS traffic. =93 [Jon] Agreed that the attack is covered off in the Security section, but = we should be limiting the possibility / scope of the attack vector by = enforcing some rules as to what is / is not allowed. Allowing a DOTS client to be able to affect all the traffic within the domain is a huge risk to me = and should not be allowed. =20 So, a ACL that blacklists the DNS server, or drops all port 443 traffic = etc. can easily cause all of the other clients / devices within the domain to = be taken off air. Putting the intelligence into the DOTS server to not = allow this to happen could be a challenge. [The signal channel is much harder to compromise and affect traffic = flows to other areas within the domain] =20 I believe that an ACL instantiated by a DOTS client (immediate or when-mitigating) should only apply to the DOTS client=92s traffic which = means that the destination-network has to be a part of the ACL, whether = implicitly added by the DOTS server, or by the DOTS client and suitably validated. =20 [Med] Putting aside that I don=92t parse =93DOTS client=92s traffic=94, [Jon] I was referring to all the traffic flows that a DOTS client can legitimately request control of to the DOTS server that are within the = scope of what the DOTS client is protecting (which may or may not be the DOTS client=92s IP address). I interpret your answer as a support to this question raised for issue = #4: * =93Should we mandate destination-network to be present for immediately enforced filters?=94 [Jon] See response to Tiru=92s Agreement above. ~Jon There is nothing to stop the DOTS server or DOTS mitigator merging = common ACLs to reduce the number of ACLs within the mitigation device. =20 As a side note =93mitigation-time=94 is perhaps a bad name as it implies = a time period =96 something like =93when-mitigating=94 to me is clearer. [Med] Fixed in my local copy. Thank you. =20 Regards =20 Jon ------=_NextPart_000_009B_01D3CDB3.76D1B010 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi there,

 

There is no current way = to request of a DOTS Server as to what is the set of IP networks that a = DOTS client can use either within a mitigation request or to set up an = ACL other than by “testing for ok or not ok” with lots of = different IP addresses.

 

There is a reasonable = likelihood of the scope of valid IPs from the Server’s perspective = will change over time.=A0 So, unless a DOTS client wants to control a = specific destination network, then my suggestion would be to leave the = ACE destination network empty and for the DOTS Server / DOTS mitigator = (how is out of scope) to fill it in at time of ACE = instantiation.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = Konda, Tirumaleswar Reddy
Sent: 27 March 2018 = 13:49
To: Jon Shallow; mohamed.boucadair@orange.com; = dots@ietf.org
Subject: Re: [Dots] IETF 101 Presentation Data = Channel Issue #4

 

Please see inline = [TR]

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Tuesday, March 27, 2018 4:07 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: RE: = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

Hi Tiru / Med

 

See inline = [Jon]

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 27 March 2018 = 09:47
To: mohamed.boucadair@orange.com= ; Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

I also support to = mandate destination-network for immediately enforced filtering = rules.

[Jon] This can be = enforced / inserted by the DOTS Server for all the destination networks = of the domain that the DOTS client ‘belongs’ to.  That = said, it would be good to always have the destination network in an ACL = as it can be validated and cross-checked whenever the legitimate set of = domain protected IPs are updated.

[Jon] However, what = happens to the Destination network in the case of a call home DOTS = client that becomes a quasi DOTS server and the Destination networks are = somewhere out on the Internet?

 

[TR] DDOS is a targeted attack, so = the DOTS client can specify the destination network targeted by devices = in the DOTS server domain and the DOTS server can validate if the = destination network is indeed targeted by its = devices.

 

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of mohamed..boucadair@orange.co= m
Sent: Tuesday, March 27, 2018 1:09 PM
To: Jon = Shallow <supjps-ietf@jpshallow.com&g= t;; dots@ietf.org
Subject: Re: = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

Hi Jon,

 

Thank you for the comments.

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] = De la part de Jon Shallow
Envoy=E9 : lundi 26 mars = 2018 14:23
=C0 : dots@ietf.org
Objet : = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

Hi = there,

 

As per Med’s presentation to the IETF = 101

 

Issue #4: Per-Domain or Per-client = Filters?

 

• Conclusion

– Filters that are activated only during = mitigation time are on a per-client basis

   • Filters are per-domain when are = immediately applied

 

“Filters are per-domain when are immediately = applied” is what I have an challenge with.

 

If we have a = compromised or rogue DOTS client, the simple use of something like curl, = along with the client certificates etc. can be used to generate any ACL = with activation-type :=3D ‘immediate’ which is then = immediately applied for all traffic within the domain as per the = above.

 

[Med] = Yes. FWIW, this attack is called out in the security considerations = section:

 

“Nevertheless, =
an

   attacker who can access a = DOTS client is technically capable of

   launching various attacks, = such as:

 

..;

 

   o  Set invalid ACL entries, which may =
prevent legitimate traffic from
      being forwarded.  =
Likewise, invalid ACL entries may lead =
to
      forward DDoS traffic.

“

[Jon] Agreed that the = attack is covered off in the Security section, but we should be limiting = the possibility / scope of the attack vector by enforcing some rules as = to what is / is not allowed.  Allowing a DOTS client to be able to = affect all the traffic within the domain is a huge risk to me and should = not be allowed.

 

So, a ACL = that blacklists the DNS server, or drops all port 443 traffic etc. can = easily cause all of the other clients / devices within the domain to be = taken off air.  Putting the intelligence into the DOTS server to = not allow this to happen could be a challenge.

[The signal channel is much harder to compromise and = affect traffic flows to other areas within the domain]

 

I believe = that an ACL instantiated by a DOTS client (immediate or when-mitigating) = should only apply to the DOTS client’s traffic which means that = the destination-network has to be a part of the ACL, whether implicitly = added by the DOTS server, or by the DOTS client and suitably = validated.

 

[Med] = Putting aside that I don’t parse “DOTS client’s = traffic”,

[Jon] I was referring to all the traffic flows = that a DOTS client can legitimately request control of to the DOTS = server that are within the scope of what the DOTS client is protecting = (which may or may not be the DOTS client’s IP = address).

I = interpret your answer as a support to this question raised for issue = #4:

    • “Should = we mandate destination-network to be present for immediately enforced = filters?”

[Jon] See response to = Tiru’s Agreement above.

~Jon

There is nothing to stop the DOTS server or DOTS = mitigator merging common ACLs to reduce the number of ACLs within the = mitigation device.

 

As a side = note “mitigation-time” is perhaps a bad name as it implies a = time period – something like “when-mitigating” to me = is clearer.

[Med] = Fixed in my local copy. Thank you.

 

Regards

 

Jon

------=_NextPart_000_009B_01D3CDB3.76D1B010-- From nobody Fri Apr 6 06:32:44 2018 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 001181270A0 for ; Fri, 6 Apr 2018 06:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pyFAzsWfVFQq for ; Fri, 6 Apr 2018 06:32:40 -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 CD8D112702E for ; Fri, 6 Apr 2018 06:32:39 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.90_1) (envelope-from ) id 1f4RTq-0001P9-85; Fri, 06 Apr 2018 14:32:38 +0100 From: "Jon Shallow" To: , "Konda, Tirumaleswar Reddy" , References: <014f01d3cc19$2e3880e0$8aa982a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7E7B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <019901d3cc23$a93ff8e0$fbbfeaa0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8524@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <004e01d3ccb4$d505e7f0$7f11b7d0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8758@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEF912A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEF93EE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <008501d3cda6$c860d210$59227630$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF951 1@OPEXCLILMA3. corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DEF9511@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Fri, 6 Apr 2018 14:32:37 +0100 Message-ID: <00b001d3cdab$ba8caec0$2fa60c40$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ5xX4UsK17va5Vv37fpNudI6+9awKIdnG+AkIt6UkCuIhgoQJj4oJpArGJQHwA3D0H4gGs0H5ZApHDVXYB/IC8TgE0bwOgAlFzC1QBmQ12ZgIBMqaPodFL5FA= Content-Language: en-gb Archived-At: Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling 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, 06 Apr 2018 13:32:43 -0000 Excellent. Thanks Jon -----Original Message----- From: mohamed.boucadair@orange.com [mailto: = mohamed.boucadair@orange.com]=20 Sent: 06 April 2018 14:29 To: Jon Shallow; Konda, Tirumaleswar Reddy; rdd@cert.org Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling Hi Jon, all,=20 I'm fine to put ttl at the level of alt-server. Cheers, Med > -----Message d'origine----- > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > Envoy=E9=A0: vendredi 6 avril 2018 14:57 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; = rdd@cert.org=20 > Objet=A0: RE: [Dots] Signal Channel - 300 Redirected Signaling >=20 > Hi there, >=20 > See inline [Jon3] >=20 > Regards >=20 > Jon >=20 >=20 > > > > -----Message d'origine----- > > > > De=A0: Konda, Tirumaleswar Reddy > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > Envoy=E9=A0: vendredi 6 avril 2018 07:07 =C0=A0: BOUCADAIR = Mohamed=20 > > > > IMT/OLN; Jon Shallow; dots@ietf.org Objet=A0: RE: > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > Hi Med, > > > > > > > > The proposed update restricts the client no to do a DNS lookup=20 > > > > using the alternate FQDN, further associating a TTL with the=20 > > > > name complicates the functionality on the DOTS client to=20 > > > > re-establish (D)TLS session with the primary DOTS server after = the TTL expires. > > > > My suggestion is to let the DOTS client continue to use the=20 > > > > alternate DOTS > > server > > > till it gets re-directed. > > > > > > [Med] This is possible with the current spec. > > > > > > Triggers for redirect and for falling back to the nominal=20 > > > configuration are deployment-specific. The current spec allows for = > > > almost all the cases > > discussed > > > so far: > > > > > > (1) Redirect for the request in progress: A server does so by=20 > > > returning > > TTL=3D0. > > > (2) The alternate server is not involved in fall back to the=20 > > > nominal > > server: upon > > > expiry of ttl of all alternate IP addresses, then fall back=20 > > > automatically > > to the > > > nominal server. > > > (3) Redirect to an alternate server, which in turn will instruct=20 > > > the client > > to > > > redirect to the "base" configuration: a TTL is provided and the=20 > > > alternate > > server > > > can reply with a redirect code any time before the expiry of the=20 > > > TTL. A > > long TTL > > > can be returned if the alternate server will be responsible for > > coordinating fall > > > back to the base server. > > > (4) Stop infinite redirects > > > > Yes, but (1) and (2) complicate the functionality of the DOTS = client. >=20 > [Med] (1) and (2) is exactly the same functionality required for=20 > caching DNS replies. >=20 > The > > only reason for adding alt-server-record in the response is DNS=20 > > server may not be reachable by the DOTS server because of a DDoS = attack. > > >=20 > [Med] Yes. Note that even if the name resolution was allowed, the=20 > client has to deal with the TTL indicated in the response...which is=20 > exactly the same as (1) and (2). >=20 >=20 > [Jon3] I think where I am struggling here is the overloaded use of TTL = > - The TTL as per a DNS record and held as a part of alt-server-record=20 > and then the TTL after which that the alt-server should be handling=20 > the traffic before handling back to the original primary server. It=20 > either has to be one or the other, or they have to have different = names. > [Jon3] If we are only going to go for one variant for simplicity, then = > I would prefer that it should be at the level of "alt-server". =20 > Handling the TTL for DNS refresh is normally handled by a resolver=20 > library, updated by the DNS packets coming in - unusual for an = application to have to do that. >=20 > > > > > > > > > I > > > > don't think the DOTS mitigation provider will know ahead-of-time = > > > > the TTL value after which the DOTS client should disconnect=20 > > > > communicating with the alternate DOTS server and re-establish=20 > > > > (D)TLS session with the primary DOTS server. > > > > > > [Med] It depends on the nature of the redirect: overload, planned > > maintenance, > > > etc. For planned maintenance, the TTL is known in general. > > > > It's the primary DOTS server responsibility to point the DOTS client = > > to an optimal alternate server, where the client can continue to=20 > > send migration requests without a frequent ping-pong between = servers. >=20 > [Med] Agree. This is a service configuration problem. > [Jon3] Agreed - and the 5 minute minimum ping-pong time is a good=20 > safety net. > ~jon3 >=20 > > I have seen TURN servers being deployed for several years with > re-direction > > but without the need for TTL (see ALTERNATE-SERVER in > > https://tools.ietf.org/html/draft-ietf-tram-turnbis-11) > > > > -Tiru > > > > > > > > > > > > > Cheers, > > > > -Tiru > > > > > > > > > -----Original Message----- > > > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of=20 > > > > > mohamed.boucadair@orange.com > > > > > Sent: Thursday, April 5, 2018 4:50 PM > > > > > To: Konda, Tirumaleswar Reddy=20 > > > > > ; > > > > > Jon Shallow ; dots@ietf.org > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > Tiru, > > > > > > > > > > I don't see the NEW text as a restriction but as a=20 > > > > > simplification of the > > > > client's > > > > > behavior. I don't want to over-specify the redirect behavior. > > > > > > > > > > Adding another yet layer of resolution will raise other issues = > > > > > such as the > > > > need to > > > > > associate a TTL with the name itself. > > > > > > > > > > Cheers, > > > > > Med > > > > > > > > > > > -----Message d'origine----- > > > > > > De=A0: Konda, Tirumaleswar Reddy=20 > > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > Envoy=E9=A0: jeudi 5 avril 2018 12:06 =C0=A0: Jon Shallow; = BOUCADAIR=20 > > > > > > Mohamed IMT/OLN; dots@ietf.org Objet=A0: > RE: > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > > > > Sent: Thursday, April 5, 2018 1:35 PM > > > > > > > To: mohamed.boucadair@orange.com; Konda, Tirumaleswar=20 > > > > > > > Reddy ; dots@ietf.org > > > > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected=20 > > > > > > > Signaling > > > > > > > > > > > > > > Hi Med, > > > > > > > > > > > > > > Thanks for this refresh to 4.6 Redirected Signaling > > > > > > > > > > > > > > Some comments > > > > > > > > > > > > > > #1 > > > > > > > > > > > > > > The DOTS server can return the error response code 3.00 = > > > > > > > in > > response > > > > > > > to a PUT request from the DOTS client or convey the=20 > > > > > > > error > > response > > > > > > > code 3.00 in a unidirectional notification response=20 > > > > > > > from the > > DOTS > > > > > > > server. > > > > > > > > > > > > > > Why is this limited to a PUT request and/or unidirectional = > > > > > > > notification > > > > > > response? > > > > > > > - Surely, any response, unsolicited or otherwise can=20 > > > > > > > contain a > > > > > > > 3.00 > > > > > > > - If Observe is not in use, then any unsolicited=20 > > > > > > > notification response will potentially get rejected by the = > > > > > > > coap library layer, so a DOTS Server cannot > > > > > > signal > > > > > > > maintenance outage other than by closing the session. > > > > > > > - I missed this the last review - sorry > > > > > > > > > > > > > > > > > > > > #2 > > > > > > > > > > > > > > If the DOTS client has been redirected to a DOTS server = > > > > > > > to > which > > it > > > > > > > has already sent the mitigation request within the last = > > > > > > > five > (5) > > > > > > > minutes, it MUST ignore the redirection and try to=20 > > > > > > > contact other DOTS > > > > > > > > > > > > > > s/ has already sent the mitigation request/ has already=20 > > > > > > > communicated with/ > > > > > > > > > > > > > > #3 > > > > > > > > > > > > > > A DOTS client MUST NOT use an alternate IP address=20 > > > > > > > to > contact > > its > > > > > > > DOTS server upon expiry of the associated TTL. > > > > > > > > > > > > > > To remove ambiguity over the use of FQDN, this could read > > > > > > > > > > > > > > A DOTS client MUST NOT use an alternate IP address=20 > > > > > > > to > contact > > its > > > > > > > DOTS server upon expiry of the associated TTL. > > > > > > > Furthermore, a > > > > DOTS > > > > > > > Client MUST NOT use the alt-server FQDN if all of=20 > > > > > > > the > > > > > > > alt-server- > > > > > > records > > > > > > > have expired. > > > > > > > > > > > > > > Or alternatively > > > > > > > > > > > > > > alt-server: FQDN of an alternate DOTS server. > > > > > > > > > > > > > > This could read > > > > > > > > > > > > > > alt-server: FQDN of an alternate DOTS server. This=20 > > > > > > > FQDN is not to be > > > > > > used for > > > > > > > looking up IP addresses to use, but is there for the SNI=20 > > > > > > > extension > > > > (7.1. > > > > > > (D)TLS > > > > > > > Protocol Profile) > > > > > > > > > > > > I don't think the above restriction is correct for the=20 > > > > > > following > > reasons: > > > > > > > > > > > > 1) If the TTL value in the alt-server-record expires, DNS=20 > > > > > > lookup can be performed by the DOTS client using the=20 > > > > > > alternate DOTS > server > > FQDN. > > > > > > 2) If the DNS server is reachable, the client may want to a=20 > > > > > > DANE lookup to get the IP addresses and certificate to=20 > > > > > > validate the alternate DOTS server certificate sent > > > > > > in the DTLS handshake. > > > > > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > Jon > > > > > > > -----Original Message----- > > > > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of=20 > > > > > > > mohamed.boucadair@orange.com > > > > > > > Sent: 05 April 2018 08:20 > > > > > > > To: Konda, Tirumaleswar Reddy; Jon Shallow; dots@ietf.org > > > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected=20 > > > > > > > Signaling > > > > > > > > > > > > > > Hi Tiru, > > > > > > > > > > > > > > Works for me. > > > > > > > > > > > > > > I updated the draft with the text additions that were=20 > > > > > > > discussed in this thread. The changes can be found at: > > > > > > > https://github.com/boucadair/draft-ietf-dots-signal- > > > > > > channel/blob/master/draf > > > > > > > t-ietf-dots-signal-channel.txt > > > > > > > > > > > > > > Cheers, > > > > > > > Med > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Konda, Tirumaleswar=20 > > > > > > > > Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > > > Envoy=E9=A0: mercredi 4 avril 2018 17:40 =C0=A0: Jon = Shallow;=20 > > > > > > > > BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet=A0: RE: > > > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > > The TTL value returned under alt-server-record is=20 > > > > > > > > equivalent to the DNS TTL value. A DDoS mitigation=20 > > > > > > > > provider with multiple DOTS servers typically re-directs = > > > > > > > > a DOTS client to a different DOTS server only if the=20 > > > > > > > > alternate DOTS server has the capacity to handle the=20 > > > > > > > > requests from the > > > > > > > DOTS client. > > > > > > > > > > > > > > > > We can add the following lines to avoid loops : > > > > > > > > > > > > > > > > If the DOTS client has been redirected to a DOTS server=20 > > > > > > > > to which it has already sent the mitigation request=20 > > > > > > > > within the last five minutes, it MUST ignore the=20 > > > > > > > > redirection and try reaching others servers listed in=20 > > > > > > > > the local configuration or discovered using dynamic = means such as DHCP or SRV procedures. > > > > > > > > This prevents infinite ping-ponging between servers in=20 > > > > > > > > case of redirection loops. > > > > > > > > > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of = > > > > > > > > > Jon Shallow > > > > > > > > > Sent: Wednesday, April 4, 2018 8:16 PM > > > > > > > > > To: mohamed.boucadair@orange.com; dots@ietf.org > > > > > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected=20 > > > > > > > > > Signaling > > > > > > > > > > > > > > > > > > Hi there, > > > > > > > > > > > > > > > > > > See inline [Jon] > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf=20 > > > > > > > > > Of mohamed.boucadair@orange.com > > > > > > > > > Sent: 04 April 2018 15:07 > > > > > > > > > To: Jon Shallow; dots@ietf.org > > > > > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected=20 > > > > > > > > > Signaling > > > > > > > > > > > > > > > > > > Re-, > > > > > > > > > > > > > > > > > > Please see inline. > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > Med > > > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Dots=20 > > > > > > > > > > [mailto:dots-bounces@ietf.org] De la part de Jon=20 > > > > > > > > > > Shallow Envoy=E9=A0: mercredi 4 avril 2018 15:31 = =C0=A0:=20 > > > > > > > > > > dots@ietf.org > > > > Objet=A0: > > > > > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > > > > > > Hi there, > > > > > > > > > > > > > > > > > > > > I have implemented the 300 Redirected-Signal in my=20 > > > > > > > > > > DOTS > code. > > > > > > > > > > This then raises some questions about usability. > > > > > > > > > > > > > > > > > > > > Usability #1 > > > > > > > > > > > > > > > > > > > > Architecture 3.2.2 Redirected Signalling > > > > > > > > > > > > > > > > > > > > 4. Having redirected the DOTS client, DOTS=20 > > > > > > > > > > server A ceases > > > > > > sending > > > > > > > > > > server signals. The DOTS client likewise=20 > > > > > > > > > > stops sending > > > > client > > > > > > > > > > signals to DOTS server A. DOTS session 1 is > > terminated. > > > > > > > > > > > > > > > > > > > > Clearly indicates that the original session (Client=20 > > > > > > > > > > to Server > > > > > > > > > > A) is no more once redirected and only Client to=20 > > > > > > > > > > Server B is in > > > > use. > > > > > > > > > > > > > > > > > > > > How is the traffic redirected back to Server A once=20 > > > > > > > > > > maintenance / overloading etc. has finished? My=20 > > > > > > > > > > assumption is that Server B sends a redirect to go=20 > > > > > > > > > > back to Server A as Server A has no way to say over=20 > > > > > > > > > > a now non-existent session to say > > > > > "come back". > > > > > > > > > > > > > > > > > > [Med] That's one possibility. This one does not=20 > > > > > > > > > require any update to the > > > > > > > > signal- > > > > > > > > > channel specification. > > > > > > > > > > > > > > > > > > Another approach would be to not require any redirect=20 > > > > > > > > > signal from server > > > > > > > B. > > > > > > > > > The client will remove server B's records upon the=20 > > > > > > > > > expiry of the TTL and > > > > > > > > will fall > > > > > > > > > back to the "base" DOTS servers configuration that was = > > > > > > > > > provisioned to the > > > > > > > > client > > > > > > > > > using DHCP or whatever mechanism. > > > > > > > > > [Jon] OK. The TTL is defined at, associated with the = > > > > > > > > > IP address level > > > > > > > > under alt- > > > > > > > > > server-record, not under > > > > > > > > > ietf-dots-signal-channel:redirected-signal. The ttl > > definition is > > > > > > > > > ambiguous as to what it refers to and perhaps could be = > > > > > > > > > tightened up in the language (I read it as being=20 > > > > > > > > > associated with "addr" in the sense of a DNS > > > > > > > > TTL). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Do we need to keep the existing Client to Server A=20 > > > > > > > > > > session warm (or perhaps to probe periodically) to=20 > > > > > > > > > > see if Server A is capable of handling the Client=20 > > > > > > > > > > again by a server response extension to the protocol = > > > > > > > > > > (e.g. a 3.01) > > > > > > > > > > > > > > > > > > [Med] Redirect was initially introduced to manage a=20 > > > > > > > > > server overload, so I > > > > > > > > don't > > > > > > > > > think it makes sense to probe or maintain a session=20 > > > > > > > > > with > server > > A. > > > > > > > > > [Jon] Agreed, but I needed to raise the question. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Should there be a retry period parameter added in to = > > > > > > > > > > the > > > > > > > > > > 3.00 protocol (as I read it, ttl only refers to the=20 > > > > > > > > > > IP > > address)? > > > > > > > > > > > > > > > > > > [Med] The client will automatically switch to Server A = > > > > > > > > > when all alternate > > > > > > > > records > > > > > > > > > expire. > > > > > > > > > [Jon] OK - again the 4.6 text needs to get tightened=20 > > > > > > > > > up to reflect this as > > > > > > > > the > > > > > > > > > intent. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Usability #2 > > > > > > > > > > > > > > > > > > > > Server A says "Redirect to Server B" due to = overloading. > > > > > > > > > > Server B accepts things for a while and then is=20 > > > > > > > > > > instructed/decides to redirect traffic back to A. =20 > > > > > > > > > > Server A is left still overload configured to=20 > > > > > > > > > > redirect to B. How should the client handle this as = > > > > > > > > > > there is no suitable > > > > > > > > > Server? > > > > > > > > > > > > > > > > > > [Med] This is a service configuration problem. We may = ask: > > > > > > > > > * the client to log the error and notify the administrator. > > > > > > > > > * and/or stop the redirection after n cycles. > > > > > > > > > > > > > > > > > > Still, this does not solve the problem. > > > > > > > > > [Jon] Agreed there is a problem here > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I agree that there needs to be co-ordination between = > > > > > > > > > > Server A and Server B, but user error may creep in. > > > > > > > > > > > > > > > > > > > > Usability #3 > > > > > > > > > > > > > > > > > > > > Server A says "Redirect to Server B" as it going to=20 > > > > > > > > > > be shut down because of maintenance. Server B=20 > > > > > > > > > > accepts things for a while and then is instructed=20 > > > > > > > > > > (in probable user > > > > > > > > > > error) to redirect traffic back to A (perhaps=20 > > > > > > > > > > because it has hit an overload condition). How=20 > > > > > > > > > > should the client > > > > > > > > > handle this? > > > > > > > > > > > > > > > > > > [Med] Isn't this a sub-case or #2? > > > > > > > > > [Jon] Yes, but I wanted to bring in Server A being=20 > > > > > > > > > alive and able to > > > > > > > > respond > > > > > > > > > versus Server A down and not responding due to maintenance. > > > > > > > > > [Jon] With my better understanding of TTL we still=20 > > > > > > > > > have an issue if the TTL expires and Server A is=20 > > > > > > > > > having an extended > > outage. > > > > > > > > > How do we recover from that? > > > > > > > > > ~jon > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > Dots mailing list > > > > > > > > > > Dots@ietf.org > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > Dots mailing list > > > > > > > > > Dots@ietf.org > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > Dots mailing list > > > > > > > > > Dots@ietf.org > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Dots mailing list > > > > > > > Dots@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > _______________________________________________ > > > > > Dots mailing list > > > > > Dots@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Fri Apr 6 07:21:12 2018 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 9B18C12D80F for ; Fri, 6 Apr 2018 07:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwLuPEgtJzHs for ; Fri, 6 Apr 2018 07:20:48 -0700 (PDT) Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EBC21270AC for ; Fri, 6 Apr 2018 07:20:47 -0700 (PDT) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 2BAC81C0964; Fri, 6 Apr 2018 16:20:46 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.41]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 061FA40098; Fri, 6 Apr 2018 16:20:46 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM31.corporate.adroot.infra.ftgroup ([fe80::2cc9:4bac:7b7d:229d%19]) with mapi id 14.03.0382.000; Fri, 6 Apr 2018 16:20:45 +0200 From: To: Jon Shallow , "Konda, Tirumaleswar Reddy" , "dots@ietf.org" Thread-Topic: [Dots] Signal Channel - 300 Redirected Signaling Thread-Index: AQJ5xX4UsK17va5Vv37fpNudI6+9awKIdnG+AkIt6UkCuIhgoQJj4oJpArGJQHwA3D0H4gGs0H5ZApHDVXYB/IC8TgE0bwOgAlFzC1Sh7g8xEIAADWwg///f84CAAC7RkA== Date: Fri, 6 Apr 2018 14:20:45 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DEF975C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <014f01d3cc19$2e3880e0$8aa982a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7E7B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <019901d3cc23$a93ff8e0$fbbfeaa0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8524@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <004e01d3ccb4$d505e7f0$7f11b7d0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8758@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEF912A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEF93EE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <008501d3cda6$c860d210$59227630$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF951 1@OPEXCLILMA3. corporate.adroot.infra.ftgroup> <00b001d3cdab$ba8caec0$2fa60c40$@jpshallow.com> In-Reply-To: <00b001d3cdab$ba8caec0$2fa60c40$@jpshallow.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling 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, 06 Apr 2018 14:20:54 -0000 X-List-Received-Date: Fri, 06 Apr 2018 14:20:54 -0000 FWIW, I implemented the change at: https://github.com/boucadair/draft-ietf-= dots-signal-channel/blob/master/draft-ietf-dots-signal-channel.txt=20 Cheers, Med=20 > -----Message d'origine----- > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > Envoy=E9=A0: vendredi 6 avril 2018 15:33 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; dots@ietf.o= rg > Objet=A0: RE: [Dots] Signal Channel - 300 Redirected Signaling >=20 > Excellent. >=20 > Thanks >=20 > Jon >=20 > -----Original Message----- > From: mohamed.boucadair@orange.com [mailto: mohamed.boucadair@orange.com] > Sent: 06 April 2018 14:29 > To: Jon Shallow; Konda, Tirumaleswar Reddy; rdd@cert.org > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling >=20 > Hi Jon, all, >=20 > I'm fine to put ttl at the level of alt-server. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > Envoy=E9=A0: vendredi 6 avril 2018 14:57 > > =C0=A0: BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; rdd@cert.= org > > Objet=A0: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > Hi there, > > > > See inline [Jon3] > > > > Regards > > > > Jon > > > > > > > > > -----Message d'origine----- > > > > > De=A0: Konda, Tirumaleswar Reddy > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > Envoy=E9=A0: vendredi 6 avril 2018 07:07 =C0=A0: BOUCADAIR Mohame= d > > > > > IMT/OLN; Jon Shallow; dots@ietf.org Objet=A0: RE: > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > Hi Med, > > > > > > > > > > The proposed update restricts the client no to do a DNS lookup > > > > > using the alternate FQDN, further associating a TTL with the > > > > > name complicates the functionality on the DOTS client to > > > > > re-establish (D)TLS session with the primary DOTS server after th= e > TTL expires. > > > > > My suggestion is to let the DOTS client continue to use the > > > > > alternate DOTS > > > server > > > > till it gets re-directed. > > > > > > > > [Med] This is possible with the current spec. > > > > > > > > Triggers for redirect and for falling back to the nominal > > > > configuration are deployment-specific. The current spec allows for > > > > almost all the cases > > > discussed > > > > so far: > > > > > > > > (1) Redirect for the request in progress: A server does so by > > > > returning > > > TTL=3D0. > > > > (2) The alternate server is not involved in fall back to the > > > > nominal > > > server: upon > > > > expiry of ttl of all alternate IP addresses, then fall back > > > > automatically > > > to the > > > > nominal server. > > > > (3) Redirect to an alternate server, which in turn will instruct > > > > the client > > > to > > > > redirect to the "base" configuration: a TTL is provided and the > > > > alternate > > > server > > > > can reply with a redirect code any time before the expiry of the > > > > TTL. A > > > long TTL > > > > can be returned if the alternate server will be responsible for > > > coordinating fall > > > > back to the base server. > > > > (4) Stop infinite redirects > > > > > > Yes, but (1) and (2) complicate the functionality of the DOTS client. > > > > [Med] (1) and (2) is exactly the same functionality required for > > caching DNS replies. > > > > The > > > only reason for adding alt-server-record in the response is DNS > > > server may not be reachable by the DOTS server because of a DDoS atta= ck. > > > > > > > [Med] Yes. Note that even if the name resolution was allowed, the > > client has to deal with the TTL indicated in the response...which is > > exactly the same as (1) and (2). > > > > > > [Jon3] I think where I am struggling here is the overloaded use of TTL > > - The TTL as per a DNS record and held as a part of alt-server-record > > and then the TTL after which that the alt-server should be handling > > the traffic before handling back to the original primary server. It > > either has to be one or the other, or they have to have different names= . > > [Jon3] If we are only going to go for one variant for simplicity, then > > I would prefer that it should be at the level of "alt-server". > > Handling the TTL for DNS refresh is normally handled by a resolver > > library, updated by the DNS packets coming in - unusual for an applicat= ion > to have to do that. > > > > > > > > > > > > > > I > > > > > don't think the DOTS mitigation provider will know ahead-of-time > > > > > the TTL value after which the DOTS client should disconnect > > > > > communicating with the alternate DOTS server and re-establish > > > > > (D)TLS session with the primary DOTS server. > > > > > > > > [Med] It depends on the nature of the redirect: overload, planned > > > maintenance, > > > > etc. For planned maintenance, the TTL is known in general. > > > > > > It's the primary DOTS server responsibility to point the DOTS client > > > to an optimal alternate server, where the client can continue to > > > send migration requests without a frequent ping-pong between servers. > > > > [Med] Agree. This is a service configuration problem. > > [Jon3] Agreed - and the 5 minute minimum ping-pong time is a good > > safety net. > > ~jon3 > > > > > I have seen TURN servers being deployed for several years with > > re-direction > > > but without the need for TTL (see ALTERNATE-SERVER in > > > https://tools.ietf.org/html/draft-ietf-tram-turnbis-11) > > > > > > -Tiru > > > > > > > > > > > > > > > > > Cheers, > > > > > -Tiru > > > > > > > > > > > -----Original Message----- > > > > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of > > > > > > mohamed.boucadair@orange.com > > > > > > Sent: Thursday, April 5, 2018 4:50 PM > > > > > > To: Konda, Tirumaleswar Reddy > > > > > > ; > > > > > > Jon Shallow ; dots@ietf.org > > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > Tiru, > > > > > > > > > > > > I don't see the NEW text as a restriction but as a > > > > > > simplification of the > > > > > client's > > > > > > behavior. I don't want to over-specify the redirect behavior. > > > > > > > > > > > > Adding another yet layer of resolution will raise other issues > > > > > > such as the > > > > > need to > > > > > > associate a TTL with the name itself. > > > > > > > > > > > > Cheers, > > > > > > Med > > > > > > > > > > > > > -----Message d'origine----- > > > > > > > De=A0: Konda, Tirumaleswar Reddy > > > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > > Envoy=E9=A0: jeudi 5 avril 2018 12:06 =C0=A0: Jon Shallow; BO= UCADAIR > > > > > > > Mohamed IMT/OLN; dots@ietf.org Objet=A0: > > RE: > > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > > > > > Sent: Thursday, April 5, 2018 1:35 PM > > > > > > > > To: mohamed.boucadair@orange.com; Konda, Tirumaleswar > > > > > > > > Reddy ; dots@ietf.org > > > > > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected > > > > > > > > Signaling > > > > > > > > > > > > > > > > Hi Med, > > > > > > > > > > > > > > > > Thanks for this refresh to 4.6 Redirected Signaling > > > > > > > > > > > > > > > > Some comments > > > > > > > > > > > > > > > > #1 > > > > > > > > > > > > > > > > The DOTS server can return the error response code 3.00 > > > > > > > > in > > > response > > > > > > > > to a PUT request from the DOTS client or convey the > > > > > > > > error > > > response > > > > > > > > code 3.00 in a unidirectional notification response > > > > > > > > from the > > > DOTS > > > > > > > > server. > > > > > > > > > > > > > > > > Why is this limited to a PUT request and/or unidirectional > > > > > > > > notification > > > > > > > response? > > > > > > > > - Surely, any response, unsolicited or otherwise can > > > > > > > > contain a > > > > > > > > 3.00 > > > > > > > > - If Observe is not in use, then any unsolicited > > > > > > > > notification response will potentially get rejected by the > > > > > > > > coap library layer, so a DOTS Server cannot > > > > > > > signal > > > > > > > > maintenance outage other than by closing the session. > > > > > > > > - I missed this the last review - sorry > > > > > > > > > > > > > > > > > > > > > > > #2 > > > > > > > > > > > > > > > > If the DOTS client has been redirected to a DOTS server > > > > > > > > to > > which > > > it > > > > > > > > has already sent the mitigation request within the last > > > > > > > > five > > (5) > > > > > > > > minutes, it MUST ignore the redirection and try to > > > > > > > > contact other DOTS > > > > > > > > > > > > > > > > s/ has already sent the mitigation request/ has already > > > > > > > > communicated with/ > > > > > > > > > > > > > > > > #3 > > > > > > > > > > > > > > > > A DOTS client MUST NOT use an alternate IP address > > > > > > > > to > > contact > > > its > > > > > > > > DOTS server upon expiry of the associated TTL. > > > > > > > > > > > > > > > > To remove ambiguity over the use of FQDN, this could read > > > > > > > > > > > > > > > > A DOTS client MUST NOT use an alternate IP address > > > > > > > > to > > contact > > > its > > > > > > > > DOTS server upon expiry of the associated TTL. > > > > > > > > Furthermore, a > > > > > DOTS > > > > > > > > Client MUST NOT use the alt-server FQDN if all of > > > > > > > > the > > > > > > > > alt-server- > > > > > > > records > > > > > > > > have expired. > > > > > > > > > > > > > > > > Or alternatively > > > > > > > > > > > > > > > > alt-server: FQDN of an alternate DOTS server. > > > > > > > > > > > > > > > > This could read > > > > > > > > > > > > > > > > alt-server: FQDN of an alternate DOTS server. This > > > > > > > > FQDN is not to be > > > > > > > used for > > > > > > > > looking up IP addresses to use, but is there for the SNI > > > > > > > > extension > > > > > (7.1. > > > > > > > (D)TLS > > > > > > > > Protocol Profile) > > > > > > > > > > > > > > I don't think the above restriction is correct for the > > > > > > > following > > > reasons: > > > > > > > > > > > > > > 1) If the TTL value in the alt-server-record expires, DNS > > > > > > > lookup can be performed by the DOTS client using the > > > > > > > alternate DOTS > > server > > > FQDN. > > > > > > > 2) If the DNS server is reachable, the client may want to a > > > > > > > DANE lookup to get the IP addresses and certificate to > > > > > > > validate the alternate DOTS server certificate sent > > > > > > > in the DTLS handshake. > > > > > > > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > Jon > > > > > > > > -----Original Message----- > > > > > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > > > > > > > mohamed.boucadair@orange.com > > > > > > > > Sent: 05 April 2018 08:20 > > > > > > > > To: Konda, Tirumaleswar Reddy; Jon Shallow; dots@ietf.org > > > > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected > > > > > > > > Signaling > > > > > > > > > > > > > > > > Hi Tiru, > > > > > > > > > > > > > > > > Works for me. > > > > > > > > > > > > > > > > I updated the draft with the text additions that were > > > > > > > > discussed in this thread. The changes can be found at: > > > > > > > > https://github.com/boucadair/draft-ietf-dots-signal- > > > > > > > channel/blob/master/draf > > > > > > > > t-ietf-dots-signal-channel.txt > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Med > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Konda, Tirumaleswar > > > > > > > > > Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > > > > Envoy=E9=A0: mercredi 4 avril 2018 17:40 =C0=A0: Jon Shal= low; > > > > > > > > > BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet=A0: RE: > > > > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > > > > The TTL value returned under alt-server-record is > > > > > > > > > equivalent to the DNS TTL value. A DDoS mitigation > > > > > > > > > provider with multiple DOTS servers typically re-directs > > > > > > > > > a DOTS client to a different DOTS server only if the > > > > > > > > > alternate DOTS server has the capacity to handle the > > > > > > > > > requests from the > > > > > > > > DOTS client. > > > > > > > > > > > > > > > > > > We can add the following lines to avoid loops : > > > > > > > > > > > > > > > > > > If the DOTS client has been redirected to a DOTS server > > > > > > > > > to which it has already sent the mitigation request > > > > > > > > > within the last five minutes, it MUST ignore the > > > > > > > > > redirection and try reaching others servers listed in > > > > > > > > > the local configuration or discovered using dynamic means > such as DHCP or SRV procedures. > > > > > > > > > This prevents infinite ping-ponging between servers in > > > > > > > > > case of redirection loops. > > > > > > > > > > > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of > > > > > > > > > > Jon Shallow > > > > > > > > > > Sent: Wednesday, April 4, 2018 8:16 PM > > > > > > > > > > To: mohamed.boucadair@orange.com; dots@ietf.org > > > > > > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected > > > > > > > > > > Signaling > > > > > > > > > > > > > > > > > > > > Hi there, > > > > > > > > > > > > > > > > > > > > See inline [Jon] > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf > > > > > > > > > > Of mohamed.boucadair@orange.com > > > > > > > > > > Sent: 04 April 2018 15:07 > > > > > > > > > > To: Jon Shallow; dots@ietf.org > > > > > > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected > > > > > > > > > > Signaling > > > > > > > > > > > > > > > > > > > > Re-, > > > > > > > > > > > > > > > > > > > > Please see inline. > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > Med > > > > > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Dots > > > > > > > > > > > [mailto:dots-bounces@ietf.org] De la part de Jon > > > > > > > > > > > Shallow Envoy=E9=A0: mercredi 4 avril 2018 15:31 =C0= =A0: > > > > > > > > > > > dots@ietf.org > > > > > Objet=A0: > > > > > > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > Hi there, > > > > > > > > > > > > > > > > > > > > > > I have implemented the 300 Redirected-Signal in my > > > > > > > > > > > DOTS > > code. > > > > > > > > > > > This then raises some questions about usability. > > > > > > > > > > > > > > > > > > > > > > Usability #1 > > > > > > > > > > > > > > > > > > > > > > Architecture 3.2.2 Redirected Signalling > > > > > > > > > > > > > > > > > > > > > > 4. Having redirected the DOTS client, DOTS > > > > > > > > > > > server A ceases > > > > > > > sending > > > > > > > > > > > server signals. The DOTS client likewise > > > > > > > > > > > stops sending > > > > > client > > > > > > > > > > > signals to DOTS server A. DOTS session 1 is > > > terminated. > > > > > > > > > > > > > > > > > > > > > > Clearly indicates that the original session (Client > > > > > > > > > > > to Server > > > > > > > > > > > A) is no more once redirected and only Client to > > > > > > > > > > > Server B is in > > > > > use. > > > > > > > > > > > > > > > > > > > > > > How is the traffic redirected back to Server A once > > > > > > > > > > > maintenance / overloading etc. has finished? My > > > > > > > > > > > assumption is that Server B sends a redirect to go > > > > > > > > > > > back to Server A as Server A has no way to say over > > > > > > > > > > > a now non-existent session to say > > > > > > "come back". > > > > > > > > > > > > > > > > > > > > [Med] That's one possibility. This one does not > > > > > > > > > > require any update to the > > > > > > > > > signal- > > > > > > > > > > channel specification. > > > > > > > > > > > > > > > > > > > > Another approach would be to not require any redirect > > > > > > > > > > signal from server > > > > > > > > B. > > > > > > > > > > The client will remove server B's records upon the > > > > > > > > > > expiry of the TTL and > > > > > > > > > will fall > > > > > > > > > > back to the "base" DOTS servers configuration that was > > > > > > > > > > provisioned to the > > > > > > > > > client > > > > > > > > > > using DHCP or whatever mechanism. > > > > > > > > > > [Jon] OK. The TTL is defined at, associated with the > > > > > > > > > > IP address level > > > > > > > > > under alt- > > > > > > > > > > server-record, not under > > > > > > > > > > ietf-dots-signal-channel:redirected-signal. The ttl > > > definition is > > > > > > > > > > ambiguous as to what it refers to and perhaps could be > > > > > > > > > > tightened up in the language (I read it as being > > > > > > > > > > associated with "addr" in the sense of a DNS > > > > > > > > > TTL). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Do we need to keep the existing Client to Server A > > > > > > > > > > > session warm (or perhaps to probe periodically) to > > > > > > > > > > > see if Server A is capable of handling the Client > > > > > > > > > > > again by a server response extension to the protocol > > > > > > > > > > > (e.g. a 3.01) > > > > > > > > > > > > > > > > > > > > [Med] Redirect was initially introduced to manage a > > > > > > > > > > server overload, so I > > > > > > > > > don't > > > > > > > > > > think it makes sense to probe or maintain a session > > > > > > > > > > with > > server > > > A. > > > > > > > > > > [Jon] Agreed, but I needed to raise the question. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Should there be a retry period parameter added in to > > > > > > > > > > > the > > > > > > > > > > > 3.00 protocol (as I read it, ttl only refers to the > > > > > > > > > > > IP > > > address)? > > > > > > > > > > > > > > > > > > > > [Med] The client will automatically switch to Server A > > > > > > > > > > when all alternate > > > > > > > > > records > > > > > > > > > > expire. > > > > > > > > > > [Jon] OK - again the 4.6 text needs to get tightened > > > > > > > > > > up to reflect this as > > > > > > > > > the > > > > > > > > > > intent. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Usability #2 > > > > > > > > > > > > > > > > > > > > > > Server A says "Redirect to Server B" due to overloadi= ng. > > > > > > > > > > > Server B accepts things for a while and then is > > > > > > > > > > > instructed/decides to redirect traffic back to A. > > > > > > > > > > > Server A is left still overload configured to > > > > > > > > > > > redirect to B. How should the client handle this as > > > > > > > > > > > there is no suitable > > > > > > > > > > Server? > > > > > > > > > > > > > > > > > > > > [Med] This is a service configuration problem. We may a= sk: > > > > > > > > > > * the client to log the error and notify the > administrator. > > > > > > > > > > * and/or stop the redirection after n cycles. > > > > > > > > > > > > > > > > > > > > Still, this does not solve the problem. > > > > > > > > > > [Jon] Agreed there is a problem here > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I agree that there needs to be co-ordination between > > > > > > > > > > > Server A and Server B, but user error may creep in. > > > > > > > > > > > > > > > > > > > > > > Usability #3 > > > > > > > > > > > > > > > > > > > > > > Server A says "Redirect to Server B" as it going to > > > > > > > > > > > be shut down because of maintenance. Server B > > > > > > > > > > > accepts things for a while and then is instructed > > > > > > > > > > > (in probable user > > > > > > > > > > > error) to redirect traffic back to A (perhaps > > > > > > > > > > > because it has hit an overload condition). How > > > > > > > > > > > should the client > > > > > > > > > > handle this? > > > > > > > > > > > > > > > > > > > > [Med] Isn't this a sub-case or #2? > > > > > > > > > > [Jon] Yes, but I wanted to bring in Server A being > > > > > > > > > > alive and able to > > > > > > > > > respond > > > > > > > > > > versus Server A down and not responding due to > maintenance. > > > > > > > > > > [Jon] With my better understanding of TTL we still > > > > > > > > > > have an issue if the TTL expires and Server A is > > > > > > > > > > having an extended > > > outage. > > > > > > > > > > How do we recover from that? > > > > > > > > > > ~jon > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > Dots mailing list > > > > > > > > > > > Dots@ietf.org > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > Dots mailing list > > > > > > > > > > Dots@ietf.org > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > Dots mailing list > > > > > > > > > > Dots@ietf.org > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Dots mailing list > > > > > > > > Dots@ietf.org > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > _______________________________________________ > > > > > > Dots mailing list > > > > > > Dots@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots >=20 From nobody Fri Apr 6 07:36:14 2018 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 0FD851270AC for ; Fri, 6 Apr 2018 07:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HlfXugl-j0aM for ; Fri, 6 Apr 2018 07:36:08 -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 DA7DF120726 for ; Fri, 6 Apr 2018 07:36:07 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.90_1) (envelope-from ) id 1f4STG-0001RB-32; Fri, 06 Apr 2018 15:36:06 +0100 From: "Jon Shallow" To: , "Konda, Tirumaleswar Reddy" , References: <014f01d3cc19$2e3880e0$8aa982a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7E7B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <019901d3cc23$a93ff8e0$fbbfeaa0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8524@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <004e01d3ccb4$d505e7f0$7f11b7d0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8758@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEF912A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEF93EE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <008501d3cda6$c860d210$59227630$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF951 1@OPEXCLILMA3 . corporate.adroot.infra.ftgroup> <00b001d3cdab$ba8caec0$2fa60c40$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF975C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DEF975C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Fri, 6 Apr 2018 15:36:05 +0100 Message-ID: <00b801d3cdb4$982dc4a0$c8894de0$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ5xX4UsK17va5Vv37fpNudI6+9awKIdnG+AkIt6UkCuIhgoQJj4oJpArGJQHwA3D0H4gGs0H5ZApHDVXYB/IC8TgE0bwOgAlFzC1QBmQ12ZgEwaI7ZAa02vLICgeu4wKG2aUHQ Content-Language: en-gb Archived-At: Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling 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, 06 Apr 2018 14:36:12 -0000 Hi Med, Thanks for this. I would like to see the ttl: definition tightened up (moved away from the DNS TTL version) Old ttl: Time to live (TTL) of alternate records, represented as an integer number of seconds. That is, the time interval that alternate IP addresses may be cached by a DOTS client. '0' means that an alternate IP address is only to be used for the request in progress, and consequently that IP address should not be cached. If no 'ttl' is returned in a redirect response, this is equivalent to returning a 'ttl' parameter set to '0'. If 'alt-server-record' has expired, the DOTS client MUST use the DOTS server(s) that was provisioned using means discussed in Section 4.1. Furthermore, a DOTS client MUST NOT use the alt- server FQDN if the 'alt-server-records' has expired. New ttl: Time to live (TTL) of the alternate DOTS server, represented as = an integer number of seconds. That is, the time interval that the alternate DOTS server may be cached for use by a DOTS client. '0' means that the alternate DOTS server is only to be used for = the request in progress, and consequently the alternate DOTS server = entry should not be cached. If no 'ttl' is returned in a redirect response, this is equivalent to returning a 'ttl' parameter set to '0'. If the alternate DOTS server TTL has expired, the DOTS client MUST = use the DOTS server(s) that was provisioned using means discussed in Section 4.1. =20 Regards Jon -----Original Message----- From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 06 April 2018 15:21 To: Jon Shallow; Konda, Tirumaleswar Reddy; dots@ietf.org Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling FWIW, I implemented the change at: https://github.com/boucadair/draft-ietf-dots-signal-channel/blob/master/d= raf t-ietf-dots-signal-channel.txt=20 Cheers, Med=20 > -----Message d'origine----- > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > Envoy=E9=A0: vendredi 6 avril 2018 15:33 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy;=20 > dots@ietf.org Objet=A0: RE: [Dots] Signal Channel - 300 Redirected=20 > Signaling >=20 > Excellent. >=20 > Thanks >=20 > Jon >=20 > -----Original Message----- > From: mohamed.boucadair@orange.com [mailto:=20 > mohamed.boucadair@orange.com] > Sent: 06 April 2018 14:29 > To: Jon Shallow; Konda, Tirumaleswar Reddy; rdd@cert.org > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling >=20 > Hi Jon, all, >=20 > I'm fine to put ttl at the level of alt-server. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > Envoy=E9=A0: vendredi 6 avril 2018 14:57 =C0=A0: BOUCADAIR Mohamed = IMT/OLN;=20 > > Konda, Tirumaleswar Reddy; rdd@cert.org Objet=A0: RE: [Dots] Signal=20 > > Channel - 300 Redirected Signaling > > > > Hi there, > > > > See inline [Jon3] > > > > Regards > > > > Jon > > > > > > > > > -----Message d'origine----- > > > > > De=A0: Konda, Tirumaleswar Reddy=20 > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > Envoy=E9=A0: vendredi 6 avril 2018 07:07 =C0=A0: BOUCADAIR = Mohamed=20 > > > > > IMT/OLN; Jon Shallow; dots@ietf.org Objet=A0: RE: > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > Hi Med, > > > > > > > > > > The proposed update restricts the client no to do a DNS lookup = > > > > > using the alternate FQDN, further associating a TTL with the=20 > > > > > name complicates the functionality on the DOTS client to=20 > > > > > re-establish (D)TLS session with the primary DOTS server after = > > > > > the > TTL expires. > > > > > My suggestion is to let the DOTS client continue to use the=20 > > > > > alternate DOTS > > > server > > > > till it gets re-directed. > > > > > > > > [Med] This is possible with the current spec. > > > > > > > > Triggers for redirect and for falling back to the nominal=20 > > > > configuration are deployment-specific. The current spec allows=20 > > > > for almost all the cases > > > discussed > > > > so far: > > > > > > > > (1) Redirect for the request in progress: A server does so by=20 > > > > returning > > > TTL=3D0. > > > > (2) The alternate server is not involved in fall back to the=20 > > > > nominal > > > server: upon > > > > expiry of ttl of all alternate IP addresses, then fall back=20 > > > > automatically > > > to the > > > > nominal server. > > > > (3) Redirect to an alternate server, which in turn will instruct = > > > > the client > > > to > > > > redirect to the "base" configuration: a TTL is provided and the = > > > > alternate > > > server > > > > can reply with a redirect code any time before the expiry of the = > > > > TTL. A > > > long TTL > > > > can be returned if the alternate server will be responsible for > > > coordinating fall > > > > back to the base server. > > > > (4) Stop infinite redirects > > > > > > Yes, but (1) and (2) complicate the functionality of the DOTS = client. > > > > [Med] (1) and (2) is exactly the same functionality required for=20 > > caching DNS replies. > > > > The > > > only reason for adding alt-server-record in the response is DNS=20 > > > server may not be reachable by the DOTS server because of a DDoS attack. > > > > > > > [Med] Yes. Note that even if the name resolution was allowed, the=20 > > client has to deal with the TTL indicated in the response...which is = > > exactly the same as (1) and (2). > > > > > > [Jon3] I think where I am struggling here is the overloaded use of=20 > > TTL > > - The TTL as per a DNS record and held as a part of=20 > > alt-server-record and then the TTL after which that the alt-server=20 > > should be handling the traffic before handling back to the original=20 > > primary server. It either has to be one or the other, or they have = to have different names. > > [Jon3] If we are only going to go for one variant for simplicity,=20 > > then I would prefer that it should be at the level of "alt-server". > > Handling the TTL for DNS refresh is normally handled by a resolver=20 > > library, updated by the DNS packets coming in - unusual for an=20 > > application > to have to do that. > > > > > > > > > > > > > > I > > > > > don't think the DOTS mitigation provider will know=20 > > > > > ahead-of-time the TTL value after which the DOTS client should = > > > > > disconnect communicating with the alternate DOTS server and=20 > > > > > re-establish (D)TLS session with the primary DOTS server. > > > > > > > > [Med] It depends on the nature of the redirect: overload,=20 > > > > planned > > > maintenance, > > > > etc. For planned maintenance, the TTL is known in general. > > > > > > It's the primary DOTS server responsibility to point the DOTS=20 > > > client to an optimal alternate server, where the client can=20 > > > continue to send migration requests without a frequent ping-pong between servers. > > > > [Med] Agree. This is a service configuration problem. > > [Jon3] Agreed - and the 5 minute minimum ping-pong time is a good=20 > > safety net. > > ~jon3 > > > > > I have seen TURN servers being deployed for several years with > > re-direction > > > but without the need for TTL (see ALTERNATE-SERVER in > > > https://tools.ietf.org/html/draft-ietf-tram-turnbis-11) > > > > > > -Tiru > > > > > > > > > > > > > > > > > Cheers, > > > > > -Tiru > > > > > > > > > > > -----Original Message----- > > > > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of=20 > > > > > > mohamed.boucadair@orange.com > > > > > > Sent: Thursday, April 5, 2018 4:50 PM > > > > > > To: Konda, Tirumaleswar Reddy=20 > > > > > > ; > > > > > > Jon Shallow ; dots@ietf.org > > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected=20 > > > > > > Signaling > > > > > > > > > > > > Tiru, > > > > > > > > > > > > I don't see the NEW text as a restriction but as a=20 > > > > > > simplification of the > > > > > client's > > > > > > behavior. I don't want to over-specify the redirect = behavior. > > > > > > > > > > > > Adding another yet layer of resolution will raise other=20 > > > > > > issues such as the > > > > > need to > > > > > > associate a TTL with the name itself. > > > > > > > > > > > > Cheers, > > > > > > Med > > > > > > > > > > > > > -----Message d'origine----- De=A0: Konda, Tirumaleswar = Reddy=20 > > > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > > Envoy=E9=A0: jeudi 5 avril 2018 12:06 =C0=A0: Jon Shallow; = > > > > > > > BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet=A0: > > RE: > > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > > > > > Sent: Thursday, April 5, 2018 1:35 PM > > > > > > > > To: mohamed.boucadair@orange.com; Konda, Tirumaleswar=20 > > > > > > > > Reddy ;=20 > > > > > > > > dots@ietf.org > > > > > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected=20 > > > > > > > > Signaling > > > > > > > > > > > > > > > > Hi Med, > > > > > > > > > > > > > > > > Thanks for this refresh to 4.6 Redirected Signaling > > > > > > > > > > > > > > > > Some comments > > > > > > > > > > > > > > > > #1 > > > > > > > > > > > > > > > > The DOTS server can return the error response code=20 > > > > > > > > 3.00 in > > > response > > > > > > > > to a PUT request from the DOTS client or convey the=20 > > > > > > > > error > > > response > > > > > > > > code 3.00 in a unidirectional notification response=20 > > > > > > > > from the > > > DOTS > > > > > > > > server. > > > > > > > > > > > > > > > > Why is this limited to a PUT request and/or=20 > > > > > > > > unidirectional notification > > > > > > > response? > > > > > > > > - Surely, any response, unsolicited or otherwise can=20 > > > > > > > > contain a > > > > > > > > 3.00 > > > > > > > > - If Observe is not in use, then any unsolicited=20 > > > > > > > > notification response will potentially get rejected by=20 > > > > > > > > the coap library layer, so a DOTS Server cannot > > > > > > > signal > > > > > > > > maintenance outage other than by closing the session. > > > > > > > > - I missed this the last review - sorry > > > > > > > > > > > > > > > > > > > > > > > #2 > > > > > > > > > > > > > > > > If the DOTS client has been redirected to a DOTS=20 > > > > > > > > server to > > which > > > it > > > > > > > > has already sent the mitigation request within the=20 > > > > > > > > last five > > (5) > > > > > > > > minutes, it MUST ignore the redirection and try to=20 > > > > > > > > contact other DOTS > > > > > > > > > > > > > > > > s/ has already sent the mitigation request/ has already=20 > > > > > > > > communicated with/ > > > > > > > > > > > > > > > > #3 > > > > > > > > > > > > > > > > A DOTS client MUST NOT use an alternate IP address = > > > > > > > > to > > contact > > > its > > > > > > > > DOTS server upon expiry of the associated TTL. > > > > > > > > > > > > > > > > To remove ambiguity over the use of FQDN, this could=20 > > > > > > > > read > > > > > > > > > > > > > > > > A DOTS client MUST NOT use an alternate IP address = > > > > > > > > to > > contact > > > its > > > > > > > > DOTS server upon expiry of the associated TTL. > > > > > > > > Furthermore, a > > > > > DOTS > > > > > > > > Client MUST NOT use the alt-server FQDN if all of=20 > > > > > > > > the > > > > > > > > alt-server- > > > > > > > records > > > > > > > > have expired. > > > > > > > > > > > > > > > > Or alternatively > > > > > > > > > > > > > > > > alt-server: FQDN of an alternate DOTS server. > > > > > > > > > > > > > > > > This could read > > > > > > > > > > > > > > > > alt-server: FQDN of an alternate DOTS server. This=20 > > > > > > > > FQDN is not to be > > > > > > > used for > > > > > > > > looking up IP addresses to use, but is there for the SNI = > > > > > > > > extension > > > > > (7.1. > > > > > > > (D)TLS > > > > > > > > Protocol Profile) > > > > > > > > > > > > > > I don't think the above restriction is correct for the=20 > > > > > > > following > > > reasons: > > > > > > > > > > > > > > 1) If the TTL value in the alt-server-record expires, DNS=20 > > > > > > > lookup can be performed by the DOTS client using the=20 > > > > > > > alternate DOTS > > server > > > FQDN. > > > > > > > 2) If the DNS server is reachable, the client may want to=20 > > > > > > > a DANE lookup to get the IP addresses and certificate to=20 > > > > > > > validate the alternate DOTS server certificate sent > > > > > > > in the DTLS handshake. > > > > > > > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > Jon > > > > > > > > -----Original Message----- > > > > > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of=20 > > > > > > > > mohamed.boucadair@orange.com > > > > > > > > Sent: 05 April 2018 08:20 > > > > > > > > To: Konda, Tirumaleswar Reddy; Jon Shallow;=20 > > > > > > > > dots@ietf.org > > > > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected=20 > > > > > > > > Signaling > > > > > > > > > > > > > > > > Hi Tiru, > > > > > > > > > > > > > > > > Works for me. > > > > > > > > > > > > > > > > I updated the draft with the text additions that were=20 > > > > > > > > discussed in this thread. The changes can be found at: > > > > > > > > https://github.com/boucadair/draft-ietf-dots-signal- > > > > > > > channel/blob/master/draf > > > > > > > > t-ietf-dots-signal-channel.txt > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Med > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Konda, Tirumaleswar = > > > > > > > > > Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > > > > Envoy=E9=A0: mercredi 4 avril 2018 17:40 =C0=A0: Jon = Shallow;=20 > > > > > > > > > BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet=A0: RE: > > > > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > > > > The TTL value returned under alt-server-record is=20 > > > > > > > > > equivalent to the DNS TTL value. A DDoS mitigation=20 > > > > > > > > > provider with multiple DOTS servers typically=20 > > > > > > > > > re-directs a DOTS client to a different DOTS server=20 > > > > > > > > > only if the alternate DOTS server has the capacity to=20 > > > > > > > > > handle the requests from the > > > > > > > > DOTS client. > > > > > > > > > > > > > > > > > > We can add the following lines to avoid loops : > > > > > > > > > > > > > > > > > > If the DOTS client has been redirected to a DOTS=20 > > > > > > > > > server to which it has already sent the mitigation=20 > > > > > > > > > request within the last five minutes, it MUST ignore=20 > > > > > > > > > the redirection and try reaching others servers listed = > > > > > > > > > in the local configuration or discovered using dynamic = > > > > > > > > > means > such as DHCP or SRV procedures. > > > > > > > > > This prevents infinite ping-ponging between servers in = > > > > > > > > > case of redirection loops. > > > > > > > > > > > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf=20 > > > > > > > > > > Of Jon Shallow > > > > > > > > > > Sent: Wednesday, April 4, 2018 8:16 PM > > > > > > > > > > To: mohamed.boucadair@orange.com; dots@ietf.org > > > > > > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected=20 > > > > > > > > > > Signaling > > > > > > > > > > > > > > > > > > > > Hi there, > > > > > > > > > > > > > > > > > > > > See inline [Jon] > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf = > > > > > > > > > > Of mohamed.boucadair@orange.com > > > > > > > > > > Sent: 04 April 2018 15:07 > > > > > > > > > > To: Jon Shallow; dots@ietf.org > > > > > > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected=20 > > > > > > > > > > Signaling > > > > > > > > > > > > > > > > > > > > Re-, > > > > > > > > > > > > > > > > > > > > Please see inline. > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > Med > > > > > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Dots=20 > > > > > > > > > > > [mailto:dots-bounces@ietf.org] De la part de Jon=20 > > > > > > > > > > > Shallow Envoy=E9=A0: mercredi 4 avril 2018 15:31 = =C0=A0: > > > > > > > > > > > dots@ietf.org > > > > > Objet=A0: > > > > > > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > Hi there, > > > > > > > > > > > > > > > > > > > > > > I have implemented the 300 Redirected-Signal in my = > > > > > > > > > > > DOTS > > code. > > > > > > > > > > > This then raises some questions about usability. > > > > > > > > > > > > > > > > > > > > > > Usability #1 > > > > > > > > > > > > > > > > > > > > > > Architecture 3.2.2 Redirected Signalling > > > > > > > > > > > > > > > > > > > > > > 4. Having redirected the DOTS client, DOTS=20 > > > > > > > > > > > server A ceases > > > > > > > sending > > > > > > > > > > > server signals. The DOTS client likewise=20 > > > > > > > > > > > stops sending > > > > > client > > > > > > > > > > > signals to DOTS server A. DOTS session 1=20 > > > > > > > > > > > is > > > terminated. > > > > > > > > > > > > > > > > > > > > > > Clearly indicates that the original session=20 > > > > > > > > > > > (Client to Server > > > > > > > > > > > A) is no more once redirected and only Client to=20 > > > > > > > > > > > Server B is in > > > > > use. > > > > > > > > > > > > > > > > > > > > > > How is the traffic redirected back to Server A=20 > > > > > > > > > > > once maintenance / overloading etc. has finished? = > > > > > > > > > > > My assumption is that Server B sends a redirect to = > > > > > > > > > > > go back to Server A as Server A has no way to say=20 > > > > > > > > > > > over a now non-existent session to say > > > > > > "come back". > > > > > > > > > > > > > > > > > > > > [Med] That's one possibility. This one does not=20 > > > > > > > > > > require any update to the > > > > > > > > > signal- > > > > > > > > > > channel specification. > > > > > > > > > > > > > > > > > > > > Another approach would be to not require any=20 > > > > > > > > > > redirect signal from server > > > > > > > > B. > > > > > > > > > > The client will remove server B's records upon the=20 > > > > > > > > > > expiry of the TTL and > > > > > > > > > will fall > > > > > > > > > > back to the "base" DOTS servers configuration that=20 > > > > > > > > > > was provisioned to the > > > > > > > > > client > > > > > > > > > > using DHCP or whatever mechanism. > > > > > > > > > > [Jon] OK. The TTL is defined at, associated with=20 > > > > > > > > > > the IP address level > > > > > > > > > under alt- > > > > > > > > > > server-record, not under > > > > > > > > > > ietf-dots-signal-channel:redirected-signal. The = ttl > > > definition is > > > > > > > > > > ambiguous as to what it refers to and perhaps could=20 > > > > > > > > > > be tightened up in the language (I read it as being=20 > > > > > > > > > > associated with "addr" in the sense of a DNS > > > > > > > > > TTL). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Do we need to keep the existing Client to Server A = > > > > > > > > > > > session warm (or perhaps to probe periodically) to = > > > > > > > > > > > see if Server A is capable of handling the Client=20 > > > > > > > > > > > again by a server response extension to the=20 > > > > > > > > > > > protocol (e.g. a 3.01) > > > > > > > > > > > > > > > > > > > > [Med] Redirect was initially introduced to manage a=20 > > > > > > > > > > server overload, so I > > > > > > > > > don't > > > > > > > > > > think it makes sense to probe or maintain a session=20 > > > > > > > > > > with > > server > > > A. > > > > > > > > > > [Jon] Agreed, but I needed to raise the question. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Should there be a retry period parameter added in=20 > > > > > > > > > > > to the > > > > > > > > > > > 3.00 protocol (as I read it, ttl only refers to=20 > > > > > > > > > > > the IP > > > address)? > > > > > > > > > > > > > > > > > > > > [Med] The client will automatically switch to Server = > > > > > > > > > > A when all alternate > > > > > > > > > records > > > > > > > > > > expire. > > > > > > > > > > [Jon] OK - again the 4.6 text needs to get tightened = > > > > > > > > > > up to reflect this as > > > > > > > > > the > > > > > > > > > > intent. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Usability #2 > > > > > > > > > > > > > > > > > > > > > > Server A says "Redirect to Server B" due to overloading. > > > > > > > > > > > Server B accepts things for a while and then is=20 > > > > > > > > > > > instructed/decides to redirect traffic back to A. > > > > > > > > > > > Server A is left still overload configured to=20 > > > > > > > > > > > redirect to B. How should the client handle this=20 > > > > > > > > > > > as there is no suitable > > > > > > > > > > Server? > > > > > > > > > > > > > > > > > > > > [Med] This is a service configuration problem. We = may ask: > > > > > > > > > > * the client to log the error and notify the > administrator. > > > > > > > > > > * and/or stop the redirection after n cycles. > > > > > > > > > > > > > > > > > > > > Still, this does not solve the problem. > > > > > > > > > > [Jon] Agreed there is a problem here > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I agree that there needs to be co-ordination=20 > > > > > > > > > > > between Server A and Server B, but user error may creep in. > > > > > > > > > > > > > > > > > > > > > > Usability #3 > > > > > > > > > > > > > > > > > > > > > > Server A says "Redirect to Server B" as it going=20 > > > > > > > > > > > to be shut down because of maintenance. Server B=20 > > > > > > > > > > > accepts things for a while and then is instructed=20 > > > > > > > > > > > (in probable user > > > > > > > > > > > error) to redirect traffic back to A (perhaps=20 > > > > > > > > > > > because it has hit an overload condition). How=20 > > > > > > > > > > > should the client > > > > > > > > > > handle this? > > > > > > > > > > > > > > > > > > > > [Med] Isn't this a sub-case or #2? > > > > > > > > > > [Jon] Yes, but I wanted to bring in Server A being=20 > > > > > > > > > > alive and able to > > > > > > > > > respond > > > > > > > > > > versus Server A down and not responding due to > maintenance. > > > > > > > > > > [Jon] With my better understanding of TTL we still=20 > > > > > > > > > > have an issue if the TTL expires and Server A is=20 > > > > > > > > > > having an extended > > > outage. > > > > > > > > > > How do we recover from that? > > > > > > > > > > ~jon > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > Dots mailing list > > > > > > > > > > > Dots@ietf.org > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > Dots mailing list > > > > > > > > > > Dots@ietf.org > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > Dots mailing list > > > > > > > > > > Dots@ietf.org > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Dots mailing list > > > > > > > > Dots@ietf.org > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > _______________________________________________ > > > > > > Dots mailing list > > > > > > Dots@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots >=20 _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Fri Apr 6 07:44:05 2018 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 919BD1270AC for ; Fri, 6 Apr 2018 07:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLQNWZoPa8wg for ; Fri, 6 Apr 2018 07:44:00 -0700 (PDT) Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C923C120726 for ; Fri, 6 Apr 2018 07:43:59 -0700 (PDT) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 4FFB912043A; Fri, 6 Apr 2018 16:43:58 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.61]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 29C208008B; Fri, 6 Apr 2018 16:43:58 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7E.corporate.adroot.infra.ftgroup ([fe80::b91c:ea2c:ac8a:7462%19]) with mapi id 14.03.0382.000; Fri, 6 Apr 2018 16:43:57 +0200 From: To: Jon Shallow , "Konda, Tirumaleswar Reddy" , "dots@ietf.org" Thread-Topic: [Dots] Signal Channel - 300 Redirected Signaling Thread-Index: AQJ5xX4UsK17va5Vv37fpNudI6+9awKIdnG+AkIt6UkCuIhgoQJj4oJpArGJQHwA3D0H4gGs0H5ZApHDVXYB/IC8TgE0bwOgAlFzC1QBmQ12ZgEwaI7ZAa02vLICgeu4wKG2aUHQgAADq4A= Date: Fri, 6 Apr 2018 14:43:57 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DEF9841@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <014f01d3cc19$2e3880e0$8aa982a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7E7B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <019901d3cc23$a93ff8e0$fbbfeaa0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8524@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <004e01d3ccb4$d505e7f0$7f11b7d0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8758@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEF912A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEF93EE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <008501d3cda6$c860d210$59227630$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF951 1@OPEXCLILMA3 . corporate.adroot.infra.ftgroup> <00b001d3cdab$ba8caec0$2fa60c40$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF975C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <00b801d3cdb4$982dc4a0$c8894de0$@jpshallow.com> In-Reply-To: <00b801d3cdb4$982dc4a0$c8894de0$@jpshallow.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling 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, 06 Apr 2018 14:44:03 -0000 Re-, Happily. You may check the github version.=20 Cheers, Med > -----Message d'origine----- > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > Envoy=E9=A0: vendredi 6 avril 2018 16:36 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; dots@ietf.o= rg > Objet=A0: RE: [Dots] Signal Channel - 300 Redirected Signaling >=20 > Hi Med, >=20 > Thanks for this. I would like to see the ttl: definition tightened up > (moved away from the DNS TTL version) >=20 > Old >=20 > ttl: Time to live (TTL) of alternate records, represented as an > integer number of seconds. That is, the time interval that > alternate IP addresses may be cached by a DOTS client. >=20 > '0' means that an alternate IP address is only to be used for the > request in progress, and consequently that IP address should not > be cached. >=20 > If no 'ttl' is returned in a redirect response, this is equivalent > to returning a 'ttl' parameter set to '0'. >=20 > If 'alt-server-record' has expired, the DOTS client MUST use the > DOTS server(s) that was provisioned using means discussed in > Section 4.1. Furthermore, a DOTS client MUST NOT use the alt- > server FQDN if the 'alt-server-records' has expired. >=20 > New >=20 > ttl: Time to live (TTL) of the alternate DOTS server, represented as = an > integer number of seconds. That is, the time interval that > the alternate DOTS server may be cached for use by a DOTS client. >=20 > '0' means that the alternate DOTS server is only to be used for the > request in progress, and consequently the alternate DOTS server ent= ry > should not > be cached. >=20 > If no 'ttl' is returned in a redirect response, this is equivalent > to returning a 'ttl' parameter set to '0'. >=20 > If the alternate DOTS server TTL has expired, the DOTS client MUST = use > the > DOTS server(s) that was provisioned using means discussed in > Section 4.1. >=20 >=20 > Regards >=20 > Jon >=20 > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > mohamed.boucadair@orange.com > Sent: 06 April 2018 15:21 > To: Jon Shallow; Konda, Tirumaleswar Reddy; dots@ietf.org > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling >=20 > FWIW, I implemented the change at: > https://github.com/boucadair/draft-ietf-dots-signal-channel/blob/master/d= raf > t-ietf-dots-signal-channel.txt >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > Envoy=E9=A0: vendredi 6 avril 2018 15:33 > > =C0=A0: BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; > > dots@ietf.org Objet=A0: RE: [Dots] Signal Channel - 300 Redirected > > Signaling > > > > Excellent. > > > > Thanks > > > > Jon > > > > -----Original Message----- > > From: mohamed.boucadair@orange.com [mailto: > > mohamed.boucadair@orange.com] > > Sent: 06 April 2018 14:29 > > To: Jon Shallow; Konda, Tirumaleswar Reddy; rdd@cert.org > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > Hi Jon, all, > > > > I'm fine to put ttl at the level of alt-server. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > Envoy=E9=A0: vendredi 6 avril 2018 14:57 =C0=A0: BOUCADAIR Mohamed IM= T/OLN; > > > Konda, Tirumaleswar Reddy; rdd@cert.org Objet=A0: RE: [Dots] Signal > > > Channel - 300 Redirected Signaling > > > > > > Hi there, > > > > > > See inline [Jon3] > > > > > > Regards > > > > > > Jon > > > > > > > > > > > > -----Message d'origine----- > > > > > > De=A0: Konda, Tirumaleswar Reddy > > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > Envoy=E9=A0: vendredi 6 avril 2018 07:07 =C0=A0: BOUCADAIR Moha= med > > > > > > IMT/OLN; Jon Shallow; dots@ietf.org Objet=A0: RE: > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > Hi Med, > > > > > > > > > > > > The proposed update restricts the client no to do a DNS lookup > > > > > > using the alternate FQDN, further associating a TTL with the > > > > > > name complicates the functionality on the DOTS client to > > > > > > re-establish (D)TLS session with the primary DOTS server after > > > > > > the > > TTL expires. > > > > > > My suggestion is to let the DOTS client continue to use the > > > > > > alternate DOTS > > > > server > > > > > till it gets re-directed. > > > > > > > > > > [Med] This is possible with the current spec. > > > > > > > > > > Triggers for redirect and for falling back to the nominal > > > > > configuration are deployment-specific. The current spec allows > > > > > for almost all the cases > > > > discussed > > > > > so far: > > > > > > > > > > (1) Redirect for the request in progress: A server does so by > > > > > returning > > > > TTL=3D0. > > > > > (2) The alternate server is not involved in fall back to the > > > > > nominal > > > > server: upon > > > > > expiry of ttl of all alternate IP addresses, then fall back > > > > > automatically > > > > to the > > > > > nominal server. > > > > > (3) Redirect to an alternate server, which in turn will instruct > > > > > the client > > > > to > > > > > redirect to the "base" configuration: a TTL is provided and the > > > > > alternate > > > > server > > > > > can reply with a redirect code any time before the expiry of the > > > > > TTL. A > > > > long TTL > > > > > can be returned if the alternate server will be responsible for > > > > coordinating fall > > > > > back to the base server. > > > > > (4) Stop infinite redirects > > > > > > > > Yes, but (1) and (2) complicate the functionality of the DOTS clien= t. > > > > > > [Med] (1) and (2) is exactly the same functionality required for > > > caching DNS replies. > > > > > > The > > > > only reason for adding alt-server-record in the response is DNS > > > > server may not be reachable by the DOTS server because of a DDoS > attack. > > > > > > > > > > [Med] Yes. Note that even if the name resolution was allowed, the > > > client has to deal with the TTL indicated in the response...which is > > > exactly the same as (1) and (2). > > > > > > > > > [Jon3] I think where I am struggling here is the overloaded use of > > > TTL > > > - The TTL as per a DNS record and held as a part of > > > alt-server-record and then the TTL after which that the alt-server > > > should be handling the traffic before handling back to the original > > > primary server. It either has to be one or the other, or they have t= o > have different names. > > > [Jon3] If we are only going to go for one variant for simplicity, > > > then I would prefer that it should be at the level of "alt-server". > > > Handling the TTL for DNS refresh is normally handled by a resolver > > > library, updated by the DNS packets coming in - unusual for an > > > application > > to have to do that. > > > > > > > > > > > > > > > > > > I > > > > > > don't think the DOTS mitigation provider will know > > > > > > ahead-of-time the TTL value after which the DOTS client should > > > > > > disconnect communicating with the alternate DOTS server and > > > > > > re-establish (D)TLS session with the primary DOTS server. > > > > > > > > > > [Med] It depends on the nature of the redirect: overload, > > > > > planned > > > > maintenance, > > > > > etc. For planned maintenance, the TTL is known in general. > > > > > > > > It's the primary DOTS server responsibility to point the DOTS > > > > client to an optimal alternate server, where the client can > > > > continue to send migration requests without a frequent ping-pong > between servers. > > > > > > [Med] Agree. This is a service configuration problem. > > > [Jon3] Agreed - and the 5 minute minimum ping-pong time is a good > > > safety net. > > > ~jon3 > > > > > > > I have seen TURN servers being deployed for several years with > > > re-direction > > > > but without the need for TTL (see ALTERNATE-SERVER in > > > > https://tools.ietf.org/html/draft-ietf-tram-turnbis-11) > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > -Tiru > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of > > > > > > > mohamed.boucadair@orange.com > > > > > > > Sent: Thursday, April 5, 2018 4:50 PM > > > > > > > To: Konda, Tirumaleswar Reddy > > > > > > > ; > > > > > > > Jon Shallow ; dots@ietf.org > > > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected > > > > > > > Signaling > > > > > > > > > > > > > > Tiru, > > > > > > > > > > > > > > I don't see the NEW text as a restriction but as a > > > > > > > simplification of the > > > > > > client's > > > > > > > behavior. I don't want to over-specify the redirect behavior. > > > > > > > > > > > > > > Adding another yet layer of resolution will raise other > > > > > > > issues such as the > > > > > > need to > > > > > > > associate a TTL with the name itself. > > > > > > > > > > > > > > Cheers, > > > > > > > Med > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Konda, Tirumaleswar Redd= y > > > > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > > > Envoy=E9=A0: jeudi 5 avril 2018 12:06 =C0=A0: Jon Shallow; > > > > > > > > BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet=A0: > > > RE: > > > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > > > > > > Sent: Thursday, April 5, 2018 1:35 PM > > > > > > > > > To: mohamed.boucadair@orange.com; Konda, Tirumaleswar > > > > > > > > > Reddy ; > > > > > > > > > dots@ietf.org > > > > > > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected > > > > > > > > > Signaling > > > > > > > > > > > > > > > > > > Hi Med, > > > > > > > > > > > > > > > > > > Thanks for this refresh to 4.6 Redirected Signaling > > > > > > > > > > > > > > > > > > Some comments > > > > > > > > > > > > > > > > > > #1 > > > > > > > > > > > > > > > > > > The DOTS server can return the error response code > > > > > > > > > 3.00 in > > > > response > > > > > > > > > to a PUT request from the DOTS client or convey the > > > > > > > > > error > > > > response > > > > > > > > > code 3.00 in a unidirectional notification response > > > > > > > > > from the > > > > DOTS > > > > > > > > > server. > > > > > > > > > > > > > > > > > > Why is this limited to a PUT request and/or > > > > > > > > > unidirectional notification > > > > > > > > response? > > > > > > > > > - Surely, any response, unsolicited or otherwise can > > > > > > > > > contain a > > > > > > > > > 3.00 > > > > > > > > > - If Observe is not in use, then any unsolicited > > > > > > > > > notification response will potentially get rejected by > > > > > > > > > the coap library layer, so a DOTS Server cannot > > > > > > > > signal > > > > > > > > > maintenance outage other than by closing the session. > > > > > > > > > - I missed this the last review - sorry > > > > > > > > > > > > > > > > > > > > > > > > > > #2 > > > > > > > > > > > > > > > > > > If the DOTS client has been redirected to a DOTS > > > > > > > > > server to > > > which > > > > it > > > > > > > > > has already sent the mitigation request within the > > > > > > > > > last five > > > (5) > > > > > > > > > minutes, it MUST ignore the redirection and try to > > > > > > > > > contact other DOTS > > > > > > > > > > > > > > > > > > s/ has already sent the mitigation request/ has already > > > > > > > > > communicated with/ > > > > > > > > > > > > > > > > > > #3 > > > > > > > > > > > > > > > > > > A DOTS client MUST NOT use an alternate IP address > > > > > > > > > to > > > contact > > > > its > > > > > > > > > DOTS server upon expiry of the associated TTL. > > > > > > > > > > > > > > > > > > To remove ambiguity over the use of FQDN, this could > > > > > > > > > read > > > > > > > > > > > > > > > > > > A DOTS client MUST NOT use an alternate IP address > > > > > > > > > to > > > contact > > > > its > > > > > > > > > DOTS server upon expiry of the associated TTL. > > > > > > > > > Furthermore, a > > > > > > DOTS > > > > > > > > > Client MUST NOT use the alt-server FQDN if all of > > > > > > > > > the > > > > > > > > > alt-server- > > > > > > > > records > > > > > > > > > have expired. > > > > > > > > > > > > > > > > > > Or alternatively > > > > > > > > > > > > > > > > > > alt-server: FQDN of an alternate DOTS server. > > > > > > > > > > > > > > > > > > This could read > > > > > > > > > > > > > > > > > > alt-server: FQDN of an alternate DOTS server. This > > > > > > > > > FQDN is not to be > > > > > > > > used for > > > > > > > > > looking up IP addresses to use, but is there for the SNI > > > > > > > > > extension > > > > > > (7.1. > > > > > > > > (D)TLS > > > > > > > > > Protocol Profile) > > > > > > > > > > > > > > > > I don't think the above restriction is correct for the > > > > > > > > following > > > > reasons: > > > > > > > > > > > > > > > > 1) If the TTL value in the alt-server-record expires, DNS > > > > > > > > lookup can be performed by the DOTS client using the > > > > > > > > alternate DOTS > > > server > > > > FQDN. > > > > > > > > 2) If the DNS server is reachable, the client may want to > > > > > > > > a DANE lookup to get the IP addresses and certificate to > > > > > > > > validate the alternate DOTS server certificate sent > > > > > > > > in the DTLS handshake. > > > > > > > > > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > Jon > > > > > > > > > -----Original Message----- > > > > > > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > > > > > > > > mohamed.boucadair@orange.com > > > > > > > > > Sent: 05 April 2018 08:20 > > > > > > > > > To: Konda, Tirumaleswar Reddy; Jon Shallow; > > > > > > > > > dots@ietf.org > > > > > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected > > > > > > > > > Signaling > > > > > > > > > > > > > > > > > > Hi Tiru, > > > > > > > > > > > > > > > > > > Works for me. > > > > > > > > > > > > > > > > > > I updated the draft with the text additions that were > > > > > > > > > discussed in this thread. The changes can be found at: > > > > > > > > > https://github.com/boucadair/draft-ietf-dots-signal- > > > > > > > > channel/blob/master/draf > > > > > > > > > t-ietf-dots-signal-channel.txt > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > Med > > > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Konda, Tirumaleswar > > > > > > > > > > Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > > > > > Envoy=E9=A0: mercredi 4 avril 2018 17:40 =C0=A0: Jon Sh= allow; > > > > > > > > > > BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet=A0: RE: > > > > > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > > > > > > The TTL value returned under alt-server-record is > > > > > > > > > > equivalent to the DNS TTL value. A DDoS mitigation > > > > > > > > > > provider with multiple DOTS servers typically > > > > > > > > > > re-directs a DOTS client to a different DOTS server > > > > > > > > > > only if the alternate DOTS server has the capacity to > > > > > > > > > > handle the requests from the > > > > > > > > > DOTS client. > > > > > > > > > > > > > > > > > > > > We can add the following lines to avoid loops : > > > > > > > > > > > > > > > > > > > > If the DOTS client has been redirected to a DOTS > > > > > > > > > > server to which it has already sent the mitigation > > > > > > > > > > request within the last five minutes, it MUST ignore > > > > > > > > > > the redirection and try reaching others servers listed > > > > > > > > > > in the local configuration or discovered using dynamic > > > > > > > > > > means > > such as DHCP or SRV procedures. > > > > > > > > > > This prevents infinite ping-ponging between servers in > > > > > > > > > > case of redirection loops. > > > > > > > > > > > > > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf > > > > > > > > > > > Of Jon Shallow > > > > > > > > > > > Sent: Wednesday, April 4, 2018 8:16 PM > > > > > > > > > > > To: mohamed.boucadair@orange.com; dots@ietf.org > > > > > > > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected > > > > > > > > > > > Signaling > > > > > > > > > > > > > > > > > > > > > > Hi there, > > > > > > > > > > > > > > > > > > > > > > See inline [Jon] > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf > > > > > > > > > > > Of mohamed.boucadair@orange.com > > > > > > > > > > > Sent: 04 April 2018 15:07 > > > > > > > > > > > To: Jon Shallow; dots@ietf.org > > > > > > > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected > > > > > > > > > > > Signaling > > > > > > > > > > > > > > > > > > > > > > Re-, > > > > > > > > > > > > > > > > > > > > > > Please see inline. > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > Med > > > > > > > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Dots > > > > > > > > > > > > [mailto:dots-bounces@ietf.org] De la part de Jon > > > > > > > > > > > > Shallow Envoy=E9=A0: mercredi 4 avril 2018 15:31 = =C0=A0: > > > > > > > > > > > > dots@ietf.org > > > > > > Objet=A0: > > > > > > > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > > > Hi there, > > > > > > > > > > > > > > > > > > > > > > > > I have implemented the 300 Redirected-Signal in my > > > > > > > > > > > > DOTS > > > code. > > > > > > > > > > > > This then raises some questions about usability. > > > > > > > > > > > > > > > > > > > > > > > > Usability #1 > > > > > > > > > > > > > > > > > > > > > > > > Architecture 3.2.2 Redirected Signalling > > > > > > > > > > > > > > > > > > > > > > > > 4. Having redirected the DOTS client, DOTS > > > > > > > > > > > > server A ceases > > > > > > > > sending > > > > > > > > > > > > server signals. The DOTS client likewise > > > > > > > > > > > > stops sending > > > > > > client > > > > > > > > > > > > signals to DOTS server A. DOTS session 1 > > > > > > > > > > > > is > > > > terminated. > > > > > > > > > > > > > > > > > > > > > > > > Clearly indicates that the original session > > > > > > > > > > > > (Client to Server > > > > > > > > > > > > A) is no more once redirected and only Client to > > > > > > > > > > > > Server B is in > > > > > > use. > > > > > > > > > > > > > > > > > > > > > > > > How is the traffic redirected back to Server A > > > > > > > > > > > > once maintenance / overloading etc. has finished? > > > > > > > > > > > > My assumption is that Server B sends a redirect to > > > > > > > > > > > > go back to Server A as Server A has no way to say > > > > > > > > > > > > over a now non-existent session to say > > > > > > > "come back". > > > > > > > > > > > > > > > > > > > > > > [Med] That's one possibility. This one does not > > > > > > > > > > > require any update to the > > > > > > > > > > signal- > > > > > > > > > > > channel specification. > > > > > > > > > > > > > > > > > > > > > > Another approach would be to not require any > > > > > > > > > > > redirect signal from server > > > > > > > > > B. > > > > > > > > > > > The client will remove server B's records upon the > > > > > > > > > > > expiry of the TTL and > > > > > > > > > > will fall > > > > > > > > > > > back to the "base" DOTS servers configuration that > > > > > > > > > > > was provisioned to the > > > > > > > > > > client > > > > > > > > > > > using DHCP or whatever mechanism. > > > > > > > > > > > [Jon] OK. The TTL is defined at, associated with > > > > > > > > > > > the IP address level > > > > > > > > > > under alt- > > > > > > > > > > > server-record, not under > > > > > > > > > > > ietf-dots-signal-channel:redirected-signal. The ttl > > > > definition is > > > > > > > > > > > ambiguous as to what it refers to and perhaps could > > > > > > > > > > > be tightened up in the language (I read it as being > > > > > > > > > > > associated with "addr" in the sense of a DNS > > > > > > > > > > TTL). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Do we need to keep the existing Client to Server A > > > > > > > > > > > > session warm (or perhaps to probe periodically) to > > > > > > > > > > > > see if Server A is capable of handling the Client > > > > > > > > > > > > again by a server response extension to the > > > > > > > > > > > > protocol (e.g. a 3.01) > > > > > > > > > > > > > > > > > > > > > > [Med] Redirect was initially introduced to manage a > > > > > > > > > > > server overload, so I > > > > > > > > > > don't > > > > > > > > > > > think it makes sense to probe or maintain a session > > > > > > > > > > > with > > > server > > > > A. > > > > > > > > > > > [Jon] Agreed, but I needed to raise the question. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Should there be a retry period parameter added in > > > > > > > > > > > > to the > > > > > > > > > > > > 3.00 protocol (as I read it, ttl only refers to > > > > > > > > > > > > the IP > > > > address)? > > > > > > > > > > > > > > > > > > > > > > [Med] The client will automatically switch to Server > > > > > > > > > > > A when all alternate > > > > > > > > > > records > > > > > > > > > > > expire. > > > > > > > > > > > [Jon] OK - again the 4.6 text needs to get tightened > > > > > > > > > > > up to reflect this as > > > > > > > > > > the > > > > > > > > > > > intent. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Usability #2 > > > > > > > > > > > > > > > > > > > > > > > > Server A says "Redirect to Server B" due to > overloading. > > > > > > > > > > > > Server B accepts things for a while and then is > > > > > > > > > > > > instructed/decides to redirect traffic back to A. > > > > > > > > > > > > Server A is left still overload configured to > > > > > > > > > > > > redirect to B. How should the client handle this > > > > > > > > > > > > as there is no suitable > > > > > > > > > > > Server? > > > > > > > > > > > > > > > > > > > > > > [Med] This is a service configuration problem. We may > ask: > > > > > > > > > > > * the client to log the error and notify the > > administrator. > > > > > > > > > > > * and/or stop the redirection after n cycles. > > > > > > > > > > > > > > > > > > > > > > Still, this does not solve the problem. > > > > > > > > > > > [Jon] Agreed there is a problem here > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I agree that there needs to be co-ordination > > > > > > > > > > > > between Server A and Server B, but user error may > creep in. > > > > > > > > > > > > > > > > > > > > > > > > Usability #3 > > > > > > > > > > > > > > > > > > > > > > > > Server A says "Redirect to Server B" as it going > > > > > > > > > > > > to be shut down because of maintenance. Server B > > > > > > > > > > > > accepts things for a while and then is instructed > > > > > > > > > > > > (in probable user > > > > > > > > > > > > error) to redirect traffic back to A (perhaps > > > > > > > > > > > > because it has hit an overload condition). How > > > > > > > > > > > > should the client > > > > > > > > > > > handle this? > > > > > > > > > > > > > > > > > > > > > > [Med] Isn't this a sub-case or #2? > > > > > > > > > > > [Jon] Yes, but I wanted to bring in Server A being > > > > > > > > > > > alive and able to > > > > > > > > > > respond > > > > > > > > > > > versus Server A down and not responding due to > > maintenance. > > > > > > > > > > > [Jon] With my better understanding of TTL we still > > > > > > > > > > > have an issue if the TTL expires and Server A is > > > > > > > > > > > having an extended > > > > outage. > > > > > > > > > > > How do we recover from that? > > > > > > > > > > > ~jon > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > Dots mailing list > > > > > > > > > > > > Dots@ietf.org > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > Dots mailing list > > > > > > > > > > > Dots@ietf.org > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > Dots mailing list > > > > > > > > > > > Dots@ietf.org > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > Dots mailing list > > > > > > > > > Dots@ietf.org > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Dots mailing list > > > > > > > Dots@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > _______________________________________________ > > > > Dots mailing list > > > > Dots@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots > > >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Fri Apr 6 07:45:39 2018 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 7CDE9120726 for ; Fri, 6 Apr 2018 07:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 CSgDBc-xTOxO for ; Fri, 6 Apr 2018 07:45:34 -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 C94621270AE for ; Fri, 6 Apr 2018 07:45:33 -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=1523025933; 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: dlp-product:dlp-version:dlp-reaction: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-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-Network-Message-Id: 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=4 5hbc5ik7xxWd85HtvemriSj05mpUQ5mjwvA17VSnr Q=; b=pY4MjQK4Mjt2XhtRm+O+O0xe5BBwBanPOcHu+zkUJ12l 7R5KBP607m0UkbsMILJpO5KJKe90xQvZQZbNGDr5HAXnLEKn/O w5XLcV1I0Ij0AJSV9rnPlT9Jdwurh0362nYeVXTdmvvRlDIns2 kBQZvgBeACsEGI1By8reEsdvVs0= Received: from DNVEXAPP1N04.corpzone.internalzone.com (DNVEXAPP1N04.corpzone.internalzone.com [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 3127_1c8d_45168669_3403_4670_abab_63efa569e37b; Fri, 06 Apr 2018 09:45:32 -0500 Received: from DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 6 Apr 2018 08:44:15 -0600 Received: from DNVEXUSR1N08.corpzone.internalzone.com (10.44.48.81) by DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 6 Apr 2018 08:44:14 -0600 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXUSR1N08.corpzone.internalzone.com (10.44.48.81) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Fri, 6 Apr 2018 08:44:14 -0600 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (10.44.176.240) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 6 Apr 2018 08:44:13 -0600 Received: from BN6PR16MB1425.namprd16.prod.outlook.com (10.172.207.19) by BN6PR16MB1410.namprd16.prod.outlook.com (10.172.207.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.653.12; Fri, 6 Apr 2018 14:44:11 +0000 Received: from BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d]) by BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d%2]) with mapi id 15.20.0653.012; Fri, 6 Apr 2018 14:44:11 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Signal Channel - 300 Redirected Signaling Thread-Index: AdPMGSyCaQQbv+vLSW+0gkDbU7HOEwAAo7xAAAH7T4AAARdqYAAhoxEAAAGQiwAAAKyNYAAF3e1QACUKCFAAAZEMQAAIeXTgAARcGhAABheI0A== Date: Fri, 6 Apr 2018 14:44:11 +0000 Message-ID: References: <014f01d3cc19$2e3880e0$8aa982a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7E7B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <019901d3cc23$a93ff8e0$fbbfeaa0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8524@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <004e01d3ccb4$d505e7f0$7f11b7d0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8758@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEF912A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEF93EE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DEF93EE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [122.172.69.219] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR16MB1410; 7:g0UUoXKGSAYYLVZRHYuQJmivlzyCeY8idiNpjm/n+C4GL3DsC2uFO06rKks1A1JCK4x3uP69PIRM2EJoooFOPbrYLkMomqGIiDWZmBbHuGizX3lQzwRJk7GrQf9r8i5PAfxd+tghFyMND5A32qcwAesxFWryNzuurFTl5Pt8GzYYMLXrl7AccZMOUI8/qB7X3x2VWK7mErWBgIz3prcSwx4UYzMVLYV9ohDJPzrmgRDSJTkW3zZXXikAPUnEsimu x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: a8b04b13-152a-4265-0cdb-08d59bccdc7c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BN6PR16MB1410; x-ms-traffictypediagnostic: BN6PR16MB1410: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(166708455590820)(18271650672692)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(3231221)(944501327)(52105095)(10201501046)(6041310)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:BN6PR16MB1410; BCL:0; PCL:0; RULEID:; SRVR:BN6PR16MB1410; x-forefront-prvs: 0634F37BFF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39380400002)(376002)(346002)(39860400002)(366004)(396003)(199004)(55784002)(32952001)(189003)(13464003)(57704003)(102836004)(105586002)(6246003)(26005)(11346002)(478600001)(3280700002)(7696005)(55016002)(86362001)(8936002)(316002)(110136005)(53936002)(7736002)(6436002)(6306002)(6506007)(9686003)(106356001)(72206003)(14454004)(5660300001)(486006)(305945005)(53946003)(5250100002)(74316002)(66066001)(76176011)(446003)(2501003)(966005)(93886005)(6116002)(59450400001)(81156014)(2900100001)(476003)(25786009)(68736007)(8676002)(2906002)(99286004)(3846002)(33656002)(229853002)(97736004)(186003)(3660700001)(80792005)(81166006)(53546011)(85282002)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR16MB1410; H:BN6PR16MB1425.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: qNXxtJ12ll00CPw3GpDdXqGyBB0DU4v7FPLvZRAykzkqO/DCRUIDE814rRlkpOn5r+7Kt8Yb0/bIxK4N+oeMHHtLxNj/qnTL89LDeja9qjv9korxlm5FSTOdh4xwdhtye1QFG/unfjC8YCcncryuykreJRfrj4e021mZgup/ueatme3E5g+eru1Ft90eZqLVrhy7NcPHO1nwZy+6AJQnh99fExytkJKZFq6ciWgnX2axg5lEQgX/s3Fi7ax+l6U7R019ByuLtAAPNrfeURJCDrG0qjKyZn/FcW4jcI/YOk14lYrdHA99PT/6eh1ubutmzMpxsHBoXvZBv6rexE/UneiFSQn9SFLGT8FacLidLKBb+gWTqi8mC+p/q9QTkGKYI2ZN+gW33j05CDtmistInQNb7ztSkJDzfAtnb81BnUA= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: a8b04b13-152a-4265-0cdb-08d59bccdc7c X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2018 14:44:11.5182 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR16MB1410 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 <6259> : inlines <6552> : streams <1783372> : uri <2621484> Archived-At: Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling 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, 06 Apr 2018 14:45:37 -0000 > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of > mohamed.boucadair@orange.com > Sent: Friday, April 6, 2018 5:37 PM > To: Konda, Tirumaleswar Reddy ; > Jon Shallow ; dots@ietf.org > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling >=20 > Re-, >=20 > Please see inline. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Konda, > > Tirumaleswar Reddy Envoy=E9=A0: vendredi 6 avril 2018 11:59 =C0=A0: BOU= CADAIR > > Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet=A0: Re: [Dots] Signal > > Channel - 300 Redirected Signaling > > > > > -----Original Message----- > > > From: mohamed.boucadair@orange.com > > > [mailto:mohamed.boucadair@orange.com] > > > Sent: Friday, April 6, 2018 11:26 AM > > > To: Konda, Tirumaleswar Reddy ; > > > Jon Shallow ; dots@ietf.org > > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > Hi Tiru, > > > > > > Please see inline. > > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De=A0: Konda, Tirumaleswar Reddy > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > Envoy=E9=A0: vendredi 6 avril 2018 07:07 =C0=A0: BOUCADAIR Mohamed > > > > IMT/OLN; Jon Shallow; dots@ietf.org Objet=A0: RE: > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > Hi Med, > > > > > > > > The proposed update restricts the client no to do a DNS lookup > > > > using the alternate FQDN, further associating a TTL with the name > > > > complicates the functionality on the DOTS client to re-establish > > > > (D)TLS session with the primary DOTS server after the TTL expires. > > > > My suggestion is to let the DOTS client continue to use the > > > > alternate DOTS > > server > > > till it gets re-directed. > > > > > > [Med] This is possible with the current spec. > > > > > > Triggers for redirect and for falling back to the nominal > > > configuration are deployment-specific. The current spec allows for > > > almost all the cases > > discussed > > > so far: > > > > > > (1) Redirect for the request in progress: A server does so by > > > returning > > TTL=3D0. > > > (2) The alternate server is not involved in fall back to the nominal > > server: upon > > > expiry of ttl of all alternate IP addresses, then fall back > > > automatically > > to the > > > nominal server. > > > (3) Redirect to an alternate server, which in turn will instruct the > > > client > > to > > > redirect to the "base" configuration: a TTL is provided and the > > > alternate > > server > > > can reply with a redirect code any time before the expiry of the > > > TTL. A > > long TTL > > > can be returned if the alternate server will be responsible for > > coordinating fall > > > back to the base server. > > > (4) Stop infinite redirects > > > > Yes, but (1) and (2) complicate the functionality of the DOTS client. >=20 > [Med] (1) and (2) is exactly the same functionality required for caching = DNS > replies. >=20 > The > > only reason for adding alt-server-record in the response is DNS server > > may not be reachable by the DOTS server because of a DDoS attack. > > >=20 > [Med] Yes. Note that even if the name resolution was allowed, the client = has to > deal with the TTL indicated in the response...which is exactly the same a= s (1) and > (2). No, the TTL indicated in the alt-server-record is equivalent to the TTL val= ue in the DNS response for caching.=20 -Tiru >=20 > > > > > > > > > I > > > > don't think the DOTS mitigation provider will know ahead-of-time th= e > > > > TTL value after which the DOTS client should disconnect communicati= ng > > > > with the alternate DOTS server and re-establish (D)TLS session with > > > > the primary DOTS server. > > > > > > [Med] It depends on the nature of the redirect: overload, planned > > maintenance, > > > etc. For planned maintenance, the TTL is known in general. > > > > It's the primary DOTS server responsibility to point the DOTS client to= an > > optimal alternate server, where the client can continue to send migrati= on > > requests without a frequent ping-pong between servers. >=20 > [Med] Agree. This is a service configuration problem. >=20 > > I have seen TURN servers being deployed for several years with re-direc= tion > > but without the need for TTL (see ALTERNATE-SERVER in > > https://tools.ietf.org/html/draft-ietf-tram-turnbis-11) > > > > -Tiru > > > > > > > > > > > > > Cheers, > > > > -Tiru > > > > > > > > > -----Original Message----- > > > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of > > > > > mohamed.boucadair@orange.com > > > > > Sent: Thursday, April 5, 2018 4:50 PM > > > > > To: Konda, Tirumaleswar Reddy > ; > > > > > Jon Shallow ; dots@ietf.org > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > Tiru, > > > > > > > > > > I don't see the NEW text as a restriction but as a simplification= of > > > > > the > > > > client's > > > > > behavior. I don't want to over-specify the redirect behavior. > > > > > > > > > > Adding another yet layer of resolution will raise other issues su= ch > > > > > as the > > > > need to > > > > > associate a TTL with the name itself. > > > > > > > > > > Cheers, > > > > > Med > > > > > > > > > > > -----Message d'origine----- > > > > > > De=A0: Konda, Tirumaleswar Reddy > > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > Envoy=E9=A0: jeudi 5 avril 2018 12:06 > > > > > > =C0=A0: Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org O= bjet=A0: > RE: > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > > > > Sent: Thursday, April 5, 2018 1:35 PM > > > > > > > To: mohamed.boucadair@orange.com; Konda, Tirumaleswar Reddy > > > > > > > ; dots@ietf.org > > > > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > Hi Med, > > > > > > > > > > > > > > Thanks for this refresh to 4.6 Redirected Signaling > > > > > > > > > > > > > > Some comments > > > > > > > > > > > > > > #1 > > > > > > > > > > > > > > The DOTS server can return the error response code 3.00 in > > response > > > > > > > to a PUT request from the DOTS client or convey the error > > response > > > > > > > code 3.00 in a unidirectional notification response from t= he > > DOTS > > > > > > > server. > > > > > > > > > > > > > > Why is this limited to a PUT request and/or unidirectional > > > > > > > notification > > > > > > response? > > > > > > > - Surely, any response, unsolicited or otherwise can contain = a > > > > > > > 3.00 > > > > > > > - If Observe is not in use, then any unsolicited notification > > > > > > > response will potentially get rejected by the coap library > > > > > > > layer, so a DOTS Server cannot > > > > > > signal > > > > > > > maintenance outage other than by closing the session. > > > > > > > - I missed this the last review - sorry > > > > > > > > > > > > > > > > > > > > #2 > > > > > > > > > > > > > > If the DOTS client has been redirected to a DOTS server to= which > > it > > > > > > > has already sent the mitigation request within the last fi= ve (5) > > > > > > > minutes, it MUST ignore the redirection and try to contact > > > > > > > other DOTS > > > > > > > > > > > > > > s/ has already sent the mitigation request/ has already > > > > > > > communicated with/ > > > > > > > > > > > > > > #3 > > > > > > > > > > > > > > A DOTS client MUST NOT use an alternate IP address to c= ontact > > its > > > > > > > DOTS server upon expiry of the associated TTL. > > > > > > > > > > > > > > To remove ambiguity over the use of FQDN, this could read > > > > > > > > > > > > > > A DOTS client MUST NOT use an alternate IP address to c= ontact > > its > > > > > > > DOTS server upon expiry of the associated TTL. > > > > > > > Furthermore, a > > > > DOTS > > > > > > > Client MUST NOT use the alt-server FQDN if all of the > > > > > > > alt-server- > > > > > > records > > > > > > > have expired. > > > > > > > > > > > > > > Or alternatively > > > > > > > > > > > > > > alt-server: FQDN of an alternate DOTS server. > > > > > > > > > > > > > > This could read > > > > > > > > > > > > > > alt-server: FQDN of an alternate DOTS server. This FQDN = is > > > > > > > not to be > > > > > > used for > > > > > > > looking up IP addresses to use, but is there for the SNI > > > > > > > extension > > > > (7.1. > > > > > > (D)TLS > > > > > > > Protocol Profile) > > > > > > > > > > > > I don't think the above restriction is correct for the followin= g > > reasons: > > > > > > > > > > > > 1) If the TTL value in the alt-server-record expires, DNS looku= p > > > > > > can be performed by the DOTS client using the alternate DOTS se= rver > > FQDN. > > > > > > 2) If the DNS server is reachable, the client may want to a DAN= E > > > > > > lookup to get the IP addresses and certificate to validate the > > > > > > alternate DOTS server certificate sent > > > > > > in the DTLS handshake. > > > > > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > Jon > > > > > > > -----Original Message----- > > > > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > > > > > > mohamed.boucadair@orange.com > > > > > > > Sent: 05 April 2018 08:20 > > > > > > > To: Konda, Tirumaleswar Reddy; Jon Shallow; dots@ietf.org > > > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > Hi Tiru, > > > > > > > > > > > > > > Works for me. > > > > > > > > > > > > > > I updated the draft with the text additions that were discuss= ed > > > > > > > in this thread. The changes can be found at: > > > > > > > https://github.com/boucadair/draft-ietf-dots-signal- > > > > > > channel/blob/master/draf > > > > > > > t-ietf-dots-signal-channel.txt > > > > > > > > > > > > > > Cheers, > > > > > > > Med > > > > > > > > > > > > > > > -----Message d'origine----- > > > > > > > > De=A0: Konda, Tirumaleswar Reddy > > > > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > > > Envoy=E9=A0: mercredi 4 avril 2018 17:40 =C0=A0: Jon Shallo= w; > > > > > > > > BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet=A0: RE: > > > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > > The TTL value returned under alt-server-record is equivalen= t > > > > > > > > to the DNS TTL value. A DDoS mitigation provider with multi= ple > > > > > > > > DOTS servers typically re-directs a DOTS client to a differ= ent > > > > > > > > DOTS server only if the alternate DOTS server has the capac= ity > > > > > > > > to handle the requests from the > > > > > > > DOTS client. > > > > > > > > > > > > > > > > We can add the following lines to avoid loops : > > > > > > > > > > > > > > > > If the DOTS client has been redirected to a DOTS server to > > > > > > > > which it has already sent the mitigation request within the > > > > > > > > last five minutes, it MUST ignore the redirection and try > > > > > > > > reaching others servers listed in the local configuration o= r > > > > > > > > discovered using dynamic means such as DHCP or SRV procedur= es. > > > > > > > > This prevents infinite ping-ponging between servers in case= of > > > > > > > > redirection loops. > > > > > > > > > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jo= n > > > > > > > > > Shallow > > > > > > > > > Sent: Wednesday, April 4, 2018 8:16 PM > > > > > > > > > To: mohamed.boucadair@orange.com; dots@ietf.org > > > > > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected > > > > > > > > > Signaling > > > > > > > > > > > > > > > > > > Hi there, > > > > > > > > > > > > > > > > > > See inline [Jon] > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > > > > > > > > mohamed.boucadair@orange.com > > > > > > > > > Sent: 04 April 2018 15:07 > > > > > > > > > To: Jon Shallow; dots@ietf.org > > > > > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected > > > > > > > > > Signaling > > > > > > > > > > > > > > > > > > Re-, > > > > > > > > > > > > > > > > > > Please see inline. > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > Med > > > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Dots > > > > > > > > > > [mailto:dots-bounces@ietf.org] De la part de Jon Shallo= w > > > > > > > > > > Envoy=E9=A0: mercredi 4 avril 2018 15:31 =C0=A0: dots@i= etf.org > > > > Objet=A0: > > > > > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > > > > > > Hi there, > > > > > > > > > > > > > > > > > > > > I have implemented the 300 Redirected-Signal in my DOTS= code. > > > > > > > > > > This then raises some questions about usability. > > > > > > > > > > > > > > > > > > > > Usability #1 > > > > > > > > > > > > > > > > > > > > Architecture 3.2.2 Redirected Signalling > > > > > > > > > > > > > > > > > > > > 4. Having redirected the DOTS client, DOTS server A > > > > > > > > > > ceases > > > > > > sending > > > > > > > > > > server signals. The DOTS client likewise stops > > > > > > > > > > sending > > > > client > > > > > > > > > > signals to DOTS server A. DOTS session 1 is > > terminated. > > > > > > > > > > > > > > > > > > > > Clearly indicates that the original session (Client to > > > > > > > > > > Server > > > > > > > > > > A) is no more once redirected and only Client to Server= B > > > > > > > > > > is in > > > > use. > > > > > > > > > > > > > > > > > > > > How is the traffic redirected back to Server A once > > > > > > > > > > maintenance / overloading etc. has finished? My > > > > > > > > > > assumption is that Server B sends a redirect to go back= to > > > > > > > > > > Server A as Server A has no way to say over a now > > > > > > > > > > non-existent session to say > > > > > "come back". > > > > > > > > > > > > > > > > > > [Med] That's one possibility. This one does not require a= ny > > > > > > > > > update to the > > > > > > > > signal- > > > > > > > > > channel specification. > > > > > > > > > > > > > > > > > > Another approach would be to not require any redirect sig= nal > > > > > > > > > from server > > > > > > > B. > > > > > > > > > The client will remove server B's records upon the expiry= of > > > > > > > > > the TTL and > > > > > > > > will fall > > > > > > > > > back to the "base" DOTS servers configuration that was > > > > > > > > > provisioned to the > > > > > > > > client > > > > > > > > > using DHCP or whatever mechanism. > > > > > > > > > [Jon] OK. The TTL is defined at, associated with the IP > > > > > > > > > address level > > > > > > > > under alt- > > > > > > > > > server-record, not under > > > > > > > > > ietf-dots-signal-channel:redirected-signal. The ttl > > definition is > > > > > > > > > ambiguous as to what it refers to and perhaps could be > > > > > > > > > tightened up in the language (I read it as being associat= ed > > > > > > > > > with "addr" in the sense of a DNS > > > > > > > > TTL). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Do we need to keep the existing Client to Server A sess= ion > > > > > > > > > > warm (or perhaps to probe periodically) to see if Serve= r A > > > > > > > > > > is capable of handling the Client again by a server > > > > > > > > > > response extension to the protocol (e.g. a 3.01) > > > > > > > > > > > > > > > > > > [Med] Redirect was initially introduced to manage a serve= r > > > > > > > > > overload, so I > > > > > > > > don't > > > > > > > > > think it makes sense to probe or maintain a session with = server > > A. > > > > > > > > > [Jon] Agreed, but I needed to raise the question. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Should there be a retry period parameter added in to th= e > > > > > > > > > > 3.00 protocol (as I read it, ttl only refers to the IP > > address)? > > > > > > > > > > > > > > > > > > [Med] The client will automatically switch to Server A wh= en > > > > > > > > > all alternate > > > > > > > > records > > > > > > > > > expire. > > > > > > > > > [Jon] OK - again the 4.6 text needs to get tightened up t= o > > > > > > > > > reflect this as > > > > > > > > the > > > > > > > > > intent. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Usability #2 > > > > > > > > > > > > > > > > > > > > Server A says "Redirect to Server B" due to overloading= . > > > > > > > > > > Server B accepts things for a while and then is > > > > > > > > > > instructed/decides to redirect traffic back to A. Serv= er > > > > > > > > > > A is left still overload configured to redirect to B. = How > > > > > > > > > > should the client handle this as there is no suitable > > > > > > > > > Server? > > > > > > > > > > > > > > > > > > [Med] This is a service configuration problem. We may ask= : > > > > > > > > > * the client to log the error and notify the administrato= r. > > > > > > > > > * and/or stop the redirection after n cycles. > > > > > > > > > > > > > > > > > > Still, this does not solve the problem. > > > > > > > > > [Jon] Agreed there is a problem here > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I agree that there needs to be co-ordination between > > > > > > > > > > Server A and Server B, but user error may creep in. > > > > > > > > > > > > > > > > > > > > Usability #3 > > > > > > > > > > > > > > > > > > > > Server A says "Redirect to Server B" as it going to be > > > > > > > > > > shut down because of maintenance. Server B accepts thi= ngs > > > > > > > > > > for a while and then is instructed (in probable user > > > > > > > > > > error) to redirect traffic back to A (perhaps because i= t > > > > > > > > > > has hit an overload condition). How should the client > > > > > > > > > handle this? > > > > > > > > > > > > > > > > > > [Med] Isn't this a sub-case or #2? > > > > > > > > > [Jon] Yes, but I wanted to bring in Server A being alive = and > > > > > > > > > able to > > > > > > > > respond > > > > > > > > > versus Server A down and not responding due to maintenanc= e. > > > > > > > > > [Jon] With my better understanding of TTL we still have a= n > > > > > > > > > issue if the TTL expires and Server A is having an extend= ed > > outage. > > > > > > > > > How do we recover from that? > > > > > > > > > ~jon > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > Dots mailing list > > > > > > > > > > Dots@ietf.org > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > Dots mailing list > > > > > > > > > Dots@ietf.org > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > Dots mailing list > > > > > > > > > Dots@ietf.org > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Dots mailing list > > > > > > > Dots@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > _______________________________________________ > > > > > Dots mailing list > > > > > Dots@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Fri Apr 6 07:55:47 2018 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 9A8E11271FD for ; Fri, 6 Apr 2018 07:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 TQxqgKe1DBWR for ; Fri, 6 Apr 2018 07:55:40 -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 677AA120726 for ; Fri, 6 Apr 2018 07:55: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=1523026539; 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: dlp-product:dlp-version:dlp-reaction: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-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-Network-Message-Id: 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=a +z+cDYe+HV+tqymbUtCCCqBRJ34hX01d93wYfVJ9h I=; b=lPST0WUXBaj8WqFLi1MoM8kLmoVV22duXaq8LAtY892t /p5PaSNQT8ohPZCkELwn/hhXnpfd7D4RzXwS0a3UcMCBxSD5JL dCEi9T1mRDTVYL8Zfw+Bt1L+hNwhpMXWe5Jlme98knEg2OLKZZ PU+ja35Yu7oPLfbkNLPCsmt1kBI= Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 3b6c_09bc_b52d2306_f919_4f52_a8d5_1c04d989c218; Fri, 06 Apr 2018 09:55:38 -0500 Received: from DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 6 Apr 2018 08:55:25 -0600 Received: from DNVEXUSR1N14.corpzone.internalzone.com (10.44.48.87) by DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 6 Apr 2018 08:55:25 -0600 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXUSR1N14.corpzone.internalzone.com (10.44.48.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Fri, 6 Apr 2018 08:55:24 -0600 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (10.44.176.241) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 6 Apr 2018 08:55:24 -0600 Received: from BN6PR16MB1425.namprd16.prod.outlook.com (10.172.207.19) by BN6PR16MB1508.namprd16.prod.outlook.com (10.172.208.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.653.12; Fri, 6 Apr 2018 14:55:22 +0000 Received: from BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d]) by BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d%2]) with mapi id 15.20.0653.012; Fri, 6 Apr 2018 14:55:22 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: [Dots] Signal Channel - 300 Redirected Signaling Thread-Index: AdPMGSyCaQQbv+vLSW+0gkDbU7HOEwAAo7xAAAH7T4AAARdqYAAhoxEAAAGQiwAAAKyNYAAF3e1QACUKCFAAAZEMQAAIeXTgAARcGhAAAoG7gAABGXwAAAAjBIAAAa5ZgAAAiReAAABpmzA= Date: Fri, 6 Apr 2018 14:55:22 +0000 Message-ID: References: <014f01d3cc19$2e3880e0$8aa982a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7E7B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <019901d3cc23$a93ff8e0$fbbfeaa0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8524@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <004e01d3ccb4$d505e7f0$7f11b7d0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8758@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEF912A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEF93EE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <008501d3cda6$c860d210$59227630$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF951 1@OPEXCLILMA3 . corporate.adroot.infra.ftgroup> <00b001d3cdab$ba8caec0$2fa60c40$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF975C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <00b801d3cdb4$982dc4a0$c8894de0$@jpshallow.com> In-Reply-To: <00b801d3cdb4$982dc4a0$c8894de0$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [122.172.69.219] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR16MB1508; 7:O3dpbiaXHBafKjH4xLmbm4WwoQYkOqzAgkDxYQX7mkbyiQVWyEhdQB9TxwG3lxney2hICODn9810lESniz70L/jaKPHlPPUvE84k1YmNUwBTt1mEf5NSKinYImggZlAifjPJIAHUUAmIfJgh6gaTCGudsZq6KhNRFfXbtxNsED7OQDME+vhPrY12pY1R5u7yJQBTUu377c6leiq3FQX1PzLOaddG3A46K9AdYmOFHJzJxe7p+AELZIRDcjMukyw6 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: beca6614-1ccd-4a08-15cc-08d59bce6c63 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BN6PR16MB1508; x-ms-traffictypediagnostic: BN6PR16MB1508: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(166708455590820)(18271650672692)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(3231221)(944501327)(52105095)(6041310)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(6072148)(201708071742011); SRVR:BN6PR16MB1508; BCL:0; PCL:0; RULEID:; SRVR:BN6PR16MB1508; x-forefront-prvs: 0634F37BFF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39380400002)(39860400002)(346002)(396003)(376002)(55784002)(57704003)(199004)(32952001)(189003)(13464003)(476003)(93886005)(106356001)(86362001)(105586002)(8936002)(8676002)(7736002)(81156014)(81166006)(186003)(305945005)(11346002)(26005)(25786009)(2201001)(74316002)(2900100001)(446003)(6246003)(68736007)(966005)(97736004)(80792005)(6306002)(102836004)(55016002)(486006)(6436002)(7696005)(53936002)(99286004)(59450400001)(9686003)(6506007)(76176011)(53546011)(53946003)(72206003)(2501003)(110136005)(5250100002)(66066001)(478600001)(2906002)(229853002)(3660700001)(316002)(6116002)(3280700002)(3846002)(5660300001)(33656002)(14454004)(85282002)(559001)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR16MB1508; H:BN6PR16MB1425.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: XJsv1YOPs8oSeLZnvy7sI7Do8wPmgN+/aaqEFEhCMY4uXVU33MGW8uWpIqMQQ1jNfvxOGk9QjtxiVbennvEqKA/wumEH/xAgt+ghNW2c6KX9ViXWxm2njKxKcah3MyZLCd6k2f3stHJL9yfEiJaIoxfSC1o4FiqLfgFZg3DIXbvk6MjoR//ihEp7nNeukGeKLyTqtnkAjbDJtYPkj/Sux/DsKYBpirn7+KZEwywEzLmPzrVqeCVjz/1qK2koO3w3BhoQxWt1Jkz82b5kYxpWDJFwGd9HFZ0m9Dr+q0bbtcgvbYiNbwY9KNwhJeGlOfK3J6lxFaDpS56yTjlsEmMc9YbeJT+4Hd6fch9ufHZK4fB1DE0V9zE0DBQHogPUNY0dJx1SWy8zcnSiO3BdDUEW/Woe63Q7DpQ0/K8m+jM2yKI= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: beca6614-1ccd-4a08-15cc-08d59bce6c63 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2018 14:55:22.4202 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR16MB1508 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 <6259> : inlines <6552> : streams <1783372> : uri <2621486> Archived-At: Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling 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, 06 Apr 2018 14:55:45 -0000 The below proposed change does not look good to me, its causing the DOTS cl= ient to ping-pong between multiple DOTS servers because of the TTL value. = The alternate server should serve the DOTS client till there is a planned m= aintenance, if it is getting over-subscribed it should re-direct the new DO= TS clients to an alternate server and avoid bouncing the existing DOTS clie= nts which have been sending mitigation requests to it. =20 -Tiru > -----Original Message----- > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > Sent: Friday, April 6, 2018 8:06 PM > To: mohamed.boucadair@orange.com; Konda, Tirumaleswar Reddy > ; dots@ietf.org > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling >=20 > Hi Med, >=20 > Thanks for this. I would like to see the ttl: definition tightened up (m= oved away > from the DNS TTL version) >=20 > Old >=20 > ttl: Time to live (TTL) of alternate records, represented as an > integer number of seconds. That is, the time interval that > alternate IP addresses may be cached by a DOTS client. >=20 > '0' means that an alternate IP address is only to be used for the > request in progress, and consequently that IP address should not > be cached. >=20 > If no 'ttl' is returned in a redirect response, this is equivalent > to returning a 'ttl' parameter set to '0'. >=20 > If 'alt-server-record' has expired, the DOTS client MUST use the > DOTS server(s) that was provisioned using means discussed in > Section 4.1. Furthermore, a DOTS client MUST NOT use the alt- > server FQDN if the 'alt-server-records' has expired. >=20 > New >=20 > ttl: Time to live (TTL) of the alternate DOTS server, represented as = an > integer number of seconds. That is, the time interval that > the alternate DOTS server may be cached for use by a DOTS client. >=20 > '0' means that the alternate DOTS server is only to be used for the > request in progress, and consequently the alternate DOTS server ent= ry should > not > be cached. >=20 > If no 'ttl' is returned in a redirect response, this is equivalent > to returning a 'ttl' parameter set to '0'. >=20 > If the alternate DOTS server TTL has expired, the DOTS client MUST = use the > DOTS server(s) that was provisioned using means discussed in > Section 4.1. >=20 >=20 > Regards >=20 > Jon >=20 > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > mohamed.boucadair@orange.com > Sent: 06 April 2018 15:21 > To: Jon Shallow; Konda, Tirumaleswar Reddy; dots@ietf.org > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling >=20 > FWIW, I implemented the change at: > https://github.com/boucadair/draft-ietf-dots-signal-channel/blob/master/d= raf > t-ietf-dots-signal-channel.txt >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > Envoy=E9=A0: vendredi 6 avril 2018 15:33 > > =C0=A0: BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; > > dots@ietf.org Objet=A0: RE: [Dots] Signal Channel - 300 Redirected > > Signaling > > > > Excellent. > > > > Thanks > > > > Jon > > > > -----Original Message----- > > From: mohamed.boucadair@orange.com [mailto: > > mohamed.boucadair@orange.com] > > Sent: 06 April 2018 14:29 > > To: Jon Shallow; Konda, Tirumaleswar Reddy; rdd@cert.org > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > Hi Jon, all, > > > > I'm fine to put ttl at the level of alt-server. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > Envoy=E9=A0: vendredi 6 avril 2018 14:57 =C0=A0: BOUCADAIR Mohamed IM= T/OLN; > > > Konda, Tirumaleswar Reddy; rdd@cert.org Objet=A0: RE: [Dots] Signal > > > Channel - 300 Redirected Signaling > > > > > > Hi there, > > > > > > See inline [Jon3] > > > > > > Regards > > > > > > Jon > > > > > > > > > > > > -----Message d'origine----- > > > > > > De=A0: Konda, Tirumaleswar Reddy > > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > Envoy=E9=A0: vendredi 6 avril 2018 07:07 =C0=A0: BOUCADAIR Moha= med > > > > > > IMT/OLN; Jon Shallow; dots@ietf.org Objet=A0: RE: > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > Hi Med, > > > > > > > > > > > > The proposed update restricts the client no to do a DNS lookup > > > > > > using the alternate FQDN, further associating a TTL with the > > > > > > name complicates the functionality on the DOTS client to > > > > > > re-establish (D)TLS session with the primary DOTS server after > > > > > > the > > TTL expires. > > > > > > My suggestion is to let the DOTS client continue to use the > > > > > > alternate DOTS > > > > server > > > > > till it gets re-directed. > > > > > > > > > > [Med] This is possible with the current spec. > > > > > > > > > > Triggers for redirect and for falling back to the nominal > > > > > configuration are deployment-specific. The current spec allows > > > > > for almost all the cases > > > > discussed > > > > > so far: > > > > > > > > > > (1) Redirect for the request in progress: A server does so by > > > > > returning > > > > TTL=3D0. > > > > > (2) The alternate server is not involved in fall back to the > > > > > nominal > > > > server: upon > > > > > expiry of ttl of all alternate IP addresses, then fall back > > > > > automatically > > > > to the > > > > > nominal server. > > > > > (3) Redirect to an alternate server, which in turn will instruct > > > > > the client > > > > to > > > > > redirect to the "base" configuration: a TTL is provided and the > > > > > alternate > > > > server > > > > > can reply with a redirect code any time before the expiry of the > > > > > TTL. A > > > > long TTL > > > > > can be returned if the alternate server will be responsible for > > > > coordinating fall > > > > > back to the base server. > > > > > (4) Stop infinite redirects > > > > > > > > Yes, but (1) and (2) complicate the functionality of the DOTS clien= t. > > > > > > [Med] (1) and (2) is exactly the same functionality required for > > > caching DNS replies. > > > > > > The > > > > only reason for adding alt-server-record in the response is DNS > > > > server may not be reachable by the DOTS server because of a DDoS > attack. > > > > > > > > > > [Med] Yes. Note that even if the name resolution was allowed, the > > > client has to deal with the TTL indicated in the response...which is > > > exactly the same as (1) and (2). > > > > > > > > > [Jon3] I think where I am struggling here is the overloaded use of > > > TTL > > > - The TTL as per a DNS record and held as a part of > > > alt-server-record and then the TTL after which that the alt-server > > > should be handling the traffic before handling back to the original > > > primary server. It either has to be one or the other, or they have > > > to > have different names. > > > [Jon3] If we are only going to go for one variant for simplicity, > > > then I would prefer that it should be at the level of "alt-server". > > > Handling the TTL for DNS refresh is normally handled by a resolver > > > library, updated by the DNS packets coming in - unusual for an > > > application > > to have to do that. > > > > > > > > > > > > > > > > > > I > > > > > > don't think the DOTS mitigation provider will know > > > > > > ahead-of-time the TTL value after which the DOTS client should > > > > > > disconnect communicating with the alternate DOTS server and > > > > > > re-establish (D)TLS session with the primary DOTS server. > > > > > > > > > > [Med] It depends on the nature of the redirect: overload, > > > > > planned > > > > maintenance, > > > > > etc. For planned maintenance, the TTL is known in general. > > > > > > > > It's the primary DOTS server responsibility to point the DOTS > > > > client to an optimal alternate server, where the client can > > > > continue to send migration requests without a frequent ping-pong > between servers. > > > > > > [Med] Agree. This is a service configuration problem. > > > [Jon3] Agreed - and the 5 minute minimum ping-pong time is a good > > > safety net. > > > ~jon3 > > > > > > > I have seen TURN servers being deployed for several years with > > > re-direction > > > > but without the need for TTL (see ALTERNATE-SERVER in > > > > https://tools.ietf.org/html/draft-ietf-tram-turnbis-11) > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > -Tiru > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of > > > > > > > mohamed.boucadair@orange.com > > > > > > > Sent: Thursday, April 5, 2018 4:50 PM > > > > > > > To: Konda, Tirumaleswar Reddy > > > > > > > ; > > > > > > > Jon Shallow ; dots@ietf.org > > > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected > > > > > > > Signaling > > > > > > > > > > > > > > Tiru, > > > > > > > > > > > > > > I don't see the NEW text as a restriction but as a > > > > > > > simplification of the > > > > > > client's > > > > > > > behavior. I don't want to over-specify the redirect behavior. > > > > > > > > > > > > > > Adding another yet layer of resolution will raise other > > > > > > > issues such as the > > > > > > need to > > > > > > > associate a TTL with the name itself. > > > > > > > > > > > > > > Cheers, > > > > > > > Med > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Konda, Tirumaleswar Redd= y > > > > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > > > Envoy=E9=A0: jeudi 5 avril 2018 12:06 =C0=A0: Jon Shallow; > > > > > > > > BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet=A0: > > > RE: > > > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > > > > > > Sent: Thursday, April 5, 2018 1:35 PM > > > > > > > > > To: mohamed.boucadair@orange.com; Konda, Tirumaleswar > > > > > > > > > Reddy ; > > > > > > > > > dots@ietf.org > > > > > > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected > > > > > > > > > Signaling > > > > > > > > > > > > > > > > > > Hi Med, > > > > > > > > > > > > > > > > > > Thanks for this refresh to 4.6 Redirected Signaling > > > > > > > > > > > > > > > > > > Some comments > > > > > > > > > > > > > > > > > > #1 > > > > > > > > > > > > > > > > > > The DOTS server can return the error response code > > > > > > > > > 3.00 in > > > > response > > > > > > > > > to a PUT request from the DOTS client or convey the > > > > > > > > > error > > > > response > > > > > > > > > code 3.00 in a unidirectional notification response > > > > > > > > > from the > > > > DOTS > > > > > > > > > server. > > > > > > > > > > > > > > > > > > Why is this limited to a PUT request and/or > > > > > > > > > unidirectional notification > > > > > > > > response? > > > > > > > > > - Surely, any response, unsolicited or otherwise can > > > > > > > > > contain a > > > > > > > > > 3.00 > > > > > > > > > - If Observe is not in use, then any unsolicited > > > > > > > > > notification response will potentially get rejected by > > > > > > > > > the coap library layer, so a DOTS Server cannot > > > > > > > > signal > > > > > > > > > maintenance outage other than by closing the session. > > > > > > > > > - I missed this the last review - sorry > > > > > > > > > > > > > > > > > > > > > > > > > > #2 > > > > > > > > > > > > > > > > > > If the DOTS client has been redirected to a DOTS > > > > > > > > > server to > > > which > > > > it > > > > > > > > > has already sent the mitigation request within the > > > > > > > > > last five > > > (5) > > > > > > > > > minutes, it MUST ignore the redirection and try to > > > > > > > > > contact other DOTS > > > > > > > > > > > > > > > > > > s/ has already sent the mitigation request/ has already > > > > > > > > > communicated with/ > > > > > > > > > > > > > > > > > > #3 > > > > > > > > > > > > > > > > > > A DOTS client MUST NOT use an alternate IP address > > > > > > > > > to > > > contact > > > > its > > > > > > > > > DOTS server upon expiry of the associated TTL. > > > > > > > > > > > > > > > > > > To remove ambiguity over the use of FQDN, this could > > > > > > > > > read > > > > > > > > > > > > > > > > > > A DOTS client MUST NOT use an alternate IP address > > > > > > > > > to > > > contact > > > > its > > > > > > > > > DOTS server upon expiry of the associated TTL. > > > > > > > > > Furthermore, a > > > > > > DOTS > > > > > > > > > Client MUST NOT use the alt-server FQDN if all of > > > > > > > > > the > > > > > > > > > alt-server- > > > > > > > > records > > > > > > > > > have expired. > > > > > > > > > > > > > > > > > > Or alternatively > > > > > > > > > > > > > > > > > > alt-server: FQDN of an alternate DOTS server. > > > > > > > > > > > > > > > > > > This could read > > > > > > > > > > > > > > > > > > alt-server: FQDN of an alternate DOTS server. This > > > > > > > > > FQDN is not to be > > > > > > > > used for > > > > > > > > > looking up IP addresses to use, but is there for the SNI > > > > > > > > > extension > > > > > > (7.1. > > > > > > > > (D)TLS > > > > > > > > > Protocol Profile) > > > > > > > > > > > > > > > > I don't think the above restriction is correct for the > > > > > > > > following > > > > reasons: > > > > > > > > > > > > > > > > 1) If the TTL value in the alt-server-record expires, DNS > > > > > > > > lookup can be performed by the DOTS client using the > > > > > > > > alternate DOTS > > > server > > > > FQDN. > > > > > > > > 2) If the DNS server is reachable, the client may want to > > > > > > > > a DANE lookup to get the IP addresses and certificate to > > > > > > > > validate the alternate DOTS server certificate sent > > > > > > > > in the DTLS handshake. > > > > > > > > > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > Jon > > > > > > > > > -----Original Message----- > > > > > > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > > > > > > > > mohamed.boucadair@orange.com > > > > > > > > > Sent: 05 April 2018 08:20 > > > > > > > > > To: Konda, Tirumaleswar Reddy; Jon Shallow; > > > > > > > > > dots@ietf.org > > > > > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected > > > > > > > > > Signaling > > > > > > > > > > > > > > > > > > Hi Tiru, > > > > > > > > > > > > > > > > > > Works for me. > > > > > > > > > > > > > > > > > > I updated the draft with the text additions that were > > > > > > > > > discussed in this thread. The changes can be found at: > > > > > > > > > https://github.com/boucadair/draft-ietf-dots-signal- > > > > > > > > channel/blob/master/draf > > > > > > > > > t-ietf-dots-signal-channel.txt > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > Med > > > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Konda, Tirumaleswar > > > > > > > > > > Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > > > > > Envoy=E9=A0: mercredi 4 avril 2018 17:40 =C0=A0: Jon Sh= allow; > > > > > > > > > > BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet=A0: RE: > > > > > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > > > > > > The TTL value returned under alt-server-record is > > > > > > > > > > equivalent to the DNS TTL value. A DDoS mitigation > > > > > > > > > > provider with multiple DOTS servers typically > > > > > > > > > > re-directs a DOTS client to a different DOTS server > > > > > > > > > > only if the alternate DOTS server has the capacity to > > > > > > > > > > handle the requests from the > > > > > > > > > DOTS client. > > > > > > > > > > > > > > > > > > > > We can add the following lines to avoid loops : > > > > > > > > > > > > > > > > > > > > If the DOTS client has been redirected to a DOTS > > > > > > > > > > server to which it has already sent the mitigation > > > > > > > > > > request within the last five minutes, it MUST ignore > > > > > > > > > > the redirection and try reaching others servers listed > > > > > > > > > > in the local configuration or discovered using dynamic > > > > > > > > > > means > > such as DHCP or SRV procedures. > > > > > > > > > > This prevents infinite ping-ponging between servers in > > > > > > > > > > case of redirection loops. > > > > > > > > > > > > > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf > > > > > > > > > > > Of Jon Shallow > > > > > > > > > > > Sent: Wednesday, April 4, 2018 8:16 PM > > > > > > > > > > > To: mohamed.boucadair@orange.com; dots@ietf.org > > > > > > > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected > > > > > > > > > > > Signaling > > > > > > > > > > > > > > > > > > > > > > Hi there, > > > > > > > > > > > > > > > > > > > > > > See inline [Jon] > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf > > > > > > > > > > > Of mohamed.boucadair@orange.com > > > > > > > > > > > Sent: 04 April 2018 15:07 > > > > > > > > > > > To: Jon Shallow; dots@ietf.org > > > > > > > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected > > > > > > > > > > > Signaling > > > > > > > > > > > > > > > > > > > > > > Re-, > > > > > > > > > > > > > > > > > > > > > > Please see inline. > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > Med > > > > > > > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Dots > > > > > > > > > > > > [mailto:dots-bounces@ietf.org] De la part de Jon > > > > > > > > > > > > Shallow Envoy=E9=A0: mercredi 4 avril 2018 15:31 = =C0=A0: > > > > > > > > > > > > dots@ietf.org > > > > > > Objet=A0: > > > > > > > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > > > Hi there, > > > > > > > > > > > > > > > > > > > > > > > > I have implemented the 300 Redirected-Signal in my > > > > > > > > > > > > DOTS > > > code. > > > > > > > > > > > > This then raises some questions about usability. > > > > > > > > > > > > > > > > > > > > > > > > Usability #1 > > > > > > > > > > > > > > > > > > > > > > > > Architecture 3.2.2 Redirected Signalling > > > > > > > > > > > > > > > > > > > > > > > > 4. Having redirected the DOTS client, DOTS > > > > > > > > > > > > server A ceases > > > > > > > > sending > > > > > > > > > > > > server signals. The DOTS client likewise > > > > > > > > > > > > stops sending > > > > > > client > > > > > > > > > > > > signals to DOTS server A. DOTS session 1 > > > > > > > > > > > > is > > > > terminated. > > > > > > > > > > > > > > > > > > > > > > > > Clearly indicates that the original session > > > > > > > > > > > > (Client to Server > > > > > > > > > > > > A) is no more once redirected and only Client to > > > > > > > > > > > > Server B is in > > > > > > use. > > > > > > > > > > > > > > > > > > > > > > > > How is the traffic redirected back to Server A > > > > > > > > > > > > once maintenance / overloading etc. has finished? > > > > > > > > > > > > My assumption is that Server B sends a redirect to > > > > > > > > > > > > go back to Server A as Server A has no way to say > > > > > > > > > > > > over a now non-existent session to say > > > > > > > "come back". > > > > > > > > > > > > > > > > > > > > > > [Med] That's one possibility. This one does not > > > > > > > > > > > require any update to the > > > > > > > > > > signal- > > > > > > > > > > > channel specification. > > > > > > > > > > > > > > > > > > > > > > Another approach would be to not require any > > > > > > > > > > > redirect signal from server > > > > > > > > > B. > > > > > > > > > > > The client will remove server B's records upon the > > > > > > > > > > > expiry of the TTL and > > > > > > > > > > will fall > > > > > > > > > > > back to the "base" DOTS servers configuration that > > > > > > > > > > > was provisioned to the > > > > > > > > > > client > > > > > > > > > > > using DHCP or whatever mechanism. > > > > > > > > > > > [Jon] OK. The TTL is defined at, associated with > > > > > > > > > > > the IP address level > > > > > > > > > > under alt- > > > > > > > > > > > server-record, not under > > > > > > > > > > > ietf-dots-signal-channel:redirected-signal. The ttl > > > > definition is > > > > > > > > > > > ambiguous as to what it refers to and perhaps could > > > > > > > > > > > be tightened up in the language (I read it as being > > > > > > > > > > > associated with "addr" in the sense of a DNS > > > > > > > > > > TTL). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Do we need to keep the existing Client to Server A > > > > > > > > > > > > session warm (or perhaps to probe periodically) to > > > > > > > > > > > > see if Server A is capable of handling the Client > > > > > > > > > > > > again by a server response extension to the > > > > > > > > > > > > protocol (e.g. a 3.01) > > > > > > > > > > > > > > > > > > > > > > [Med] Redirect was initially introduced to manage a > > > > > > > > > > > server overload, so I > > > > > > > > > > don't > > > > > > > > > > > think it makes sense to probe or maintain a session > > > > > > > > > > > with > > > server > > > > A. > > > > > > > > > > > [Jon] Agreed, but I needed to raise the question. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Should there be a retry period parameter added in > > > > > > > > > > > > to the > > > > > > > > > > > > 3.00 protocol (as I read it, ttl only refers to > > > > > > > > > > > > the IP > > > > address)? > > > > > > > > > > > > > > > > > > > > > > [Med] The client will automatically switch to Server > > > > > > > > > > > A when all alternate > > > > > > > > > > records > > > > > > > > > > > expire. > > > > > > > > > > > [Jon] OK - again the 4.6 text needs to get tightened > > > > > > > > > > > up to reflect this as > > > > > > > > > > the > > > > > > > > > > > intent. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Usability #2 > > > > > > > > > > > > > > > > > > > > > > > > Server A says "Redirect to Server B" due to > overloading. > > > > > > > > > > > > Server B accepts things for a while and then is > > > > > > > > > > > > instructed/decides to redirect traffic back to A. > > > > > > > > > > > > Server A is left still overload configured to > > > > > > > > > > > > redirect to B. How should the client handle this > > > > > > > > > > > > as there is no suitable > > > > > > > > > > > Server? > > > > > > > > > > > > > > > > > > > > > > [Med] This is a service configuration problem. We > > > > > > > > > > > may > ask: > > > > > > > > > > > * the client to log the error and notify the > > administrator. > > > > > > > > > > > * and/or stop the redirection after n cycles. > > > > > > > > > > > > > > > > > > > > > > Still, this does not solve the problem. > > > > > > > > > > > [Jon] Agreed there is a problem here > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I agree that there needs to be co-ordination > > > > > > > > > > > > between Server A and Server B, but user error may > creep in. > > > > > > > > > > > > > > > > > > > > > > > > Usability #3 > > > > > > > > > > > > > > > > > > > > > > > > Server A says "Redirect to Server B" as it going > > > > > > > > > > > > to be shut down because of maintenance. Server B > > > > > > > > > > > > accepts things for a while and then is instructed > > > > > > > > > > > > (in probable user > > > > > > > > > > > > error) to redirect traffic back to A (perhaps > > > > > > > > > > > > because it has hit an overload condition). How > > > > > > > > > > > > should the client > > > > > > > > > > > handle this? > > > > > > > > > > > > > > > > > > > > > > [Med] Isn't this a sub-case or #2? > > > > > > > > > > > [Jon] Yes, but I wanted to bring in Server A being > > > > > > > > > > > alive and able to > > > > > > > > > > respond > > > > > > > > > > > versus Server A down and not responding due to > > maintenance. > > > > > > > > > > > [Jon] With my better understanding of TTL we still > > > > > > > > > > > have an issue if the TTL expires and Server A is > > > > > > > > > > > having an extended > > > > outage. > > > > > > > > > > > How do we recover from that? > > > > > > > > > > > ~jon > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > Dots mailing list > > > > > > > > > > > > Dots@ietf.org > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > Dots mailing list > > > > > > > > > > > Dots@ietf.org > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > Dots mailing list > > > > > > > > > > > Dots@ietf.org > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > Dots mailing list > > > > > > > > > Dots@ietf.org > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Dots mailing list > > > > > > > Dots@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > _______________________________________________ > > > > Dots mailing list > > > > Dots@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots > > >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Fri Apr 6 08:19:48 2018 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 EAA0F127137 for ; Fri, 6 Apr 2018 08:19:46 -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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 W1TIVySkQDiL for ; Fri, 6 Apr 2018 08:19:44 -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 A9624120726 for ; Fri, 6 Apr 2018 08:19:43 -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=1523027982; 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: dlp-product:dlp-version:dlp-reaction: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-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: 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=E k2L4vedvUndUBjpD0qHBaxlAMjALySBU95ux4FscL 4=; b=Y3Pg61FRnMaXVb4kidCZXoN8TZGP02aB4zMpL81ENZBu ZIrFHtsZjrFIKZoIvABE180y9efIt31IAiB3eNjGSeLXXznjJx D9PjiskJ0ty0MxmaqIbK/votPi+v2NIciSk8fNees2bAYKnL8T lR8fBK6X4schcL2FRJOZZLHJnYM= Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 3b6c_2073_4a0999f4_09cc_46a0_9ca0_626369bc9bce; Fri, 06 Apr 2018 10:19:42 -0500 Received: from DNVEXUSR1N11.corpzone.internalzone.com (10.44.48.84) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 6 Apr 2018 09:19:06 -0600 Received: from DNVEXUSR1N10.corpzone.internalzone.com (10.44.48.83) by DNVEXUSR1N11.corpzone.internalzone.com (10.44.48.84) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 6 Apr 2018 09:19:05 -0600 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXUSR1N10.corpzone.internalzone.com (10.44.48.83) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Fri, 6 Apr 2018 09:19:04 -0600 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (10.44.176.240) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 6 Apr 2018 09:19:04 -0600 Received: from BN6PR16MB1425.namprd16.prod.outlook.com (10.172.207.19) by BN6PR16MB1492.namprd16.prod.outlook.com (10.172.207.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.653.12; Fri, 6 Apr 2018 15:19:03 +0000 Received: from BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d]) by BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d%2]) with mapi id 15.20.0653.012; Fri, 6 Apr 2018 15:19:03 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: [Dots] IETF 101 Presentation Data Channel Issue #4 Thread-Index: AdPE/QAkDtOD9YeqSAaov9+szxQnSQAoMdfAAAKPC+AAA+QiAAAEVj7wAfiJ0YAAA7+48A== Date: Fri, 6 Apr 2018 15:19:02 +0000 Message-ID: References: <008401d3c4fd$216d0840$644718c0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF1067@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <014801d3c5b7$94c67f00$be537d00$@jpshallow.com> <009a01d3cdab$150b4c40$3f21e4c0$@jpshallow.com> In-Reply-To: <009a01d3cdab$150b4c40$3f21e4c0$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [122.172.69.219] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR16MB1492; 7:gG3HssCYJqHqALSX4HwoQtF8EHNgz28ke8xYHVOl1bJ943zr3L47hsznII+WX/pyqBnAfXTU21ekOwl9jG2PIMzxx/n/ckZMF4SRtcEo4ZhCw6Wv8tllTLNtmZ/WuXIWRgIMDfWxQ5KD0Sw4HHLyhpx3drgKMKu9rBDAutf5OyV0FkApITA1G0UBco16IbW0VR1/GkotXomk28j+/d8gQCxsoFAj5DFbdZEvFjD74NbJf5pp0+aCzTiahmyn8NUy x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 017dfa7e-cbe6-45c2-0815-08d59bd1bb33 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BN6PR16MB1492; x-ms-traffictypediagnostic: BN6PR16MB1492: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(192374486261705)(18271650672692)(21748063052155)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(3231221)(944501327)(52105095)(10201501046)(93006095)(93001095)(6041310)(20161123558120)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011); SRVR:BN6PR16MB1492; BCL:0; PCL:0; RULEID:; SRVR:BN6PR16MB1492; x-forefront-prvs: 0634F37BFF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(346002)(39860400002)(39380400002)(376002)(199004)(5383002)(189003)(32952001)(14454004)(7696005)(66066001)(74316002)(7736002)(86362001)(8676002)(3846002)(486006)(72206003)(26005)(2201001)(99286004)(478600001)(186003)(5660300001)(6506007)(97736004)(54896002)(106356001)(105586002)(80792005)(6436002)(68736007)(6116002)(102836004)(790700001)(25786009)(81166006)(3280700002)(2501003)(81156014)(19609705001)(33656002)(5250100002)(53936002)(59450400001)(2906002)(446003)(8936002)(229853002)(76176011)(2900100001)(53546011)(9686003)(110136005)(6246003)(476003)(6306002)(236005)(55016002)(345774005)(316002)(93886005)(11346002)(3660700001)(91024005)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR16MB1492; H:BN6PR16MB1425.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: Xnb9SIghTSgQhZZKo5GSKYVr4NejRSSSiJ1UnRA1ZpwTAwMJT1DrzDEB8tve4JyJnHWf8L2HXMiyhwfp6ODL91lnQvQJiIdJlSw6WRYYJHUzX1je/T4qthvcwCoRUNYtWs0v/79d6pCL6SZowGqQTOlFn5QJz99oF4H0YKsmaJOYOblyq3zUFp5DjwjX762GSMfLL/FKFToyv0n0jFBkDwt7uEVdDJ4evvzWQS+M3vlh3+qNVko3TjMMyu7nSJ7ED0zMTBYSAhjsnYQm9O4Ni+es6YuDLXbEksoGcJeltjwYlDmBZZPxUuabXDAromE1UpC6/rohQHG1XTm6yQATBB7IA+lFMMkBu6kokRL2vMANqgFwTXc0QCDPzErI4tPo/BlscBGrQvaISekLqqNedhntDCZmM0cN7SRSlCL/Zbc= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR16MB1425D60620377BBD8C0E0FC7EABA0BN6PR16MB1425namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 017dfa7e-cbe6-45c2-0815-08d59bd1bb33 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2018 15:19:03.1294 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR16MB1492 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 <6259> : inlines <6552> : streams <1783374> : uri <2621492> Archived-At: Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 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, 06 Apr 2018 15:19:47 -0000 --_000_BN6PR16MB1425D60620377BBD8C0E0FC7EABA0BN6PR16MB1425namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I don't understand how the DOTS server/mitigation will fill it in at time o= f ACE instantiation, and why can't the DOTS client fill the destination net= work details ? -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Friday, April 6, 2018 6:58 PM To: Konda, Tirumaleswar Reddy ; mohamed= .boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 Hi there, There is no current way to request of a DOTS Server as to what is the set o= f IP networks that a DOTS client can use either within a mitigation request= or to set up an ACL other than by "testing for ok or not ok" with lots of = different IP addresses. There is a reasonable likelihood of the scope of valid IPs from the Server'= s perspective will change over time. So, unless a DOTS client wants to con= trol a specific destination network, then my suggestion would be to leave t= he ACE destination network empty and for the DOTS Server / DOTS mitigator (= how is out of scope) to fill it in at time of ACE instantiation. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 27 March 2018 13:49 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 Please see inline [TR] From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Tuesday, March 27, 2018 4:07 PM To: Konda, Tirumaleswar Reddy >; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 Hi Tiru / Med See inline [Jon] Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 27 March 2018 09:47 To: mohamed.boucadair@orange.com; Jon = Shallow; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 I also support to mandate destination-network for immediately enforced filt= ering rules. [Jon] This can be enforced / inserted by the DOTS Server for all the destin= ation networks of the domain that the DOTS client 'belongs' to. That said,= it would be good to always have the destination network in an ACL as it ca= n be validated and cross-checked whenever the legitimate set of domain prot= ected IPs are updated. [Jon] However, what happens to the Destination network in the case of a cal= l home DOTS client that becomes a quasi DOTS server and the Destination net= works are somewhere out on the Internet? [TR] DDOS is a targeted attack, so the DOTS client can specify the destinat= ion network targeted by devices in the DOTS server domain and the DOTS serv= er can validate if the destination network is indeed targeted by its device= s. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed..boucadair@o= range.com Sent: Tuesday, March 27, 2018 1:09 PM To: Jon Shallow >; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 Hi Jon, Thank you for the comments. Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : lundi 26 mars 2018 14:23 =C0 : dots@ietf.org Objet : [Dots] IETF 101 Presentation Data Channel Issue #4 Hi there, As per Med's presentation to the IETF 101 Issue #4: Per-Domain or Per-client Filters? * Conclusion - Filters that are activated only during mitigation time are on a per-clien= t basis * Filters are per-domain when are immediately applied "Filters are per-domain when are immediately applied" is what I have an cha= llenge with. If we have a compromised or rogue DOTS client, the simple use of something = like curl, along with the client certificates etc. can be used to generate = any ACL with activation-type :=3D 'immediate' which is then immediately app= lied for all traffic within the domain as per the above. [Med] Yes. FWIW, this attack is called out in the security considerations s= ection: "Nevertheless, an attacker who can access a DOTS client is technically capable of launching various attacks, such as: ..; o Set invalid ACL entries, which may prevent legitimate traffic from being forwarded. Likewise, invalid ACL entries may lead to forward DDoS traffic. " [Jon] Agreed that the attack is covered off in the Security section, but we= should be limiting the possibility / scope of the attack vector by enforci= ng some rules as to what is / is not allowed. Allowing a DOTS client to be= able to affect all the traffic within the domain is a huge risk to me and = should not be allowed. So, a ACL that blacklists the DNS server, or drops all port 443 traffic etc= . can easily cause all of the other clients / devices within the domain to = be taken off air. Putting the intelligence into the DOTS server to not all= ow this to happen could be a challenge. [The signal channel is much harder to compromise and affect traffic flows t= o other areas within the domain] I believe that an ACL instantiated by a DOTS client (immediate or when-miti= gating) should only apply to the DOTS client's traffic which means that the= destination-network has to be a part of the ACL, whether implicitly added = by the DOTS server, or by the DOTS client and suitably validated. [Med] Putting aside that I don't parse "DOTS client's traffic", [Jon] I was referring to all the traffic flows that a DOTS client can legit= imately request control of to the DOTS server that are within the scope of = what the DOTS client is protecting (which may or may not be the DOTS client= 's IP address). I interpret your answer as a support to this question raised for issue #4: * "Should we mandate destination-network to be present for immediate= ly enforced filters?" [Jon] See response to Tiru's Agreement above. ~Jon There is nothing to stop the DOTS server or DOTS mitigator merging common A= CLs to reduce the number of ACLs within the mitigation device. As a side note "mitigation-time" is perhaps a bad name as it implies a time= period - something like "when-mitigating" to me is clearer. [Med] Fixed in my local copy. Thank you. Regards Jon --_000_BN6PR16MB1425D60620377BBD8C0E0FC7EABA0BN6PR16MB1425namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I don’t understand how the DOTS server/mitigation = will fill it in at time of ACE instantiation, and why can’t the DOTS = client fill the destination network details ?

 

-Tiru

 

From:<= /span> Jon Shallow [mailto:s= upjps-ietf@jpshallow.com]
Sent: Friday, April 6, 2018 6:58 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; mohamed.boucadair@orange.com; dots@ietf.org
Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Hi ther= e,

&n= bsp;

There i= s no current way to request of a DOTS Server as to what is the set of IP ne= tworks that a DOTS client can use either within a mitigation request or to = set up an ACL other than by “testing for ok or not ok” with lots of different IP addresses.=

&n= bsp;

There i= s a reasonable likelihood of the scope of valid IPs from the Server’s= perspective will change over time.  So, unless a DOTS client wants to= control a specific destination network, then my suggestion would be to leave the ACE destination network empty and for the= DOTS Server / DOTS mitigator (how is out of scope) to fill it in at time o= f ACE instantiation.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 27 March 2018 13:49
To: Jon Shallow; moh= amed.boucadair@orange.com; dots@ietf.org
Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Please se= e inline [TR]

&nbs= p;

From:<= /span> Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Tuesday, March 27, 2018 4:07 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; mohamed.boucadair@orange.co= m; dots@ietf.org
Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Hi Tiru= / Med

&n= bsp;

See inl= ine [Jon]

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 27 March 2018 09:47
To: mohamed.boucadai= r@orange.com; Jon Shallow; dots@ietf.org
Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

I also su= pport to mandate destination-network for immediately enforced filtering rul= es.

[Jon] This can be enforced / inserted by the DOTS Server for all the d= estination networks of the domain that the DOTS client ‘belongs’= ; to.  That said, it would be good to always have the destination network in an ACL as it can be validated and cross-checked= whenever the legitimate set of domain protected IPs are updated.

[Jon] However, what happens to the Destination network in the case of = a call home DOTS client that becomes a quasi DOTS server and the Destinatio= n networks are somewhere out on the Internet?

&nbs= p;

[TR] DDOS= is a targeted attack, so the DOTS client can specify the destination netwo= rk targeted by devices in the DOTS server domain and the DOTS server can va= lidate if the destination network is indeed targeted by its devices.

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed= ..boucadair@orange.com
Sent: Tuesday, March 27, 2018 1:09 PM
To: Jon Shallow <sup= jps-ietf@jpshallow.com>; dots@ietf.org
Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Hi Jon,

 

Thank you for the comments.<= /p>

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow
Envoy=E9 : lundi 26 mars 2018 14:23
=C0 : dots@ietf.org
Objet : [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Hi there,

 

As per Med’s presentation= to the IETF 101

 

Issue #4: Per-Domain or Per-cli= ent Filters?

 

• Conclusion

– Filters that are activa= ted only during mitigation time are on a per-client basis=

   • Filters ar= e per-domain when are immediately applied

 

“Filters are per-domain w= hen are immediately applied” is what I have an challenge with.

 

If we have a compromised or rog= ue DOTS client, the simple use of something like curl, along with the clien= t certificates etc. can be used to generate any ACL with activation-type := =3D ‘immediate’ which is then immediately applied for all traffic within the domain as per the above.

 

[Med] Yes. FWIW, this attack is= called out in the security considerations section:

 

“Nevertheless,=
 an

   attacker who can acce= ss a DOTS client is technically capable of

   launching various att= acks, such as:

 

..;

 

   o  Set invalid ACL entries, which may prevent legiti=
mate traffic from
      being forwarded.  Likewise, invali=
d ACL entries may lead to
      forward DDoS traffic.=

“

[Jon] A= greed that the attack is covered off in the Security section, but we should= be limiting the possibility / scope of the attack vector by enforcing some= rules as to what is / is not allowed.  Allowing a DOTS client to be able to affect all the traffic within the dom= ain is a huge risk to me and should not be allowed.

 

So, a ACL that blacklists the D= NS server, or drops all port 443 traffic etc. can easily cause all of the o= ther clients / devices within the domain to be taken off air.  Putting= the intelligence into the DOTS server to not allow this to happen could be a challenge.

[The signal channel is much har= der to compromise and affect traffic flows to other areas within the domain= ]

 

I believe that an ACL instantia= ted by a DOTS client (immediate or when-mitigating) should only apply to th= e DOTS client’s traffic which means that the destination-network has = to be a part of the ACL, whether implicitly added by the DOTS server, or by the DOTS client and suitably validated.

 

[Med] Putting aside that I don&= #8217;t parse “DOTS client’s traffic”,

[Jon] I= was referring to all the traffic flows that a DOTS client can legitimately= request control of to the DOTS server that are within the scope of what th= e DOTS client is protecting (which may or may not be the DOTS client’s IP address).

I interpret your answer as a su= pport to this question raised for issue #4:

    • “Should we mandate destination-network to be present for immediately enforced filters?”

[Jon] S= ee response to Tiru’s Agreement above.

~Jon

There is nothing to stop the DO= TS server or DOTS mitigator merging common ACLs to reduce the number of ACL= s within the mitigation device.

 

As a side note “mitigatio= n-time” is perhaps a bad name as it implies a time period – som= ething like “when-mitigating” to me is clearer.

[Med] Fixed in my local copy. T= hank you.

 

Regards

 

Jon

--_000_BN6PR16MB1425D60620377BBD8C0E0FC7EABA0BN6PR16MB1425namp_-- From nobody Fri Apr 6 08:44:33 2018 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 ABE75126BF7 for ; Fri, 6 Apr 2018 08:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TGhJoMgKXEIT for ; Fri, 6 Apr 2018 08:44:29 -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 D48DB1204DA for ; Fri, 6 Apr 2018 08:44:28 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.90_1) (envelope-from ) id 1f4TXP-0001UK-2Q; Fri, 06 Apr 2018 16:44:27 +0100 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , , References: <008401d3c4fd$216d0840$644718c0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF1067@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <014801d3c5b7$94c67f00$be537d00$@jpshallow.com> <009a01d3cdab$150b4c40$3f21e4c0$@jpshallow.com> In-Reply-To: Date: Fri, 6 Apr 2018 16:44:26 +0100 Message-ID: <00cf01d3cdbe$24876650$6d9632f0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D0_01D3CDC6.864E3F50" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGlexwLZckIYJuvKwEmwuQr1rXL6AKpdMHOAgMRKpIBsBKRFgKXgqsdAxHSSssB/GODuqPgbq/A Content-Language: en-gb Archived-At: Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 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, 06 Apr 2018 15:44:31 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00D0_01D3CDC6.864E3F50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Tiru, =20 The DOTS server is likely to have a scope of IP addresses that are valid = for the client to ask for protection for based on the cuid or cdid. =20 The DOTS client may have some knowledge of the scope IPs by some out of = band method, but programmatically cannot ask the server what they are.=20 =20 If a client specifies a destination network that is out of the valid = scope of IP addresses, then the ACE request will get rejected. The client may then have a challenge to work out what destination networks it is = allowed to use. =20 How does a client set up a blacklist for all the IPS within his allowed scope if it does not know what the scope is? =20 If the client has not provided a destination network, then the DOTS = server can auto-fill in the missing information at the time of the ACE instantiation =96 and this then handles if the scope of IP addresses = change. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 06 April 2018 16:19 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 =20 I don=92t understand how the DOTS server/mitigation will fill it in at = time of ACE instantiation, and why can=92t the DOTS client fill the destination network details ? =20 -Tiru =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Friday, April 6, 2018 6:58 PM To: Konda, Tirumaleswar Reddy ; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 =20 Hi there, =20 There is no current way to request of a DOTS Server as to what is the = set of IP networks that a DOTS client can use either within a mitigation = request or to set up an ACL other than by =93testing for ok or not ok=94 with lots = of different IP addresses. =20 There is a reasonable likelihood of the scope of valid IPs from the = Server=92s perspective will change over time. So, unless a DOTS client wants to control a specific destination network, then my suggestion would be to = leave the ACE destination network empty and for the DOTS Server / DOTS = mitigator (how is out of scope) to fill it in at time of ACE instantiation. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 27 March 2018 13:49 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 =20 Please see inline [TR] =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Tuesday, March 27, 2018 4:07 PM To: Konda, Tirumaleswar Reddy ; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 =20 Hi Tiru / Med =20 See inline [Jon] =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 27 March 2018 09:47 To: mohamed.boucadair@orange.com; Jon Shallow; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 =20 I also support to mandate destination-network for immediately enforced filtering rules. [Jon] This can be enforced / inserted by the DOTS Server for all the destination networks of the domain that the DOTS client =91belongs=92 = to. That said, it would be good to always have the destination network in an ACL = as it can be validated and cross-checked whenever the legitimate set of = domain protected IPs are updated. [Jon] However, what happens to the Destination network in the case of a = call home DOTS client that becomes a quasi DOTS server and the Destination networks are somewhere out on the Internet? =20 [TR] DDOS is a targeted attack, so the DOTS client can specify the destination network targeted by devices in the DOTS server domain and = the DOTS server can validate if the destination network is indeed targeted = by its devices. =20 -Tiru =20 From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed...boucadair@orange.com =20 Sent: Tuesday, March 27, 2018 1:09 PM To: Jon Shallow ; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 =20 Hi Jon,=20 =20 Thank you for the comments. =20 Please see inline. =20 Cheers, Med =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : lundi 26 mars 2018 14:23 =C0 : dots@ietf.org Objet : [Dots] IETF 101 Presentation Data Channel Issue #4 =20 Hi there, =20 As per Med=92s presentation to the IETF 101 =20 Issue #4: Per-Domain or Per-client Filters? =20 =95 Conclusion =96 Filters that are activated only during mitigation time are on a = per-client basis =95 Filters are per-domain when are immediately applied =20 =93Filters are per-domain when are immediately applied=94 is what I have = an challenge with. =20 If we have a compromised or rogue DOTS client, the simple use of = something like curl, along with the client certificates etc. can be used to = generate any ACL with activation-type :=3D =91immediate=92 which is then = immediately applied for all traffic within the domain as per the above. =20 [Med] Yes. FWIW, this attack is called out in the security = considerations section:=20 =20 =93Nevertheless, an attacker who can access a DOTS client is technically capable of launching various attacks, such as: =20 ..; =20 o Set invalid ACL entries, which may prevent legitimate traffic from being forwarded. Likewise, invalid ACL entries may lead to forward DDoS traffic. =93 [Jon] Agreed that the attack is covered off in the Security section, but = we should be limiting the possibility / scope of the attack vector by = enforcing some rules as to what is / is not allowed. Allowing a DOTS client to be able to affect all the traffic within the domain is a huge risk to me = and should not be allowed. =20 So, a ACL that blacklists the DNS server, or drops all port 443 traffic = etc. can easily cause all of the other clients / devices within the domain to = be taken off air. Putting the intelligence into the DOTS server to not = allow this to happen could be a challenge. [The signal channel is much harder to compromise and affect traffic = flows to other areas within the domain] =20 I believe that an ACL instantiated by a DOTS client (immediate or when-mitigating) should only apply to the DOTS client=92s traffic which = means that the destination-network has to be a part of the ACL, whether = implicitly added by the DOTS server, or by the DOTS client and suitably validated. =20 [Med] Putting aside that I don=92t parse =93DOTS client=92s traffic=94, [Jon] I was referring to all the traffic flows that a DOTS client can legitimately request control of to the DOTS server that are within the = scope of what the DOTS client is protecting (which may or may not be the DOTS client=92s IP address). I interpret your answer as a support to this question raised for issue = #4: * =93Should we mandate destination-network to be present for immediately enforced filters?=94 [Jon] See response to Tiru=92s Agreement above. ~Jon There is nothing to stop the DOTS server or DOTS mitigator merging = common ACLs to reduce the number of ACLs within the mitigation device. =20 As a side note =93mitigation-time=94 is perhaps a bad name as it implies = a time period =96 something like =93when-mitigating=94 to me is clearer. [Med] Fixed in my local copy. Thank you. =20 Regards =20 Jon ------=_NextPart_000_00D0_01D3CDC6.864E3F50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

The DOTS server is = likely to have a scope of IP addresses that are valid for the client to = ask for protection for based on the cuid or = cdid.

 

The DOTS client may have = some knowledge of the scope IPs by some out of band method, but = programmatically cannot ask the server what they are. =

 

If a client specifies a = destination network that is out of the valid scope of IP addresses, then = the ACE request will get rejected.=A0 The client may then have a = challenge to work out what destination networks it is allowed to = use.

 

How does a client set up = a blacklist for all the IPS within his allowed scope if it does not know = what the scope is?

 

If the client has not = provided a destination network, then the DOTS server can auto-fill in = the missing information at the time of the ACE instantiation – and = this then handles if the scope of IP addresses = change.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = Konda, Tirumaleswar Reddy
Sent: 06 April 2018 = 16:19
To: Jon Shallow; mohamed.boucadair@orange.com; = dots@ietf.org
Subject: Re: [Dots] IETF 101 Presentation Data = Channel Issue #4

 

I don’t understand how the = DOTS server/mitigation will fill it in at time of ACE instantiation, and = why can’t the DOTS client fill the destination network details = ?

 

-Tiru

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Friday, April 6, 2018 6:58 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: RE: = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

Hi there,

 

There is no current way = to request of a DOTS Server as to what is the set of IP networks that a = DOTS client can use either within a mitigation request or to set up an = ACL other than by “testing for ok or not ok” with lots of = different IP addresses.

 

There is a reasonable = likelihood of the scope of valid IPs from the Server’s perspective = will change over time.  So, unless a DOTS client wants to control a = specific destination network, then my suggestion would be to leave the = ACE destination network empty and for the DOTS Server / DOTS mitigator = (how is out of scope) to fill it in at time of ACE = instantiation.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 27 March 2018 = 13:49
To: Jon Shallow; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: Re: = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

Please see inline = [TR]

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Tuesday, March 27, 2018 4:07 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: RE: = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

Hi Tiru / Med

 

See inline = [Jon]

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 27 March 2018 = 09:47
To: mohamed.boucadair@orange.com= ; Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

I also support to = mandate destination-network for immediately enforced filtering = rules.

[Jon] This can be = enforced / inserted by the DOTS Server for all the destination networks = of the domain that the DOTS client ‘belongs’ to.  That = said, it would be good to always have the destination network in an ACL = as it can be validated and cross-checked whenever the legitimate set of = domain protected IPs are updated.

[Jon] However, what = happens to the Destination network in the case of a call home DOTS = client that becomes a quasi DOTS server and the Destination networks are = somewhere out on the Internet?

 

[TR] DDOS is a targeted attack, so = the DOTS client can specify the destination network targeted by devices = in the DOTS server domain and the DOTS server can validate if the = destination network is indeed targeted by its = devices.

 

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of mohamed...boucadair@orange.c= om
Sent: Tuesday, March 27, 2018 1:09 PM
To: Jon = Shallow <supjps-ietf@jpshallow.com&g= t;; dots@ietf.org
Subject: Re: = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

Hi Jon,

 

Thank you for the comments.

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] = De la part de Jon Shallow
Envoy=E9 : lundi 26 mars = 2018 14:23
=C0 : dots@ietf.org
Objet : = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

Hi = there,

 

As per Med’s presentation to the IETF = 101

 

Issue #4: Per-Domain or Per-client = Filters?

 

• Conclusion

– Filters that are activated only during = mitigation time are on a per-client basis

   • Filters are per-domain when are = immediately applied

 

“Filters are per-domain when are immediately = applied” is what I have an challenge with.

 

If we have a = compromised or rogue DOTS client, the simple use of something like curl, = along with the client certificates etc. can be used to generate any ACL = with activation-type :=3D ‘immediate’ which is then = immediately applied for all traffic within the domain as per the = above.

 

[Med] = Yes. FWIW, this attack is called out in the security considerations = section:

 

“Nevertheless, =
an

   attacker who can access a = DOTS client is technically capable of

   launching various attacks, = such as:

 

..;

 

   o  Set invalid ACL entries, which may =
prevent legitimate traffic from
      being forwarded.  =
Likewise, invalid ACL entries may lead =
to
      forward DDoS traffic.

“

[Jon] Agreed that the = attack is covered off in the Security section, but we should be limiting = the possibility / scope of the attack vector by enforcing some rules as = to what is / is not allowed.  Allowing a DOTS client to be able to = affect all the traffic within the domain is a huge risk to me and should = not be allowed.

 

So, a ACL = that blacklists the DNS server, or drops all port 443 traffic etc. can = easily cause all of the other clients / devices within the domain to be = taken off air.  Putting the intelligence into the DOTS server to = not allow this to happen could be a challenge.

[The signal channel is much harder to compromise and = affect traffic flows to other areas within the domain]

 

I believe = that an ACL instantiated by a DOTS client (immediate or when-mitigating) = should only apply to the DOTS client’s traffic which means that = the destination-network has to be a part of the ACL, whether implicitly = added by the DOTS server, or by the DOTS client and suitably = validated.

 

[Med] = Putting aside that I don’t parse “DOTS client’s = traffic”,

[Jon] I was referring to all the traffic flows = that a DOTS client can legitimately request control of to the DOTS = server that are within the scope of what the DOTS client is protecting = (which may or may not be the DOTS client’s IP = address).

I = interpret your answer as a support to this question raised for issue = #4:

    • “Should = we mandate destination-network to be present for immediately enforced = filters?”

[Jon] See response to = Tiru’s Agreement above.

~Jon

There is nothing to stop the DOTS server or DOTS = mitigator merging common ACLs to reduce the number of ACLs within the = mitigation device.

 

As a side = note “mitigation-time” is perhaps a bad name as it implies a = time period – something like “when-mitigating” to me = is clearer.

[Med] = Fixed in my local copy. Thank you.

 

Regards

 

Jon

= ------=_NextPart_000_00D0_01D3CDC6.864E3F50-- From nobody Fri Apr 6 21:58:33 2018 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 F1C54126B6D for ; Fri, 6 Apr 2018 21:58:31 -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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 ZzrU6FRw1srF for ; Fri, 6 Apr 2018 21:58:29 -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 3FC3712420B for ; Fri, 6 Apr 2018 21:58:29 -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=1523077098; 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: dlp-product:dlp-version:dlp-reaction: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-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-Network-Message-Id: 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=d 23NeRwHGXq0FawcZ/hm8VIhyBBb3Dv6kd9FPSSXFE w=; b=DPW/hBncJ/5/5LMCskTscvMTB55dPOu8jfcpm/iOzAj/ r7W/S3k3265SNuTNshnMEqed7VGozpwPlm0Xv5vsM5akIIMRAM rZE2yuttK4T2wCMuOG0S2H5kEGKdsKCHhbRdevuesR3iukY6kq 8i/6rbTRHB3wOr16NRSgB3C0YIY= Received: from DNVEXAPP1N04.corpzone.internalzone.com (unknown [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 0d51_1b9d_70576e78_b80e_4a51_b7fd_4e41aace23fd; Fri, 06 Apr 2018 23:58:17 -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; Fri, 6 Apr 2018 22:58:17 -0600 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXUSR1N12.corpzone.internalzone.com (10.44.48.85) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Fri, 6 Apr 2018 22:58:17 -0600 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (10.44.176.241) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 6 Apr 2018 22:58:17 -0600 Received: from BN6PR16MB1425.namprd16.prod.outlook.com (10.172.207.19) by BN6PR16MB1473.namprd16.prod.outlook.com (10.172.207.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.653.12; Sat, 7 Apr 2018 04:58:15 +0000 Received: from BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d]) by BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d%2]) with mapi id 15.20.0653.012; Sat, 7 Apr 2018 04:58:15 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , "kaname nishizuka" , "dots@ietf.org" Thread-Topic: [Dots] WGLC on DOTS Signal Channel Thread-Index: AdPA/2I8r8JGmyBkSmyI9HwbArIJBwKrEr+AAAxpFAAAATBugAABO8EAAAGuM4AAAmXtgABcmkKAAAOWXAAAK9pXgA== Date: Sat, 7 Apr 2018 04:58:14 +0000 Message-ID: References: <359EC4B99E040048A7131E0F4E113AFC014C36B932@marathon> <68904f77-3cef-4c77-4cfa-3aeaacf95133@nttv6.jp> <787AE7BB302AE849A7480A190F8B93302DEF7927@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7277ba5c-436b-9027-8be0-49c8a53dbde2@nttv6.jp> <787AE7BB302AE849A7480A190F8B93302DEF79C9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEF7B45@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <69de4e41-1761-d02a-616d-85bc340601b4@nttv6.jp> <787AE7BB302AE849A7480A190F8B93302DEF91CB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DEF91CB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [185.221.69.46] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR16MB1473; 7:u/s8GWNm2OWgo0LDnp461q/fwzXg4XEjR1UgO33KnvNCuAV+v+RIWqfgJv64g8twZYE299/K7wpUdo30pikmLjzY/vCtIrIROBV4r33Nx/Yyt/N0Yt1zlS+XjKUWX3H40105A6tir/RhXNa/kbhxnt8J7Tu3Tl7sXehH5FeYYU1IPhAqJ9IvBk2S7iTeu4O3erZx10iYhguXUoKQuMwFD8pZYOt1EJKvkxex0Ao3IwKhf3ufbzsxbvAjVHf89Z60 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 110b1bed-aac6-4d4e-03a8-08d59c442bf2 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BN6PR16MB1473; x-ms-traffictypediagnostic: BN6PR16MB1473: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105)(100405760836317)(18271650672692); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231221)(944501327)(52105095)(10201501046)(3002001)(93006095)(93001095)(6041310)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(20161123560045)(6072148)(201708071742011); SRVR:BN6PR16MB1473; BCL:0; PCL:0; RULEID:; SRVR:BN6PR16MB1473; x-forefront-prvs: 0635D5275E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(346002)(396003)(39380400002)(376002)(55784002)(199004)(189003)(32952001)(13464003)(486006)(9686003)(966005)(6306002)(6436002)(72206003)(476003)(93886005)(86362001)(5660300001)(68736007)(8936002)(53546011)(8676002)(478600001)(6506007)(2906002)(25786009)(53936002)(11346002)(14454004)(66066001)(110136005)(55016002)(3280700002)(316002)(81166006)(446003)(81156014)(2900100001)(6246003)(186003)(74316002)(59450400001)(99286004)(305945005)(5250100002)(3660700001)(105586002)(345774005)(229853002)(26005)(106356001)(7736002)(102836004)(3846002)(33656002)(2501003)(6116002)(80792005)(97736004)(7696005)(76176011)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR16MB1473; H:BN6PR16MB1425.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 8x662dO5+vfUiOvdWkzQFXW1ZKgFB3EzELc178FDpbprE4E9hSag2YxZT5KiKXjTsnnuluqUVVHx3Uf8B6Z/SyMJhS77WhmhsYiMLdEyAjchQAXpYWSCIQZ/Sp1x+12v778QIAfrm458qMm0GXOlHGsEBXYbvavUkOmYC/lSD8N8cIqJbygIdguMagErn6XsS+eVtt1SIgXqIbQraIcR/eI4U7KOIpe8qTauHn0LkwnarrAAX5IBBIpnpA8owa5WvJ8QZJ67+MEH6UZfnL4jD+7098p3naSMGCh0rDZoHDVsgu7v37pHk5w4a5w1ooV/wjO5RuqVbf3NIfS1xqXJewDL13iUQE1/b1VmVfugZKHp6O337uVHW2onThPStQgbbESg2uPg/da0XH4wjQ5wF1Lu01iUmd+UU9ojY/QozqQ= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 110b1bed-aac6-4d4e-03a8-08d59c442bf2 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Apr 2018 04:58:14.8270 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR16MB1473 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 <6259> : inlines <6554> : streams <1783428> : uri <2621804> Archived-At: Subject: Re: [Dots] WGLC on DOTS Signal Channel 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, 07 Apr 2018 04:58:32 -0000 UGxlYXNlIHNlZSBpbmxpbmUNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9t OiBEb3RzIFttYWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4gbW9o YW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbQ0KPiBTZW50OiBGcmlkYXksIEFwcmlsIDYsIDIwMTgg MTI6NTMgUE0NCj4gVG86IGthbmFtZSBuaXNoaXp1a2EgPGthbmFtZUBudHR2Ni5qcD47IGRvdHNA aWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtEb3RzXSBXR0xDIG9uIERPVFMgU2lnbmFsIENoYW5u ZWwNCj4gDQo+IEhpIEthbmFtZSwNCj4gDQo+IFBsZWFzZSBzZWUgaW5saW5lLg0KPiANCj4gQ2hl ZXJzLA0KPiBNZWQNCj4gDQo+ID4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ID4gRGXC oDoga2FuYW1lIG5pc2hpenVrYSBbbWFpbHRvOmthbmFtZUBudHR2Ni5qcF0gRW52b3nDqcKgOiB2 ZW5kcmVkaSA2DQo+ID4gYXZyaWwgMjAxOCAwNzo0MCDDgMKgOiBCT1VDQURBSVIgTW9oYW1lZCBJ TVQvT0xOOyBkb3RzQGlldGYub3JnIE9iamV0wqA6DQo+ID4gUmU6IFtEb3RzXSBXR0xDIG9uIERP VFMgU2lnbmFsIENoYW5uZWwNCj4gPg0KPiA+IEhpIE1lZCwNCj4gPg0KPiA+IFBsZWFzZSBzZWUg aW5saW5lLg0KPiA+DQo+ID4gdGhhbmtzLA0KPiA+IEthbmFtZQ0KPiA+DQo+ID4gT24gMjAxOC8w NC8wNCAxODoyOCwgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSB3cm90ZToNCj4gPiA+IFJl LSwNCj4gPiA+DQo+ID4gPiBUaGFuayB5b3UgZm9yICB0aGUgY29tbWVudHMuDQo+ID4gPg0KPiA+ ID4gUGxlYXNlIHNlZSBpbmxpbmUuDQo+ID4gPg0KPiA+ID4gQ2hlZXJzLA0KPiA+ID4gTWVkDQo+ ID4gPg0KPiA+ID4+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiA+ID4+IERlwqA6IGth bmFtZSBuaXNoaXp1a2EgW21haWx0bzprYW5hbWVAbnR0djYuanBdIEVudm95w6nCoDogbWVyY3Jl ZGkgNA0KPiA+ID4+IGF2cmlsIDIwMTggMTA6MjAgw4DCoDogQk9VQ0FEQUlSIE1vaGFtZWQgSU1U L09MTjsgZG90c0BpZXRmLm9yZyBPYmpldA0KPiA+ID4+IDogUmU6IFtEb3RzXSBXR0xDIG9uIERP VFMgU2lnbmFsIENoYW5uZWwNCj4gPiA+Pg0KPiA+ID4+IEhpIE1lZCwNCj4gPiA+Pg0KPiA+ID4+ IFRoYW5rIHlvdSBmb3IgdGhlIGNsYXJpZmljYXRpb24gYW5kIHRoZSBwcm9wZXIgcmVmZXJlbmNl Lg0KPiA+ID4+IEkgY2FuIG5vdCBhc3N1bWUgdGhhdCBteSBET1RTIGNsaWVudCB3aWxsIGRvIE91 dC1vZi1PcmRlcg0KPiA+ID4+IENvbmZpZ3VyYXRpb24gUmVxdWVzdHMsIGJ1dC4uLiBJIGdvdCB1 bmRlcnN0YW5kIHRoYXQgJ3NpZCcgaXMgdGhlDQo+ID4gPj4gc29sdXRpb24gdG8gb3V0IG9mDQo+ ID4gb3JkZXINCj4gPiA+PiBjb25maWd1cmF0aW9uIHJlcXVlc3RzLg0KPiA+ID4+DQo+ID4gPj4g MiBtb3JlIHF1ZXN0aW9uczoNCj4gPiA+Pg0KPiA+ID4+IDEuIEdFVCB3aXRoIHNpZA0KPiA+ID4+ IE9uIHRoZSBzbGlkZSAxMiwgaXQgaXMgd3JpdHRlbiBpbiB0aGUgdGFibGUgdGhhdCAnc2lkJyBV UkkNCj4gPiA+PiBQYXJhbWV0ZXIgTVVTVA0KPiA+IE5PVA0KPiA+ID4+IGV4aXN0IGluIEdFVC4N Cj4gPiA+IFtNZWRdIEFjdHVhbGx5LCB0aGUgR0VUIGluIHRoYXQgc2xpZGUgcmVmZXJzIHRvIHRo ZSBjYXNlIHRvIGRpc2NvdmVyDQo+ID4gY29uZmlndXJhdGlvbiBwYXJhbWV0ZXJzIHdoZW4sIGZv ciBleGFtcGxlLCBhIGNsaWVudCBib290c3RyYXBzLiBJbg0KPiA+IHN1Y2ggY2FzZSwgdGhlcmUg aXMgbm8gJ3NpZCcgdG8gcGxheSB3aXRoLg0KPiA+ID4NCj4gPiA+PiBIb3dldmVyLCBJbiBSRkM3 MjUyOg0KPiA+ID4+IDUuOC4xLiBHRVQNCj4gPiA+PiAgIMKgVGhlIEdFVCBtZXRob2QgcmV0cmll dmVzIGEgcmVwcmVzZW50YXRpb24gZm9yIHRoZSBpbmZvcm1hdGlvbiB0aGF0DQo+ID4gPj4gICDC oGN1cnJlbnRseSBjb3JyZXNwb25kcyB0byB0aGUgcmVzb3VyY2UgaWRlbnRpZmllZCBieSB0aGUg cmVxdWVzdCBVUkkuDQo+ID4gPj4NCj4gPiA+PiBTbywgSSB0aGluayB0aGUgcmVzb3VyY2UgbWFk ZSBieSBQVVQgaW4gdGhlIGV4YWN0IFVSSSBwYXRoIG1heSBiZQ0KPiA+IHJldHJpZXZlZA0KPiA+ ID4+IGJ5IEdFVC4NCj4gPiA+IFtNZWRdIEFncmVlLiBUaGUgc2lnbmFsIGNoYW5uZWwgc3BlY2lm aWNhdGlvbiBkb2VzIG5vdCBjaGFuZ2UgdGhlDQo+ID4gPiBSRkM3MjUyDQo+ID4gYmVoYXZpb3Iu DQo+ID4gPg0KPiA+ID4+IEkgYW5kIEpvbiBnb3QgY29uc2Vuc3VzIHRoYXQgdGhlIGV4cGVjdGVk IHJlc3BvbnNlIG9mIEdFVCB3aXRoIHNpZA0KPiA+ID4+IGlzIGEgIkZpZ3VyZSAxODogR0VUIENv bmZpZ3VyYXRpb24gUmVzcG9uc2UgQm9keSIgbGlrZSByZXNwb25zZQ0KPiA+ID4+IHdpdGggY3Vy cmVudA0KPiA+IHZhbHVlDQo+ID4gPj4gb2YgdGhhdCBzaWQgYXQgdGhlIGludGVyb3AgdGVzdGlu Zy4NCj4gPiA+PiBUaGUgY3VycmVudCBkcmFmdCBpcyBub3QgY2xlYXIgYWJvdXQgdGhpcyBiZWhh dmlvci4NCj4gPiA+IFtNZWRdIEFzIEkgbWVudGlvbmVkIGFib3ZlLCB3ZSBhcmUgbm90IGNoYW5n aW5nIHRoZSA3MjUyIGJlaGF2aW9yLiBJDQo+ID4gPiBjYW4NCj4gPiBhZGQgdGhpcyBORVcgdGV4 dCBpZiBpdCBoZWxwczoNCj4gPiA+DQo+ID4gPiAgICAgQSBET1RTIGNsaWVudCBtYXkgaXNzdWUg YSBHRVQgbWVzc2FnZSB3aXRoIG9yIHdpdGhvdXQgJ3NpZCcgcGFyYW1ldGVyDQo+ID4gPiAgICAg dG8gcmV0cmlldmUgdGhlIGNvbmZpZ3VyYXRpb24gcGFyYW1ldGVycy4gIFRoZSByZXNwb25zZSBt ZXNzYWdlIGJvZHkNCj4gPiA+ICAgICBpcyB0aGUgc2FtZSBhcyB0aGUgb25lIGRlcGljdGVkIGlu IEZpZ3VyZSAxOC4NCj4gPiA+DQo+ID4gW2thbmFtZV0NCj4gPiBSZWZlcnJpbmcgdG8gRmlndXJl IDE4IHdhcyBub3QgcHJlY2lzZSwgc29ycnkuDQo+ID4gVGhlIEdFVCB3aXRoIHNpZCB3aWxsIGlu Y2x1ZGUgc2lkIGluIHJlc3BvbnNlIGJvZHkgYWNjb3JkaW5nIHRvIFlBTkcNCj4gPiBtb2R1bGUo NS4xLCA1LjIpDQo+ID4NCj4gPiBTbywgdGhpcyB3b3VsZCBiZSBtb3JlIHByZWNpc2UuDQo+ID4N Cj4gPiAgICAgQSBET1RTIGNsaWVudCBtYXkgaXNzdWUgYSBHRVQgbWVzc2FnZSB3aXRoIG9yIHdp dGhvdXQgJ3NpZCcgcGFyYW1ldGVyDQo+ID4gICAgIHRvIHJldHJpZXZlIHRoZSBjb25maWd1cmF0 aW9uIHBhcmFtZXRlcnMuICBUaGUgcmVzcG9uc2UgbWVzc2FnZSBib2R5DQo+ID4gICAgIGZvbGxv d3MgdGhlIFlBTkcgbW9kdWxlICJpZXRmLWRvdHMtc2lnbmFsLWNoYW5uZWwiIChTZWN0aW9uIDUu MikuDQo+ID4NCj4gDQo+IFtNZWRdIEkgc3VnZ2VzdCB0byBkZWxldGUgIm9yIHdpdGhvdXQiIGJl Y2F1c2UgdGhpcyBpcyBhbHJlYWR5IGRpc2N1c3NlZCBpbiA0LjUuMS4NCj4gDQo+ICJBIERPVFMg Y2xpZW50IG1heSBpc3N1ZSBhIEdFVCBtZXNzYWdlIHdpdGggJ3NpZCcgcGFyYW1ldGVyIHRvIHJl dHJpZXZlIHRoZQ0KPiBjb25maWd1cmF0aW9uIHBhcmFtZXRlcnMuIg0KPiANCj4gSWYgd2UgYXJl IHNpbGVudCBhYm91dCB0aGUgcmVzcG9uc2UsIHRoaXMgbWVhbnMgdGhhdCB0aGUgY2xpZW50IHNo b3VsZCBhY2NlcHQNCj4gYm90aCByZXNwb25zZXMgd2l0aCBvciB3aXRob3V0ICdzaWQnIGluIHRo ZSBib2R5Lg0KPiANCj4gRG8geW91IHdhbnQgdGhlIHRleHQgdG8gYmUgbW9yZSBzcGVjaWZpYywg ZS5nLjoNCj4gKDEpIGFsd2F5cyByZXR1cm4gc2lkIGluIHRoZSByZXNwb25zZT8gSWYgc28sIGRv ZXMgdGhlIGNsaWVudCB1c2VzIHRoYXQgaW5mb3JtYXRpb24NCj4gZm9yIHNvbWUgcHJvY2Vzc2lu Zz8NCj4gKDIpIGZvcmJpZCB0byByZXR1cm4gdGhlIHNpZD8gVGhlIGNsaWVudCB3aWxsIGFzc3Vt ZSB0aGF0IHRoZSByZXNwb25zZSBtYXRjaGVzIHRoZQ0KPiBzaWQgaW5jbHVkZWQgaW4gdGhlIHJl cXVlc3QuDQo+ICgzKSBhbGxvdyBmb3IgYm90aCBjYXNlcy4NCg0KQ29uZmlndXJhdGlvbiByZXF1 ZXN0L3Jlc3BvbnNlIGFyZSBjb25maXJtYWJsZSBtZXNzYWdlcywgRE9UUyBjbGllbnQgd2lsbCBr bm93IGlmIGl0cyByZXF1ZXN0IGlzIGFjY2VwdGVkIGJ5IHRoZSBzZXJ2ZXIgb3Igbm90LCBkb24n dCBzZWUgdGhlIG5lZWQgdG8gcmV0dXJuICJzaWQiIGluIHRoZSByZXNwb25zZS4NCkhvd2V2ZXIs ICJzaWQiIGlzIHVzZWZ1bCBpbiB0aGUgcmVxdWVzdCwgdGhvdWdoIHRoZSBjbGllbnQgc2VuZHMg Y29uZmlndXJhdGlvbiByZXF1ZXN0IGluIG9yZGVyLCB0aGV5IG1heSBhcnJpdmUNCmF0IHRoZSBE T1RTIHNlcnZlciBvdXQtb2Ytb3JkZXIgKHJlcXVlc3RzIG1heSB0YWtlIGRpZmZlcmVudCBuZXR3 b3JrIHBhdGhzKS4NCg0KQ2hlZXJzDQotVGlydQ0KDQo+IA0KPiA+DQo+ID4gPj4gMi4gaG93IHRv IGdldCBkZWZhdWx0IHZhbHVlcyBhZnRlciBzZXZlcmFsIG5lZ290aWF0aW9ucyBHRVQgd2l0aG91 dA0KPiA+ID4+IHNpZCByZXR1cm5zIHRoZSBjdXJyZW50IHZhbHVlcy4NCj4gPiA+PiBUaGUgZGVm YXVsdCB2YWx1ZXMgY2FuIGJlIHJldHJpZXZlZCBvbmx5IGp1c3QgYWZ0ZXIgYm9vdHNyYXBwaW5n IG9yDQo+ID4gc2VuZGluZw0KPiA+ID4+IERFTEVURSByZXF1ZXN0Lg0KPiA+ID4+IChhIERPVFMg Y2xpZW50IE1BWSBzZW5kIGEgREVMRVRFIHJlcXVlc3QgdG8gc2V0IHRoZSBjb25maWd1cmF0aW9u DQo+ID4gcGFyYW1ldGVycw0KPiA+ID4+IHRvIGRlZmF1bHQgdmFsdWVzLikNCj4gPiA+PiBJJ2Qg bGlrZSB0byBnZXQgdGhlIGRlZmF1bHQgdmFsdWVzIGV2ZW4gYWZ0ZXIgbmVnb3RpYXRpb25zLiBJ cw0KPiA+ID4+IHRoZXJlIGFueQ0KPiA+IHdheQ0KPiA+ID4+IHRvIGdldCB0aGVtPw0KPiA+ID4g W01lZF0gRGVmYXVsdCB2YWx1ZXMgYXJlIGtub3duIHRvIERPVFMgYWdlbnRzIGJ5IGRlc2lnbi4g VGhhdCBpcyBhDQo+ID4gPiBET1RTDQo+ID4gYWdlbnQgYXNzdW1lcyB0aGUgZm9sbG93aW5nIGRl ZmF1bHQgdmFsdWVzOg0KPiA+ID4NCj4gPiA+IFRoZSBSRUNPTU1FTkRFRCB2YWx1ZXMgb2YgdHJh bnNtaXNzaW9uIHBhcmFtZXRlcg0KPiA+ID4gICAgIHZhbHVlcyBhcmUgYWNrLXRpbWVvdXQgKDIg c2Vjb25kcyksIG1heC1yZXRyYW5zbWl0ICgzKSwgYWNrLXJhbmRvbS0NCj4gPiA+ICAgICBmYWN0 b3IgKDEuNSkuICBJbiBhZGRpdGlvbiB0byB0aG9zZSBwYXJhbWV0ZXJzLCB0aGUgUkVDT01NRU5E RUQNCj4gPiA+ICAgICBzcGVjaWZpYyBET1RTIHRyYW5zbWlzc2lvbiBwYXJhbWV0ZXIgdmFsdWVz IGFyZSAnaGVhcnRiZWF0LWludGVydmFsJw0KPiA+ID4gICAgICgzMCBzZWNvbmRzKSBhbmQgJ21p c3NpbmctaGItYWxsb3dlZCcgKDUpLg0KPiA+DQo+ID4gW0thbmFtZV0NCj4gPiBJIHRob3VnaHQg ZWFjaCBET1RTIHNlcnZlciBjb3VsZCBoYXZlIGl0cyBvd24gZGVmYXVsdCB2YWx1ZXMgYmVjYXVz ZQ0KPiA+IHRoZSBkZWZhdWx0IHZhbHVlcyBieSBkZXNpZ24gaXMganVzdCBhIHJlY29tbWVuZGF0 aW9uLg0KPiA+DQo+IA0KPiBbTWVkXSBPbmUgd2F5IHRvIGRpc2NvdmVyIHdoZXRoZXIgYSBzZXZl ciB1c2VzIG5vbi1yZWNvbW1lbmRlZCB2YWx1ZXMgYXMNCj4gZGVmYXVsdCBpcyB0byBpc3N1ZSBh IEdFVCBhdCBib290c3RyYXAgb3IgYWZ0ZXIgYSBERUxURVRFLg0KPiANCj4gPiA+IFdoZW4gRE9U UyBhZ2VudHMgbmVnb3RpYXRlIGEgZ2l2ZW4gcGFyYW1ldGVyLCB0aGUgbmVnb3RpYXRlZCB2YWx1 ZQ0KPiA+ID4gaXMgdXNlZA0KPiA+IHRvIG92ZXJyaWRlIHRoZSBkZWZhdWx0IG9uZS4gT3RoZXJ3 aXNlLCB0aGUgZGVmYXVsdCB2YWx1ZSBpcyB1c2VkLg0KPiA+ID4NCj4gPiA+IEEgRE9UUyBjbGll bnQgbWFpbnRhaW5zIGEgc3RhdGUgd2hldGhlciBhIHZhbHVlIHdhcyBuZWdvdGlhdGVkLiBBcw0K PiA+ID4gc3VjaCwgYQ0KPiA+IERPVFMgY2xpZW50IGRvZXMgbm90IG5lZWQgdG8gZGlzY292ZXIg ZGVmYXVsdCB2YWx1ZXMuDQo+ID4gW0thbmFtZV0NCj4gPiBZZXMsIHRoYXQncyB0cnVlLg0KPiA+ IFdoYXQgSSB0aG91Z2h0IHdhcywgZnJvbSBvcGVyYXRpb25hbCBwZXJzcGVjdGl2ZSwgYW4gb3Bl cmF0b3IgbWF5IHdhbnQNCj4gPiB0byBrbm93IHRoZSBkZWZhdWx0IHZhbHVlcyBvZiB0aGUgRE9U UyBzZXJ2ZXIgYmVmb3JlIGRlbGV0aW5nIHRoZQ0KPiA+IG5lZ290aWF0ZWQgdmFsdWVzLg0KPiA+ IEJ1dCwgSSBhZ3JlZSB0aGF0IGlzIG91dCBvZiBET1RTIHNwZWMuDQo+ID4NCj4gPiA+IERpZCBJ IG1pc3NlZCBzb21ldGhpbmc/DQo+ID4NCj4gPg0KPiA+ID4+IHRoYW5rcywNCj4gPiA+PiBLYW5h bWUNCj4gPiA+Pg0KPiA+ID4+DQo+ID4gPj4NCj4gPiA+PiBPbiAyMDE4LzA0LzA0IDE2OjMxLCBt b2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIHdyb3RlOg0KPiA+ID4+PiBSZS0sDQo+ID4gPj4+ DQo+ID4gPj4+IFBsZWFzZSBzZWUgaW5saW5lLg0KPiA+ID4+Pg0KPiA+ID4+PiBDaGVlcnMsDQo+ ID4gPj4+IE1lZA0KPiA+ID4+Pg0KPiA+ID4+Pj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0t DQo+ID4gPj4+PiBEZcKgOiBrYW5hbWUgbmlzaGl6dWthIFttYWlsdG86a2FuYW1lQG50dHY2Lmpw XSBFbnZvecOpwqA6IG1lcmNyZWRpDQo+ID4gPj4+PiA0IGF2cmlsIDIwMTggMDg6NTcgw4DCoDog Qk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTjsgZG90c0BpZXRmLm9yZw0KPiA+ID4+Pj4gT2JqZXTC oDogUmU6IFtEb3RzXSBXR0xDIG9uIERPVFMgU2lnbmFsIENoYW5uZWwNCj4gPiA+Pj4+DQo+ID4g Pj4+PiBIaSBNZWQsDQo+ID4gPj4+Pg0KPiA+ID4+Pj4NCj4gPiA+Pj4+IE9uIDIwMTgvMDQvMDQg MTU6MjIsIG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20gd3JvdGU6DQo+ID4gPj4+Pj4gSGkg S2FuYW1lLA0KPiA+ID4+Pj4+DQo+ID4gPj4+Pj4gUGxlYXNlIHNlZSBpbmxpbmUuDQo+ID4gPj4+ Pj4NCj4gPiA+Pj4+PiBDaGVlcnMsDQo+ID4gPj4+Pj4gTWVkDQo+ID4gPj4+Pj4NCj4gPiA+Pj4+ Pj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ID4gPj4+Pj4+IERlwqA6IERvdHMgW21h aWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUga2FuYW1lDQo+ID4gbmlz aGl6dWthDQo+ID4gPj4+Pj4+IEVudm95w6nCoDogbWVyY3JlZGkgNCBhdnJpbCAyMDE4IDAyOjI3 IMOAwqA6IGRvdHNAaWV0Zi5vcmcgT2JqZXTCoDoNCj4gPiA+Pj4+Pj4gUmU6IFtEb3RzXSBXR0xD IG9uIERPVFMgU2lnbmFsIENoYW5uZWwNCj4gPiA+Pj4+Pj4NCj4gPiA+Pj4+Pj4gSGksDQo+ID4g Pj4+Pj4+DQo+ID4gPj4+Pj4+IEkgaGF2ZSBvbmUgY2xhcmlmaWNhdGlvbiBxdWVzdGlvbnMgYWJv dXQgc2lkIGluIHNpZ25hbCBjaGFubmVsDQo+ID4gPj4+Pj4+IHNlc3Npb24gY29uZmlndXJhdGlv bi4NCj4gPiA+Pj4+Pj4NCj4gPiA+Pj4+Pj4gVGhlIGRyYWZ0IHNheXM6DQo+ID4gPj4+Pj4+ICAg ICDCoEF0IGxlYXN0IG9uZSBvZiB0aGUgYXR0cmlidXRlcyDigJloZWFydGJlYXQtaW50ZXJ2YWzi gJksDQo+ID4gPj4+Pj4+IOKAmW1pc3NpbmctaGIgYWxsb3dlZOKAmSwg4oCZbWF4LXJldHJhbnNt aXTigJksIOKAmWFjay10aW1lb3V04oCZLCDigJlhY2stcmFuZG9tLQ0KPiBmYWN0b3LigJksIGFu ZA0KPiA+ID4+Pj4+PiAgICAgwqDigJl0cmlnZ2VyLW1pdGlnYXRpb27igJkgTVVTVCBiZSBwcmVz ZW50IGluIHRoZSBQVVQgcmVxdWVzdC4NCj4gPiA+Pj4+Pj4gICAgIMKgKHNuaXApDQo+ID4gPj4+ Pj4+ICAgICDCoFRoZSBQVVQgcmVxdWVzdCB3aXRoIGEgaGlnaGVyIG51bWVyaWMg4oCZc2lk4oCZ IHZhbHVlDQo+ID4gPj4+Pj4+IG92ZXJyaWRlcyB0aGUNCj4gPiBET1RTDQo+ID4gPj4+Pj4+ICAg ICDCoHNpZ25hbCBjaGFubmVsIHNlc3Npb24gY29uZmlndXJhdGlvbiBkYXRhIGluc3RhbGxlZCBi eSBhDQo+ID4gPj4+Pj4+IFBVVA0KPiA+IHJlcXVlc3QNCj4gPiA+Pj4+Pj4gICAgIMKgd2l0aCBh IGxvd2VyIG51bWVyaWMg4oCZc2lk4oCZIHZhbHVlLg0KPiA+ID4+Pj4+Pg0KPiA+ID4+Pj4+PiBh c3N1bWluZyB0aGVzZSBhcmUgZGVmYXVsdCB2YWx1ZXMgb2YgYSBET1RTIHNlcnZlcjoNCj4gPiA+ Pj4+Pj4gICAgIMKgJ2hlYXJ0YmVhdC1pbnRlcnZhbCc9MzANCj4gPiA+Pj4+Pj4gICAgIMKg4oCZ bWF4LXJldHJhbnNtaXTigJk9Mw0KPiA+ID4+Pj4+Pg0KPiA+ID4+Pj4+PiBpZiB0aGVzZSBtZXNz YWdlcyBjYW1lIHRvIHRoZSBET1RTIHNlcnZlciBjb25zZWN1dGl2ZWx5LA0KPiA+ID4+Pj4+PiAg ICAgwqAxLiBzaWQ9MTIzLCAiaGVhcnRiZWF0LWludGVydmFsIj0xMA0KPiA+ID4+Pj4+PiAgICAg wqAyLiBzaWQ9NDU2LCDigJltYXgtcmV0cmFuc21pdOKAmT01IGluIHRoZSBmaW5hbCBzdGF0ZSwg dGhlDQo+ID4gPj4+Pj4+IGZpcnN0IGNoYW5nZSBzaG91bGQgYmUgZGlzY2FyZGVkPzoNCj4gPiA+ Pj4+Pj4gICAgIMKgJ2hlYXJ0YmVhdC1pbnRlcnZhbCc9MzANCj4gPiA+Pj4+Pj4gICAgIMKg4oCZ bWF4LXJldHJhbnNtaXTigJk9NQ0KPiA+ID4+Pj4+PiBvciBhY2N1bXVsYXRlZD86DQo+ID4gPj4+ Pj4+ICAgICDCoCdoZWFydGJlYXQtaW50ZXJ2YWwnPTEwDQo+ID4gPj4+Pj4+ICAgICDCoOKAmW1h eC1yZXRyYW5zbWl04oCZPTUNCj4gPiA+Pj4+Pj4NCj4gPiA+Pj4+Pj4gc28sIHRoZSBxdWVzdGlv biBpczogc2hvdWxkIHRoZXkgYmUgb3ZlcnJpZGRlbiBieSBkZWZhdWx0DQo+ID4gPj4+Pj4+IHZh bHVlcyBldmVuDQo+ID4gaWYNCj4gPiA+Pj4+IGl0DQo+ID4gPj4+Pj4+IGlzIG5vdCBzcGVjaWZp ZWQ/DQo+ID4gPj4+Pj4gW01lZF0gVGhlIGJlaGF2aW9yIHRvIGZvbGxvdyBpcyBjb3ZlcmVkIGJ5 IHRoaXMgdGV4dDoNCj4gPiA+Pj4+Pg0KPiA+ID4+Pj4+ICAgICAgIFRoZSBQVVQgcmVxdWVzdCB3 aXRoIGEgaGlnaGVyIG51bWVyaWMgJ3NpZCcgdmFsdWUNCj4gPiA+Pj4+PiBvdmVycmlkZXMgdGhl DQo+ID4gRE9UUw0KPiA+ID4+Pj4+ICAgICAgIHNpZ25hbCBjaGFubmVsIHNlc3Npb24gY29uZmln dXJhdGlvbiBkYXRhIGluc3RhbGxlZCBieSBhDQo+ID4gPj4+Pj4gUFVUDQo+ID4gcmVxdWVzdA0K PiA+ID4+Pj4+ICAgICAgIHdpdGggYSBsb3dlciBudW1lcmljICdzaWQnIHZhbHVlLiAgVG8gYXZv aWQgbWFpbnRhaW5pbmcgYQ0KPiA+ID4+Pj4+IGxvbmcNCj4gPiBsaXN0DQo+ID4gPj4+Pj4gICAg ICAgb2YgJ3NpZCcgcmVxdWVzdHMgZnJvbSBhIERPVFMgY2xpZW50LCB0aGUgbG93ZXIgbnVtZXJp YyAnc2lkJw0KPiA+IE1VU1QNCj4gPiA+PiBiZQ0KPiA+ID4+Pj4+ICAgICAgIGF1dG9tYXRpY2Fs bHkgZGVsZXRlZCBhbmQgbm8gbG9uZ2VyIGF2YWlsYWJsZSBhdCB0aGUgRE9UUyBzZXJ2ZXIuDQo+ ID4gPj4+Pj4NCj4gPiA+Pj4+PiBBbmQNCj4gPiA+Pj4+Pg0KPiA+ID4+Pj4+ICAgICAgIFRoZSBE T1RTIGFnZW50cyBNVVNUIHVzZSB0aGUgbmVnb3RpYXRlZA0KPiA+ID4+Pj4+ICAgICAgIHZhbHVl cyBmb3IgbWVzc2FnZSB0cmFuc21pc3Npb24gcGFyYW1ldGVycyBhbmQgZGVmYXVsdCB2YWx1ZXMg Zm9yDQo+ID4gPj4+Pj4gICAgICAgbm9uLW5lZ290aWF0ZWQgbWVzc2FnZSB0cmFuc21pc3Npb24g cGFyYW1ldGVycy4NCj4gPiA+Pj4+IFRoYW5rcywgc28sIGluIG15IGV4YW1wbGUsIGZpbmFsIHN0 YXRlIGlzDQo+ID4gPj4+PiAgICDCoCAnaGVhcnRiZWF0LWludGVydmFsJz0zMCAocmV2ZXJ0ZWQg dG8gZGVmYXVsdCB2YWx1ZSkNCj4gPiA+Pj4+ICAgIMKgIOKAmW1heC1yZXRyYW5zbWl04oCZPTUN Cj4gPiA+Pj4+IGFuZCB0aGUgbG93ZXIgbnVtZXJpYyAnc2lkJyBubyBsb25nZXIgZXhpc3QgaW4g dGhlIERPVFMgc2VydmVyLCByaWdodD8NCj4gPiA+Pj4+DQo+ID4gPj4+IFtNZWRdIEV4YWN0bHku DQo+ID4gPj4+DQo+ID4gPj4+Pj4+IEkgdGhpbmsgdGhlIGZvcm1lciBpcyBpZGVhbCBiZWhhdmlv ci4NCj4gPiA+Pj4+Pj4gSG93ZXZlciwgaWYgc28sIHRoZSBET1RTIHNlcnZlciBpcyBvbmx5IHJl cXVpcmVkIHRvIGtlZXAgdGhlDQo+ID4gPj4+Pj4+IGxhdGVzdA0KPiA+ID4+Pj4gcmVzb3VyY2UN Cj4gPiA+Pj4+Pj4gb2YgdGhlIGhpZ2hlc3Qgc2lkLA0KPiA+ID4+Pj4+PiB0aGVuIHRoZXJlIHNo b3VsZCBiZSBubyBkaWZmZXJlbmNlIGJldHdlZW4gREVMRVRFIG1lc3NhZ2Ugd2l0aA0KPiA+ID4+ Pj4+PiBhbmQNCj4gPiA+PiB3aXRob3V0DQo+ID4gPj4+Pj4+IHNpZC4NCj4gPiA+Pj4+Pj4NCj4g PiA+Pj4+PiBbTWVkXSBUbyBkZWxldGUgYSBjb25maWd1cmF0aW9uLCBhIGNsaWVudCBtYXkgc2Vu ZCBhIERFTEVURSB3aXRoDQo+ID4gPj4+Pj4gYQ0KPiA+IHZhbGlkDQo+ID4gPj4+PiAnc2lkJyBv ciBhIERFTEVURSB3aXRob3V0IHN1cHBseWluZyBhICdzaWQnLg0KPiA+ID4+Pj4+IEJvdGggYXJl IGNvbnNpZGVyZWQgYXMgdmFsaWQgaW4gU2VjdGlvbiA0LjUuNC4NCj4gPiA+Pj4+Pg0KPiA+ID4+ Pj4gYm90aCBhcmUgT0sgYW5kIGhhdmUgdGhlIHNhbWUgZWZmZWN0IG9uIERPVFMgc2VydmVyLCBy aWdodD8NCj4gPiA+Pj4gW01lZF0gWWVzLg0KPiA+ID4+Pg0KPiA+ID4+Pj4gQSBET1RTIHNlcnZl ciBhbHdheXMga2VlcHMgdGhlIGxhdGVzdCBzaWQgb25seS4NCj4gPiA+Pj4gW01lZF0gTm90IHRo ZSAibGF0ZXN0IiByZWNlaXZlZCBzaWQuLi5idXQgdGhlIHJlcXVlc3Qgd2l0aCB0aGUNCj4gPiA+ Pj4gaGlnaGVyDQo+ID4gc2lkLg0KPiA+ID4+Pg0KPiA+ID4+PiAgICBBIERPVFMgY2xpZW50IGFs d2F5cyBhdHRlbXB0DQo+ID4gPj4+PiB0byB1cGRhdGUgaXQuDQo+ID4gPj4+PiBTbyB0aGVyZSBp cyBubyByZWFzb24gdG8gdXNlIFBVVCwgR0VULCBERUxFVEUgd2l0aCBzaWQuDQo+ID4gPj4+PiBX aHkgc2lkIGRvZXMgZXhpc3QgaXMgY29uZnVzaW5nIG1lLg0KPiA+ID4+PiBbTWVkXSAnc2lkJyBp cyB0aGVyZSB0byBzb2x2ZSBvdXQgb2Ygb3JkZXIgY29uZmlndXJhdGlvbiByZXF1ZXN0cy4NCj4g PiA+Pj4gVGhlDQo+ID4gPj4gcmF0aW9uYWxlIGlzIGV4cGxhaW5lZCBpbiBzbGlkZSAxMiBvZg0K PiA+ID4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy9pbnRlcmltLTIwMTgt ZG90cy0NCj4gPiAwMS9tYXRlcmlhbHMvc2xpZGVzLQ0KPiA+ID4+IGludGVyaW0tMjAxOC1kb3Rz LTAxLXNlc3NhLXNpZ25hbC1jaGFubmVsLTAwLnBkZg0KPiA+ID4+Pj4gSSdtIGFmcmFpZCBpdCB3 YXMgZGlzY3Vzc2VkIG9uIHRoZSBNTCBidXQgSSdkIGxpa2UgdG8ga25vdyB0aGUNCj4gPiA+Pj4+ IHJhdGlvbmFsDQo+ID4gb2YNCj4gPiA+Pj4+IGV4aXN0ZW5jZSBvZiBzaWQuDQo+ID4gPj4+PiBg YGANCj4gPiA+Pj4+ICAgIMKgc2lkOiBTZXNzaW9uIElkZW50aWZpZXIgaXMgYW4gaWRlbnRpZmll ciBmb3IgdGhlIERPVFMgc2lnbmFsIGNoYW5uZWwNCj4gPiA+Pj4+ICAgIMKgc2Vzc2lvbiBjb25m aWd1cmF0aW9uIGRhdGEgcmVwcmVzZW50ZWQgYXMgYW4gaW50ZWdlci4gVGhpcw0KPiA+ID4+Pj4g ICAgwqBpZGVudGlmaWVyIE1VU1QgYmUgZ2VuZXJhdGVkIGJ5IERPVFMgY2xpZW50cy4g4oCZc2lk 4oCZIHZhbHVlcyBNVVNUDQo+ID4gPj4+PiAgICDCoGluY3JlYXNlIG1vbm90b25pY2FsbHkuDQo+ ID4gPj4+PiBgYGANCj4gPiA+Pj4+IHRoaXMgaXMgbm90IGNvbnZpbmNpbmcgYmVjYXVzZSBhbHdh eXMgb25seSBvbmUgY29uZmlndXJhdGlvbiBpcw0KPiA+IHJlZ2lzdGVyZWQNCj4gPiA+PiBvbg0K PiA+ID4+Pj4gRE9UUyBzZXJ2ZXIuDQo+ID4gPj4+PiBpdCB3aWxsIGNvbXBsZXRlbHkgd29yayB3 aXRob3V0IHNpZC4NCj4gPiA+Pj4+DQo+ID4gPj4+PiB0aGFua3MsDQo+ID4gPj4+PiBLYW5hbWUN Cj4gPiA+Pj4+DQo+ID4gPj4+Pg0KPiA+ID4+Pj4+PiByZWdhcmRzLA0KPiA+ID4+Pj4+PiBLYW5h bWUNCj4gPiA+Pj4+Pj4NCj4gPiA+Pj4+Pj4NCj4gPiA+Pj4+Pj4gT24gMjAxOC8wMy8yMSAxOToz MiwgUm9tYW4gRGFueWxpdyB3cm90ZToNCj4gPiA+Pj4+Pj4+IEhlbGxvIQ0KPiA+ID4+Pj4+Pj4N Cj4gPiA+Pj4+Pj4+IENvbnNpc3RlbnQgd2l0aCBvdXIgZGlzY3Vzc2lvbiBhdCB0aGUgTG9uZG9u IG1lZXRpbmcsIHdlIGFyZQ0KPiA+ID4+Pj4+Pj4gc3RhcnRpbmcNCj4gPiBhDQo+ID4gPj4+Pj4+ IHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIChXR0xDKSBmb3IgdGhlIERPVFMgU2lnbmFsIENoYW5u ZWwgZHJhZnQ6DQo+ID4gPj4+Pj4+PiBET1RTIFNpZ25hbCBDaGFubmVsIFNwZWNpZmljYXRpb24N Cj4gPiA+Pj4+Pj4+IGRyYWZ0LWlldGYtZG90cy1zaWduYWwtY2hhbm5lbC0xOA0KPiA+ID4+Pj4+ Pj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZG90cy1zaWduYWwtY2hh bm5lbC0xOA0KPiA+ID4+Pj4+Pj4NCj4gPiA+Pj4+Pj4+IFBsZWFzZSBzZW5kIGNvbW1lbnRzIHRv IHRoZSBET1RTIG1haWxpbmcgbGlzdCAtLSBmZWVkYmFjayBvbg0KPiA+IHJlbWFpbmluZw0KPiA+ ID4+Pj4+PiBpc3N1ZXMgb3IgbmVlZGVkIGNoYW5nZXM7IGFzIHdlbGwgYXMgZW5kb3JzZW1lbnRz IHRoYXQgdGhpcw0KPiA+ID4+Pj4+PiBkcmFmdCBpcw0KPiA+ID4+Pj4gcmVhZHkuDQo+ID4gPj4+ Pj4+PiBUaGlzIFdHTEMgd2lsbCBlbmQgb24gQXByaWwgNiwgMjAxOC4NCj4gPiA+Pj4+Pj4+DQo+ ID4gPj4+Pj4+PiBUaGFua3MsDQo+ID4gPj4+Pj4+PiBSb21hbg0KPiA+ID4+Pj4+Pj4NCj4gPiA+ Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4gPj4+Pj4+PiBEb3RzIG1haWxpbmcgbGlzdA0KPiA+ID4+Pj4+Pj4gRG90c0BpZXRmLm9yZw0K PiA+ID4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3RzDQo+ ID4gPj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+ID4gPj4+Pj4+IERvdHMgbWFpbGluZyBsaXN0DQo+ID4gPj4+Pj4+IERvdHNAaWV0Zi5vcmcN Cj4gPiA+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3RzDQo+ ID4gPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gPiA+Pj4+PiBEb3RzIG1haWxpbmcgbGlzdA0KPiA+ID4+Pj4+IERvdHNAaWV0Zi5vcmcNCj4g PiA+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHMNCj4gPiA+ Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ Pj4gRG90cyBtYWlsaW5nIGxpc3QNCj4gPiA+Pj4gRG90c0BpZXRmLm9yZw0KPiA+ID4+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHMNCj4gPiA+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiBEb3RzIG1haWxpbmcg bGlzdA0KPiA+ID4gRG90c0BpZXRmLm9yZw0KPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9kb3RzDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiBEb3RzIG1haWxpbmcgbGlzdA0KPiBEb3RzQGlldGYub3JnDQo+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90cw0K From nobody Fri Apr 6 22:48:24 2018 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 6206F12783A for ; Fri, 6 Apr 2018 22:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 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, T_RP_MATCHES_RCVD=-0.01, 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 VzuXHdk9b33L for ; Fri, 6 Apr 2018 22:48:20 -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 9C0F112420B for ; Fri, 6 Apr 2018 22:48:19 -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=1523080098; 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: dlp-product:dlp-version:dlp-reaction: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-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: 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=f g3oeAIlu4457sgON/MMkkBqrF45g/37W38i/nqgnb U=; b=a2V9l9IQVT0cyACkIjwQ5azH1MuN9maf+2Aza1JIm1eC gzsaoMxIlHk05elHGLY78nbZYHcwr5tYai+HJQLNvpoPvYwyXn NO4MSIWYptZQNrE3rmhqx84Dg9hLdAJgCF07944YdiFutoAaYs nDzUUK9JxXe+k7CMtVJ1Tu+bZfk= Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 0d51_3ad8_c2e88b98_714e_44c9_aeb8_8255be1faebb; Sat, 07 Apr 2018 00:48:17 -0500 Received: from DNVEXUSR1N13.corpzone.internalzone.com (10.44.48.86) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 6 Apr 2018 23:48:17 -0600 Received: from DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) by DNVEXUSR1N13.corpzone.internalzone.com (10.44.48.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 6 Apr 2018 23:48:16 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Fri, 6 Apr 2018 23:48:15 -0600 Received: from NAM02-CY1-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.1347.2; Fri, 6 Apr 2018 23:48:15 -0600 Received: from BN6PR16MB1425.namprd16.prod.outlook.com (10.172.207.19) by BN6PR16MB1506.namprd16.prod.outlook.com (10.172.208.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.653.12; Sat, 7 Apr 2018 05:48:13 +0000 Received: from BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d]) by BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d%2]) with mapi id 15.20.0653.012; Sat, 7 Apr 2018 05:48:13 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: [Dots] IETF 101 Presentation Data Channel Issue #4 Thread-Index: AdPE/QAkDtOD9YeqSAaov9+szxQnSQAoMdfAAAKPC+AAA+QiAAAEVj7wAfiJ0YAAA7+48AABBD0AAByNZ3A= Date: Sat, 7 Apr 2018 05:48:13 +0000 Message-ID: References: <008401d3c4fd$216d0840$644718c0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF1067@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <014801d3c5b7$94c67f00$be537d00$@jpshallow.com> <009a01d3cdab$150b4c40$3f21e4c0$@jpshallow.com> <00cf01d3cdbe$24876650$6d9632f0$@jpshallow.com> In-Reply-To: <00cf01d3cdbe$24876650$6d9632f0$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [185.221.69.46] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR16MB1506; 7:A+DTH/BFbpsWp22Ry1jCRHGS+/Nabk682lGFvstP8ZXfXEbyWALQDBW5wf/GSJS3jJWwyise1Jl/QPiM75daqHIgeSFVjvH382Id0AyEKFRYuO17r0TjHvXsKV3POCkoc5U+xpDHATdA1mRa9ue8H4MooaS/n7Z3DIQzCHwO4HBdllGU8Jp2IAxh+YcWSvRMgYqHl2Z2psnZutekW9Btd8XGPRVyyeE3SCTHzmIDSJW9/pxhTqxUFA/p48WM86bF x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: f991942f-7ea9-4b6a-0cc6-08d59c4b2705 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BN6PR16MB1506; x-ms-traffictypediagnostic: BN6PR16MB1506: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(192374486261705)(18271650672692)(21748063052155)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231221)(944501327)(52105095)(6041310)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(20161123560045)(6072148)(201708071742011); SRVR:BN6PR16MB1506; BCL:0; PCL:0; RULEID:; SRVR:BN6PR16MB1506; x-forefront-prvs: 0635D5275E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(39860400002)(346002)(39380400002)(376002)(5383002)(199004)(189003)(32952001)(2900100001)(2906002)(3280700002)(9326002)(3846002)(478600001)(81156014)(6116002)(81166006)(790700001)(8676002)(8936002)(97736004)(68736007)(446003)(102836004)(2501003)(486006)(2201001)(86362001)(5250100002)(6436002)(93886005)(106356001)(476003)(3660700001)(316002)(11346002)(110136005)(33656002)(6506007)(53546011)(59450400001)(9686003)(53946003)(345774005)(66066001)(14454004)(25786009)(80792005)(54896002)(105586002)(76176011)(6306002)(7736002)(5660300001)(229853002)(186003)(99286004)(55016002)(26005)(6246003)(7696005)(53936002)(72206003)(19609705001)(74316002)(236005)(91024005)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR16MB1506; H:BN6PR16MB1425.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: pNZ5vvF3w6SVV1aPQFCAfmeOeh5Lbs32da/HyoNqyZLryjPlrBKVudRkBL0WHmVZAk04PNHSlt0H8QHfQ7XMz/R0rbI+QDgIon4zdfI96tJCCaPO4OUHbFHZ3WNinsoYzZyNIKVDM9DFXi5vqOggRvwngmkRA8a3iXHMsX5guC2tR6IZOiSforGKSqfYGFEkPirzJMLbNk/BH3DWGIBftYVvd37KS7KdKJQ90GCHluMRtzTcAcp1bUp7PRm9t7K9S3+q/FBPFSUYj2mtexwsKTnZkynyd8h2QQhdzRfp3kw3tWEkIZCcl3R+STZvj/sp9iQcHaWiWnCfVjvEZ6jjKR6k/BBM0fxfECSIh7gD57YXn1Xsu8FB7U0Qx4Jy/lfABYz5kUJPcXJChEQZmSV0H+N85R5YR8JmPQ/9YlRa5pI= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR16MB14256E04A088C9C512E76395EAB90BN6PR16MB1425namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: f991942f-7ea9-4b6a-0cc6-08d59c4b2705 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Apr 2018 05:48:13.2925 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR16MB1506 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 <6259> : inlines <6554> : streams <1783432> : uri <2621824> Archived-At: Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 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, 07 Apr 2018 05:48:23 -0000 --_000_BN6PR16MB14256E04A088C9C512E76395EAB90BN6PR16MB1425namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jon, DOTS clients (intelligent DDoS mitigation system, application server) will = know the destination networks, what kind of DOTS clients will not know the = destination networks they are allowed to use ? DOTS clients could be behind client-domain DOTS gateway, DOTS server will h= ave no way to validate the DOTS client identity sending the ACE request to = determine the destination IP addresses in its scope, it will only know the = destination IP addresses in the DOTS client domain scope. Further, the implicit rule can be misused by compromised DOTS clients (e.g.= black-list good traffic to the entire DOTS client domain) and it's a trou= bleshooting nightmare to find the culprit device adversely impacting the en= tire network. Cheers, -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Friday, April 6, 2018 9:14 PM To: Konda, Tirumaleswar Reddy ; mohamed= .boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 Hi Tiru, The DOTS server is likely to have a scope of IP addresses that are valid fo= r the client to ask for protection for based on the cuid or cdid. The DOTS client may have some knowledge of the scope IPs by some out of ban= d method, but programmatically cannot ask the server what they are. If a client specifies a destination network that is out of the valid scope = of IP addresses, then the ACE request will get rejected. The client may th= en have a challenge to work out what destination networks it is allowed to = use. How does a client set up a blacklist for all the IPS within his allowed sco= pe if it does not know what the scope is? If the client has not provided a destination network, then the DOTS server = can auto-fill in the missing information at the time of the ACE instantiati= on - and this then handles if the scope of IP addresses change. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 06 April 2018 16:19 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 I don't understand how the DOTS server/mitigation will fill it in at time o= f ACE instantiation, and why can't the DOTS client fill the destination net= work details ? -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Friday, April 6, 2018 6:58 PM To: Konda, Tirumaleswar Reddy >; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 Hi there, There is no current way to request of a DOTS Server as to what is the set o= f IP networks that a DOTS client can use either within a mitigation request= or to set up an ACL other than by "testing for ok or not ok" with lots of = different IP addresses. There is a reasonable likelihood of the scope of valid IPs from the Server'= s perspective will change over time. So, unless a DOTS client wants to con= trol a specific destination network, then my suggestion would be to leave t= he ACE destination network empty and for the DOTS Server / DOTS mitigator (= how is out of scope) to fill it in at time of ACE instantiation. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 27 March 2018 13:49 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 Please see inline [TR] From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Tuesday, March 27, 2018 4:07 PM To: Konda, Tirumaleswar Reddy >; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 Hi Tiru / Med See inline [Jon] Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 27 March 2018 09:47 To: mohamed.boucadair@orange.com; Jon = Shallow; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 I also support to mandate destination-network for immediately enforced filt= ering rules. [Jon] This can be enforced / inserted by the DOTS Server for all the destin= ation networks of the domain that the DOTS client 'belongs' to. That said,= it would be good to always have the destination network in an ACL as it ca= n be validated and cross-checked whenever the legitimate set of domain prot= ected IPs are updated. [Jon] However, what happens to the Destination network in the case of a cal= l home DOTS client that becomes a quasi DOTS server and the Destination net= works are somewhere out on the Internet? [TR] DDOS is a targeted attack, so the DOTS client can specify the destinat= ion network targeted by devices in the DOTS server domain and the DOTS serv= er can validate if the destination network is indeed targeted by its device= s. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed...boucadair@= orange.com Sent: Tuesday, March 27, 2018 1:09 PM To: Jon Shallow >; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 Hi Jon, Thank you for the comments. Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : lundi 26 mars 2018 14:23 =C0 : dots@ietf.org Objet : [Dots] IETF 101 Presentation Data Channel Issue #4 Hi there, As per Med's presentation to the IETF 101 Issue #4: Per-Domain or Per-client Filters? * Conclusion - Filters that are activated only during mitigation time are on a per-clien= t basis * Filters are per-domain when are immediately applied "Filters are per-domain when are immediately applied" is what I have an cha= llenge with. If we have a compromised or rogue DOTS client, the simple use of something = like curl, along with the client certificates etc. can be used to generate = any ACL with activation-type :=3D 'immediate' which is then immediately app= lied for all traffic within the domain as per the above. [Med] Yes. FWIW, this attack is called out in the security considerations s= ection: "Nevertheless, an attacker who can access a DOTS client is technically capable of launching various attacks, such as: ..; o Set invalid ACL entries, which may prevent legitimate traffic from being forwarded. Likewise, invalid ACL entries may lead to forward DDoS traffic. " [Jon] Agreed that the attack is covered off in the Security section, but we= should be limiting the possibility / scope of the attack vector by enforci= ng some rules as to what is / is not allowed. Allowing a DOTS client to be= able to affect all the traffic within the domain is a huge risk to me and = should not be allowed. So, a ACL that blacklists the DNS server, or drops all port 443 traffic etc= . can easily cause all of the other clients / devices within the domain to = be taken off air. Putting the intelligence into the DOTS server to not all= ow this to happen could be a challenge. [The signal channel is much harder to compromise and affect traffic flows t= o other areas within the domain] I believe that an ACL instantiated by a DOTS client (immediate or when-miti= gating) should only apply to the DOTS client's traffic which means that the= destination-network has to be a part of the ACL, whether implicitly added = by the DOTS server, or by the DOTS client and suitably validated. [Med] Putting aside that I don't parse "DOTS client's traffic", [Jon] I was referring to all the traffic flows that a DOTS client can legit= imately request control of to the DOTS server that are within the scope of = what the DOTS client is protecting (which may or may not be the DOTS client= 's IP address). I interpret your answer as a support to this question raised for issue #4: * "Should we mandate destination-network to be present for immediate= ly enforced filters?" [Jon] See response to Tiru's Agreement above. ~Jon There is nothing to stop the DOTS server or DOTS mitigator merging common A= CLs to reduce the number of ACLs within the mitigation device. As a side note "mitigation-time" is perhaps a bad name as it implies a time= period - something like "when-mitigating" to me is clearer. [Med] Fixed in my local copy. Thank you. Regards Jon --_000_BN6PR16MB14256E04A088C9C512E76395EAB90BN6PR16MB1425namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jon,

&nbs= p;

DOTS clie= nts (intelligent DDoS mitigation system, application server) will know the = destination networks, what kind of DOTS clients will not know the destinati= on networks they are allowed to use ?

DOTS clie= nts could be behind client-domain DOTS gateway, DOTS server will have no wa= y to validate the DOTS client identity sending the ACE request to determine= the destination IP addresses in its scope, it will only know the destination IP addresses in the DOTS client d= omain scope.

Further, = the implicit rule can be misused by compromised DOTS clients (e.g. black-li= st good traffic to the entire DOTS client domain) and it’s a  tr= oubleshooting nightmare to find the culprit device adversely impacting the entire network.

&nbs= p;

Cheers,

-Tiru

 

From:<= /span> Jon Shallow [mailto:s= upjps-ietf@jpshallow.com]
Sent: Friday, April 6, 2018 9:14 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; mohamed.boucadair@orange.com; dots@ietf.org
Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Hi Tiru= ,

&n= bsp;

The DOT= S server is likely to have a scope of IP addresses that are valid for the c= lient to ask for protection for based on the cuid or cdid.

&n= bsp;

The DOT= S client may have some knowledge of the scope IPs by some out of band metho= d, but programmatically cannot ask the server what they are.

&n= bsp;

If a cl= ient specifies a destination network that is out of the valid scope of IP a= ddresses, then the ACE request will get rejected.  The client may then= have a challenge to work out what destination networks it is allowed to use.

&n= bsp;

How doe= s a client set up a blacklist for all the IPS within his allowed scope if i= t does not know what the scope is?

&n= bsp;

If the = client has not provided a destination network, then the DOTS server can aut= o-fill in the missing information at the time of the ACE instantiation R= 11; and this then handles if the scope of IP addresses change.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 06 April 2018 16:19
To: Jon Shallow; moh= amed.boucadair@orange.com; dots@ietf.org
Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

I donR= 17;t understand how the DOTS server/mitigation will fill it in at time of A= CE instantiation, and why can’t the DOTS client fill the destination = network details ?

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Friday, April 6, 2018 6:58 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; mohamed.boucadair@orange.co= m; dots@ietf.org
Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Hi ther= e,

&n= bsp;

There i= s no current way to request of a DOTS Server as to what is the set of IP ne= tworks that a DOTS client can use either within a mitigation request or to = set up an ACL other than by “testing for ok or not ok” with lots of different IP addresses.=

&n= bsp;

There i= s a reasonable likelihood of the scope of valid IPs from the Server’s= perspective will change over time.  So, unless a DOTS client wants to= control a specific destination network, then my suggestion would be to leave the ACE destination network empty and for the= DOTS Server / DOTS mitigator (how is out of scope) to fill it in at time o= f ACE instantiation.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 27 March 2018 13:49
To: Jon Shallow; moh= amed.boucadair@orange.com; dots@ietf.org
Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Please se= e inline [TR]

&nbs= p;

From:<= /span> Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Tuesday, March 27, 2018 4:07 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; mohamed.boucadair@orange.co= m; dots@ietf.org
Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Hi Tiru= / Med

&n= bsp;

See inl= ine [Jon]

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 27 March 2018 09:47
To: mohamed.boucadai= r@orange.com; Jon Shallow; dots@ietf.org
Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

I also su= pport to mandate destination-network for immediately enforced filtering rul= es.

[Jon] This can be enforced / inserted by the DOTS Server for all the d= estination networks of the domain that the DOTS client ‘belongs’= ; to.  That said, it would be good to always have the destination network in an ACL as it can be validated and cross-checked= whenever the legitimate set of domain protected IPs are updated.

[Jon] However, what happens to the Destination network in the case of = a call home DOTS client that becomes a quasi DOTS server and the Destinatio= n networks are somewhere out on the Internet?

&nbs= p;

[TR] DDOS= is a targeted attack, so the DOTS client can specify the destination netwo= rk targeted by devices in the DOTS server domain and the DOTS server can va= lidate if the destination network is indeed targeted by its devices.

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed= ...boucadair@orange.com
Sent: Tuesday, March 27, 2018 1:09 PM
To: Jon Shallow <sup= jps-ietf@jpshallow.com>; dots@ietf.org
Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Hi Jon,

 

Thank you for the comments.<= /p>

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow
Envoy=E9 : lundi 26 mars 2018 14:23
=C0 : dots@ietf.org
Objet : [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Hi there,

 

As per Med’s presentation= to the IETF 101

 

Issue #4: Per-Domain or Per-cli= ent Filters?

 

• Conclusion

– Filters that are activa= ted only during mitigation time are on a per-client basis=

   • Filters ar= e per-domain when are immediately applied

 

“Filters are per-domain w= hen are immediately applied” is what I have an challenge with.

 

If we have a compromised or rog= ue DOTS client, the simple use of something like curl, along with the clien= t certificates etc. can be used to generate any ACL with activation-type := =3D ‘immediate’ which is then immediately applied for all traffic within the domain as per the above.

 

[Med] Yes. FWIW, this attack is= called out in the security considerations section:

 

“Nevertheless,=
 an

   attacker who can acce= ss a DOTS client is technically capable of

   launching various att= acks, such as:

 

..;

 

   o  Set invalid ACL entries, which may prevent legiti=
mate traffic from
      being forwarded.  Likewise, invali=
d ACL entries may lead to
      forward DDoS traffic.=

“

[Jon] A= greed that the attack is covered off in the Security section, but we should= be limiting the possibility / scope of the attack vector by enforcing some= rules as to what is / is not allowed.  Allowing a DOTS client to be able to affect all the traffic within the dom= ain is a huge risk to me and should not be allowed.

 

So, a ACL that blacklists the D= NS server, or drops all port 443 traffic etc. can easily cause all of the o= ther clients / devices within the domain to be taken off air.  Putting= the intelligence into the DOTS server to not allow this to happen could be a challenge.

[The signal channel is much har= der to compromise and affect traffic flows to other areas within the domain= ]

 

I believe that an ACL instantia= ted by a DOTS client (immediate or when-mitigating) should only apply to th= e DOTS client’s traffic which means that the destination-network has = to be a part of the ACL, whether implicitly added by the DOTS server, or by the DOTS client and suitably validated.

 

[Med] Putting aside that I don&= #8217;t parse “DOTS client’s traffic”,

[Jon] I= was referring to all the traffic flows that a DOTS client can legitimately= request control of to the DOTS server that are within the scope of what th= e DOTS client is protecting (which may or may not be the DOTS client’s IP address).

I interpret your answer as a su= pport to this question raised for issue #4:

    • “Should we mandate destination-network to be present for immediately enforced filters?”

[Jon] S= ee response to Tiru’s Agreement above.

~Jon

There is nothing to stop the DO= TS server or DOTS mitigator merging common ACLs to reduce the number of ACL= s within the mitigation device.

 

As a side note “mitigatio= n-time” is perhaps a bad name as it implies a time period – som= ething like “when-mitigating” to me is clearer.

[Med] Fixed in my local copy. T= hank you.

 

Regards

 

Jon

--_000_BN6PR16MB14256E04A088C9C512E76395EAB90BN6PR16MB1425namp_-- From nobody Fri Apr 6 23:54:54 2018 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 C8D4512946D for ; Fri, 6 Apr 2018 23:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 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, T_RP_MATCHES_RCVD=-0.01, 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 ekHE4ldCoaPq for ; Fri, 6 Apr 2018 23:54:49 -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 03B01126BF6 for ; Fri, 6 Apr 2018 23:54:48 -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=1523084088; 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: dlp-product:dlp-version:dlp-reaction: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-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: 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=r5R8xOu9wAp5X1lrVKmWhx1+S9slXL/h2quzWl 6URAE=; b=KpxdM6oPlNxBRGLsKju6SQ2uY+Ui3qR0X724tx+Z NsJJUINkaJiyzcBc543svYpwYe4EuQ3Y6j+eWywTcyhJZCv2d9 oxlBjCLR0G2nK4rFDPcoN4arNEBmbWsVVP+pSZJsOffmc5adKD 8Bts0yVnTDV06Dpnfk3DwqqL6imfy3I= Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 0d51_5a25_fe7e6ffa_8f62_40d2_b019_24f51f0449e1; Sat, 07 Apr 2018 01:54:47 -0500 Received: from DNVEXUSR1N13.corpzone.internalzone.com (10.44.48.86) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sat, 7 Apr 2018 00:54:46 -0600 Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXUSR1N13.corpzone.internalzone.com (10.44.48.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sat, 7 Apr 2018 00:54:45 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Sat, 7 Apr 2018 00:54:45 -0600 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sat, 7 Apr 2018 00:54:44 -0600 Received: from BN6PR16MB1425.namprd16.prod.outlook.com (10.172.207.19) by BN6PR16MB1475.namprd16.prod.outlook.com (10.172.207.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.653.12; Sat, 7 Apr 2018 06:54:43 +0000 Received: from BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d]) by BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d%2]) with mapi id 15.20.0653.012; Sat, 7 Apr 2018 06:54:43 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: [Dots] Data Channel ACL fragments Thread-Index: AdPMHAMfDWFlXvb3TSeAr5MVkYUzIgAA3pEAAAKPJoAAIuTfcAADWaQAAADopUA= Date: Sat, 7 Apr 2018 06:54:43 +0000 Message-ID: References: <016401d3cc1c$03321200$09963600$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7F97@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <01a701d3cc29$ba915b10$2fb41130$@jpshallow.com> <007501d3ccc2$b49f0b00$1ddd2100$@jpshallow.com> In-Reply-To: <007501d3ccc2$b49f0b00$1ddd2100$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [185.221.69.46] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR16MB1475; 7:EG6jPvat/mrrTQSgwWyZCv1G9YQRgu4wzIRrQDcfM0AXqCjbEhbR51IN8D+Zyov6moUeECCa36U3zM3R5VljF40Pn4HFoKOsu2Vf8+w/H+uCYwsicJOvjDn1vLzhiKjLrVjVCq2HnWuQFPXSIYBVe/pChISroxp4gtk/X3KcbRNOW2woYCn7SRQgZ4Kt5yTg7GyzIvXZGfqNiq8uB4Io0cM2+u8WAK7WgJ+B0P5eXi7jj735VShKsuAbbXqWXlzd x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 6cd5618d-a850-49c8-78ad-08d59c54714e x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BN6PR16MB1475; x-ms-traffictypediagnostic: BN6PR16MB1475: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(192374486261705)(114627819485645)(95692535739014)(18271650672692)(21748063052155)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(3231221)(944501327)(52105095)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:BN6PR16MB1475; BCL:0; PCL:0; RULEID:; SRVR:BN6PR16MB1475; x-forefront-prvs: 0635D5275E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39380400002)(366004)(376002)(346002)(396003)(39860400002)(51444003)(32952001)(189003)(199004)(186003)(55016002)(53936002)(6246003)(9686003)(8936002)(8676002)(81166006)(81156014)(236005)(2900100001)(6306002)(54896002)(86362001)(19609705001)(229853002)(105586002)(106356001)(2501003)(97736004)(5250100002)(3846002)(2201001)(80792005)(68736007)(99286004)(790700001)(7696005)(33656002)(3280700002)(93886005)(606006)(74316002)(25786009)(486006)(66066001)(110136005)(316002)(6116002)(102836004)(11346002)(476003)(3660700001)(446003)(7736002)(5660300001)(2906002)(478600001)(14454004)(26005)(72206003)(76176011)(53546011)(59450400001)(966005)(6506007)(6436002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR16MB1475; H:BN6PR16MB1425.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: C8oVAWMO2F1PFxH4fag+N0fMeFsNtDDF14FpYDE7PVeQ1Iparv0gh44EKib4+HDjOfMjfooYmZB03hQrZl8MazGdrhOF8c0jkBv9s81+/a6Ir9rVFo1HWP32N8QO5oi8bFdIcH3+y3T3JYbRIfTo73QU0uHJecR9StCKHLTpcYdCxJuSyVo0tiZokTdXuNa2V6eGU9V2MGn18ajUpV9uZRI5x1nUC2MZ3rvL4ObcUdpjB3mV9Re04NcFhz+l7qJQkqFiPKlB7Z3IHAir3YPGRTMHGtDriJkrsd4koP7h+E1w247usqF7skPPjHF5mIj2GorRdNv9Kvx8DONLN6EkCdnts8EMKYQIrhRGaUYjYErC7UgwcTY5FiBqO+r80GhdbFC8LfVLLxefoujxm6plrblyuzwMEBmrW2BSRcoOpPg= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR16MB1425B5115EC9C603E5E7945AEAB90BN6PR16MB1425namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 6cd5618d-a850-49c8-78ad-08d59c54714e X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Apr 2018 06:54:43.4476 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR16MB1475 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6259> : inlines <6554> : streams <1783436> : uri <2621848> Archived-At: Subject: Re: [Dots] Data Channel ACL fragments 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, 07 Apr 2018 06:54:53 -0000 --_000_BN6PR16MB1425B5115EC9C603E5E7945AEAB90BN6PR16MB1425namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jon, Please see inline [TR] From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Thursday, April 5, 2018 3:15 PM To: Konda, Tirumaleswar Reddy ; mohamed= .boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] Data Channel ACL fragments Hi Tiru, Actually no, as there is a disconnect between the Cisco document and what w= e have currently got set up. The Cisco Document refers to ACL, which is an ACE in netmod-acl-model/DOTS = speak. A DOTS ACL can be a list of separate matching ACEs. With netmod-acl, we have layer 3 definitions and then separately layer 4 de= finitions - there is now no concept of L3+L4 within the same ACE. So, the Cisco statement "Note: When there is both Layer 3 and Layer 4 infor= mation in the ACL line and the fragments keyword is present" will never be = true for an ACE entry. [TR] No, as per the ACE definition in draft-ietf-netmod-acl-model-16, The c= hoice statements within the match container allow for selection of one head= er within each of "l2", "l3", or "l4" headers. It is possible to specify both L3 and L4 information in the ACE (each ACE h= as a group of match criteria). ---- I still do not understand from the Cisco Document how you can build a set o= f ACLs that say (but I may be missing something) "All traffic to port 53 is allowed unless it is fragmented, in which case a= ll fragments are to be dropped" I can create a set of ACLs that say "All traffic to port 53 is allowed unless it is fragmented, in which case a= ll non-initial fragments are to be dropped" Which does set things up for a DoS of the target with all the initial fragm= ents waiting re-assembly. [TR] The don't think a ACL should blindly drop all fragmented packets, frag= mentation may or may not happen because of a DoS attack. Do vendors current= ly support what you are asking ? -Tiru ---- Which then gets more complicated to construct something when we can only do= either L3 or L4 matching on a per ACE. Regards Jon From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of Konda, T= irumaleswar Reddy Sent: 05 April 2018 09:23 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] Data Channel ACL fragments Hi Jon, The fragment definition to protect the target from attacks that use non-ini= tial fragments only. We followed the Security considerations for IP filtering given in Section 2= of https://www.ietf.org/rfc/rfc1858.txt to drop the initial fragment, so t= he non-initial fragments will be discarded by the destination host (its imp= lemented and discussed in https://www.cisco.com/c/en/us/support/docs/ip/gen= eric-routing-encapsulation-gre/8014-acl-wp.html). -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Wednesday, April 4, 2018 9:00 PM To: mohamed.boucadair@orange.com; dots= @ietf.org Subject: Re: [Dots] Data Channel ACL fragments Hi Med et all, See inline [Jon] Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 04 April 2018 15:27 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Data Channel ACL fragments Re-, I guess we do still need this because we wanted to achieve this functionali= ty (especially for the non-initial fragments): =3D=3D This document supports fragment filtering which adds an additional layer of protection against a DoS attack that uses non-initial fragments only. When there is only layer 3 information in the ACL entry and the fragments keyword is present, for non-initial fragments matching the ACE entry, the 'deny' or 'accept' action associated with the ACE entry will be enforced. For initial or non-fragment matching the ACE entry, the next ACE entry will be processed. When there is both layer 3 and layer 4 information in the ACE entry and the fragments keyword is present, the ACE action is conservative for both 'accept' and 'deny' actions. The actions are conservative to not accidentally deny a fragmented portion of a flow because the fragments do not contain sufficient information to match all of the filter attributes. In the 'deny' action case, instead of denying a non-initial fragment, the next ACE entry is processed. In the 'accept' case, it is assumed that the layer 4 information in the non- initial fragment, if available, matches the layer 4 information in the ACE entry. =3D=3D [Jon] Actually, as I read the text above, if the additional layer of protec= tion is required against fragmented attacks and v-[46]-fragment is set with= action "drop", then any non-initial fragment is dropped - fine. However, the initial fragment skips this ACE test and goes onto the next AC= E. Assuming that there is a "accept" that matches everything else (i.e. we= like the packet apart from when it is fragmented), then the initial fragme= nt is let through. The target IP then consumes lots of RAM whilst waiting for the missing frag= ment segments........D(D)oS Success. There is no way to drop the initial fragment with the above text other than= to "drop" genuine non fragmented traffic as well. I think that logic is f= lawed to drop just subsequent fragments. [Jon] I also wonder how the above is going to get implemented - it would be= easier to say any fragmented packet sequence is not allowed (including the= initial packet) rather than only a part of the sequence which then leads t= o a DoS in its own rights. No? [Jon] See above. I do agree that flags -> fragment -> 1 is a bit ambiguous= is its definition when used to match a packet as an acl/ace, but I do thin= k the match intent is that the packet is not fragmented. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : mercredi 4 avril 2018 15:51 =C0 : dots@ietf.org Objet : [Dots] Data Channel ACL fragments Hi there, Do we still need to have the fragment definition for ACEs in the data chann= el? draft-ietf-netmod-acl-model-18 now supports fragments for ipv4 (flags + opt= ions) and implicitly in ipv6 through the next header field protocol set to = 44 (fragment extension header). IPV4 =3D=3D=3D=3D grouping acl-ipv4-header-fields { description "Fields in IPv4 header."; ... leaf flags { type bits { bit reserved { position 0; description "Reserved. Must be zero."; } bit fragment { position 1; description "Setting value to 0 indicates may fragment, while setting the value to 1 indicates do not fragment."; } bit more { position 2; description "Setting the value to 0 indicates this is the last fragment, and setting the value to 1 indicates more fragments are coming."; } } description "Bit definitions for the flags field in IPv4 header."; } leaf offset { type uint16 { range "20..65535"; } description "The fragment offset is measured in units of 8 octets (64 bits). The first fragment has offset zero. The length is 13 bits"; } Regards Jon --_000_BN6PR16MB1425B5115EC9C603E5E7945AEAB90BN6PR16MB1425namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jon,

 

Please see inline [TR]

 

From:<= /span> Jon Shallow [mailto:s= upjps-ietf@jpshallow.com]
Sent: Thursday, April 5, 2018 3:15 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; mohamed.boucadair@orange.com; dots@ietf.org
Subject: RE: [Dots] Data Channel ACL fragments

 

Hi Tiru= ,

&n= bsp;

Actuall= y no, as there is a disconnect between the Cisco document and what we have = currently got set up.

&n= bsp;

The Cis= co Document refers to ACL, which is an ACE in netmod-acl-model/DOTS speak.&= nbsp; A DOTS ACL can be a list of separate matching ACEs.=

&n= bsp;

With ne= tmod-acl, we have layer 3 definitions and then separately layer 4 definitio= ns – there is now no concept of L3+L4 within the same ACE.

&n= bsp;

So, the= Cisco statement “Note: When there is both Layer 3 and Layer 4 inform= ation in the ACL line and the fragments keyword is present” will neve= r be true for an ACE entry.

&nbs= p;

[TR] No, = as per the ACE definition in draft-ietf-netmod-acl-model-16, The choice sta= tements within the match container allow for selection of one header within= each of "l2", "l3", or "l4" headers.

It is pos= sible to specify both L3 and L4 information in the ACE (each ACE has a grou= p of match criteria).

----

&n= bsp;

I still= do not understand from the Cisco Document how you can build a set of ACLs = that say (but I may be missing something)

“= All traffic to port 53 is allowed unless it is fragmented, in which case al= l fragments are to be dropped”

&n= bsp;

I can c= reate a set of ACLs that say

“= All traffic to port 53 is allowed unless it is fragmented, in which case al= l non-initial fragments are to be dropped”

Which d= oes set things up for a DoS of the target with all the initial fragments wa= iting re-assembly.

 

[TR] The don’t think a ACL should blindly drop= all fragmented packets, fragmentation may or may not happen because of a D= oS attack. Do vendors currently support what you are asking ?

 

-Tiru

 

----

&n= bsp;

Which t= hen gets more complicated to construct something when we can only do either= L3 or L4 matching on a per ACE.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto:ietf-supjps-dots-bounces@iet= f.org] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 05 April 2018 09:23
To: Jon Shallow; mohamed.boucadair@orange.com; dots@iet= f.org
Subject: Re: [Dots] Data Channel ACL fragments

 

Hi Jon,

&nbs= p;

The fragm= ent definition to protect the target from attacks that use non-initial frag= ments only.

We follow= ed the Security considerations for IP filtering given in Section 2 of https://www.ietf.org/rfc/rfc1858.txt to drop the initial fragment, so th= e non-initial fragments will be discarded by the destination host (its implemented and discussed in https= ://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulation-gre/= 8014-acl-wp.html).

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: Wednesday, April 4, 2018 9:00 PM
To: mohamed.boucadair@orange.com; dots@ietf.org=
Subject: Re: [Dots] Data Channel ACL fragments

 

Hi Med = et all,

&n= bsp;

See inl= ine [Jon]

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: = dots-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com
Sent: 04 April 2018 15:27
To: Jon Shallow; dots@ietf.org
Subject: Re: [Dots] Data Channel ACL fragments

 

Re-,

 

I guess we do still need this because we wante= d to achieve this functionality (especially for the non-initial fragments):=

 

=3D=3D

   This document support= s fragment filtering which adds an additional

   layer of protection a= gainst a DoS attack that uses non-initial

   fragments only. = When there is only layer 3 information in the ACL

   entry and the fragmen= ts keyword is present, for non-initial fragments

   matching the ACE entr= y, the 'deny' or 'accept' action associated with

   the ACE entry will be= enforced.  For initial or non-fragment matching

   the ACE entry, the ne= xt ACE entry will be processed.  When there is

   both layer 3 and laye= r 4 information in the ACE entry and the

   fragments keyword is = present, the ACE action is conservative for both

   'accept' and 'deny' a= ctions.  The actions are conservative to not

   accidentally deny a f= ragmented portion of a flow because the

   fragments do not cont= ain sufficient information to match all of the

   filter attributes.&nb= sp; In the 'deny' action case, instead of denying a

   non-initial fragment,= the next ACE entry is processed.  In the

   'accept' case, it is = assumed that the layer 4 information in the non-

   initial fragment, if = available, matches the layer 4 information in

   the ACE entry.

=3D=3D

 

[Jon] Actually, as I r= ead the text above, if the additional layer of protection is required again= st fragmented attacks and v-[46]-fragment is set with action “drop= 221;, then any non-initial fragment is dropped – fine.

 

However, the initial f= ragment skips this ACE test and goes onto the next ACE.  Assuming that= there is a “accept” that matches everything else (i.e. we like= the packet apart from when it is fragmented), then the initial fragment is let through.

 

The target IP then con= sumes lots of RAM whilst waiting for the missing fragment segments…&#= 8230;..D(D)oS Success.

 

There is no way to dro= p the initial fragment with the above text other than to “drop”= genuine non fragmented traffic as well.  I think that logic is flawed= to drop just subsequent fragments.

 

[Jon] I also wonder ho= w the above is going to get implemented – it would be easier to say a= ny fragmented packet sequence is not allowed (including the initial packet)= rather than only a part of the sequence which then leads to a DoS in its own rights.

 

No?

 

[Jon] See above. = I do agree that flags -> fragment -> 1 is a bit ambiguous is its def= inition when used to match a packet as an acl/ace, but I do think the match= intent is that the packet is not fragmented.

 

 

Cheers,

Med

 

De : Dots [mailto:dots-boun= ces@ietf.org] De la part de Jon Shallow
Envoy=E9 : mercredi 4 avril 2018 15:51
=C0 : dots@ietf.org
Objet : [Dots] Data Channel ACL fragments

 

Hi there,

 

Do we still need to have the fr= agment definition for ACEs in the data channel?

 

draft-ietf-netmod-acl-model-18 = now supports fragments for ipv4 (flags + options) and implicitly in ipv= 6 through the next header field protocol set to 44 (fragment extension head= er).

 

IPV4

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

  grouping acl-ipv4-header= -fields {

    description<= o:p>

      = "Fields in IPv4 header.";

...

    leaf flags {=

      = type bits {

     &= nbsp;  bit reserved {

     &= nbsp;    position 0;

     &= nbsp;    description

     &= nbsp;      "Reserved. Must be zero.";

     &= nbsp;  }

     &= nbsp;  bit fragment {

     &= nbsp;    position 1;

     &= nbsp;    description

     &= nbsp;      "Setting value to 0 indicates may = fragment, while setting

     &= nbsp;       the value to 1 indicates do not f= ragment.";

     &= nbsp;  }

     &= nbsp;  bit more {

     &= nbsp;    position 2;

     &= nbsp;    description

     &= nbsp;      "Setting the value to 0 indicates = this is the last fragment,

     &= nbsp;       and setting the value to 1 indica= tes more fragments are

     &= nbsp;       coming.";<= /p>

     &= nbsp;  }

      = }

      = description

     &= nbsp;  "Bit definitions for the flags field in IPv4 header."= ;

    }=

 

    leaf offset = {

      = type uint16 {

      =   range "20..65535";

      = }

      = description

     &= nbsp;  "The fragment offset is measured in units of 8 octets (64 = bits).

     &= nbsp;   The first fragment has offset zero. The length is 13 bits= ";

    }=

 

Regards

 

Jon

 

--_000_BN6PR16MB1425B5115EC9C603E5E7945AEAB90BN6PR16MB1425namp_-- From nobody Sat Apr 7 06:27:50 2018 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 59FF41243F3 for ; Sat, 7 Apr 2018 06:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FEXPmW8Q2wZt for ; Sat, 7 Apr 2018 06:27:45 -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 082C7126BF3 for ; Sat, 7 Apr 2018 06:27:44 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.90_1) (envelope-from ) id 1f4nsc-00027s-3V; Sat, 07 Apr 2018 14:27:42 +0100 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , , References: <014f01d3cc19$2e3880e0$8aa982a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7E7B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <019901d3cc23$a93ff8e0$fbbfeaa0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8524@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <004e01d3ccb4$d505e7f0$7f11b7d0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8758@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEF912A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEF93EE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <008501d3cda6$c860d210$59227630$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF951 1@OPEXCLILMA3 . corporate.adroot.infra.ftgroup> <00b001d3cdab$ba8caec0$2fa60c40$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF975C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <00b801d3cdb4$982dc4a0$c8894de0$@jpshallow.com> In-Reply-To: Date: Sat, 7 Apr 2018 14:27:42 +0100 Message-ID: <015101d3ce74$351393c0$9f3abb40$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ5xX4UsK17va5Vv37fpNudI6+9awKIdnG+AkIt6UkCuIhgoQJj4oJpArGJQHwA3D0H4gGs0H5ZApHDVXYB/IC8TgE0bwOgAlFzC1QBmQ12ZgHSvGs3Aa02vLICgeu4wAFxD+3yAcnB1kihmNGJcA== Content-Language: en-gb Archived-At: Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling 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, 07 Apr 2018 13:27:48 -0000 Hi there, My suggestion would be to make ttl of -1 'infinite', otherwise have a minimum value of 300 seconds. The text could read (including referring = to the optional etc. to be consistent with the rest of the document:- alt-server: FQDN of an alternate DOTS server. This is a required attribute. alt-server-record: A list of IP addresses of an alternate DOTS server. This is an optional attribute. ttl: Time to live (TTL) of the alternate DOTS server, represented as an integer number of seconds. That is, the time interval that the alternate DOTS server may be used by a DOTS client. The minimum value is '300' seconds, or '-1'. '-1' means that the alternate DOTS server is to be used until the alternate DOTS server redirects the traffic with another 3.00 response. There is no TTL expiry. If no 'ttl' is returned in a redirect response, this is equivalent to returning a 'ttl' parameter set to '-1'. If the alternate DOTS server TTL has expired, the DOTS client MUST use the DOTS server(s) that was provisioned using means discussed in Section 4.1. =20 This is an optional attribute. Regards Jon -----Original Message----- From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 06 April 2018 15:55 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling The below proposed change does not look good to me, its causing the DOTS client to ping-pong between multiple DOTS servers because of the TTL = value. The alternate server should serve the DOTS client till there is a = planned maintenance, if it is getting over-subscribed it should re-direct the = new DOTS clients to an alternate server and avoid bouncing the existing DOTS clients which have been sending mitigation requests to it. =20 -Tiru > -----Original Message----- > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > Sent: Friday, April 6, 2018 8:06 PM > To: mohamed.boucadair@orange.com; Konda, Tirumaleswar Reddy=20 > ; dots@ietf.org > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling >=20 > Hi Med, >=20 > Thanks for this. I would like to see the ttl: definition tightened up = > (moved away from the DNS TTL version) >=20 > Old >=20 > ttl: Time to live (TTL) of alternate records, represented as an > integer number of seconds. That is, the time interval that > alternate IP addresses may be cached by a DOTS client. >=20 > '0' means that an alternate IP address is only to be used for = the > request in progress, and consequently that IP address should not > be cached. >=20 > If no 'ttl' is returned in a redirect response, this is = equivalent > to returning a 'ttl' parameter set to '0'. >=20 > If 'alt-server-record' has expired, the DOTS client MUST use the > DOTS server(s) that was provisioned using means discussed in > Section 4.1. Furthermore, a DOTS client MUST NOT use the alt- > server FQDN if the 'alt-server-records' has expired. >=20 > New >=20 > ttl: Time to live (TTL) of the alternate DOTS server, represented = as an > integer number of seconds. That is, the time interval that > the alternate DOTS server may be cached for use by a DOTS = client. >=20 > '0' means that the alternate DOTS server is only to be used for = the > request in progress, and consequently the alternate DOTS server=20 > entry should not > be cached. >=20 > If no 'ttl' is returned in a redirect response, this is = equivalent > to returning a 'ttl' parameter set to '0'. >=20 > If the alternate DOTS server TTL has expired, the DOTS client = MUST use the > DOTS server(s) that was provisioned using means discussed in > Section 4.1. >=20 >=20 > Regards >=20 > Jon >=20 > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of=20 > mohamed.boucadair@orange.com > Sent: 06 April 2018 15:21 > To: Jon Shallow; Konda, Tirumaleswar Reddy; dots@ietf.org > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling >=20 > FWIW, I implemented the change at: > https://github.com/boucadair/draft-ietf-dots-signal-channel/blob/maste > r/draf > t-ietf-dots-signal-channel.txt >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > Envoy=E9=A0: vendredi 6 avril 2018 15:33 =C0=A0: BOUCADAIR Mohamed = IMT/OLN;=20 > > Konda, Tirumaleswar Reddy; dots@ietf.org Objet=A0: RE: [Dots] Signal = > > Channel - 300 Redirected Signaling > > > > Excellent. > > > > Thanks > > > > Jon > > > > -----Original Message----- > > From: mohamed.boucadair@orange.com [mailto: > > mohamed.boucadair@orange.com] > > Sent: 06 April 2018 14:29 > > To: Jon Shallow; Konda, Tirumaleswar Reddy; rdd@cert.org > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > Hi Jon, all, > > > > I'm fine to put ttl at the level of alt-server. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > Envoy=E9=A0: vendredi 6 avril 2018 14:57 =C0=A0: BOUCADAIR Mohamed = > > > IMT/OLN; Konda, Tirumaleswar Reddy; rdd@cert.org Objet=A0: RE:=20 > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > Hi there, > > > > > > See inline [Jon3] > > > > > > Regards > > > > > > Jon > > > > > > > > > > > > -----Message d'origine----- > > > > > > De=A0: Konda, Tirumaleswar Reddy=20 > > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > Envoy=E9=A0: vendredi 6 avril 2018 07:07 =C0=A0: BOUCADAIR = Mohamed=20 > > > > > > IMT/OLN; Jon Shallow; dots@ietf.org Objet=A0: RE: > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > Hi Med, > > > > > > > > > > > > The proposed update restricts the client no to do a DNS=20 > > > > > > lookup using the alternate FQDN, further associating a TTL=20 > > > > > > with the name complicates the functionality on the DOTS=20 > > > > > > client to re-establish (D)TLS session with the primary DOTS=20 > > > > > > server after the > > TTL expires. > > > > > > My suggestion is to let the DOTS client continue to use the=20 > > > > > > alternate DOTS > > > > server > > > > > till it gets re-directed. > > > > > > > > > > [Med] This is possible with the current spec. > > > > > > > > > > Triggers for redirect and for falling back to the nominal=20 > > > > > configuration are deployment-specific. The current spec allows = > > > > > for almost all the cases > > > > discussed > > > > > so far: > > > > > > > > > > (1) Redirect for the request in progress: A server does so by=20 > > > > > returning > > > > TTL=3D0. > > > > > (2) The alternate server is not involved in fall back to the=20 > > > > > nominal > > > > server: upon > > > > > expiry of ttl of all alternate IP addresses, then fall back=20 > > > > > automatically > > > > to the > > > > > nominal server. > > > > > (3) Redirect to an alternate server, which in turn will=20 > > > > > instruct the client > > > > to > > > > > redirect to the "base" configuration: a TTL is provided and=20 > > > > > the alternate > > > > server > > > > > can reply with a redirect code any time before the expiry of=20 > > > > > the TTL. A > > > > long TTL > > > > > can be returned if the alternate server will be responsible=20 > > > > > for > > > > coordinating fall > > > > > back to the base server. > > > > > (4) Stop infinite redirects > > > > > > > > Yes, but (1) and (2) complicate the functionality of the DOTS client. > > > > > > [Med] (1) and (2) is exactly the same functionality required for=20 > > > caching DNS replies. > > > > > > The > > > > only reason for adding alt-server-record in the response is DNS=20 > > > > server may not be reachable by the DOTS server because of a DDoS > attack. > > > > > > > > > > [Med] Yes. Note that even if the name resolution was allowed, the=20 > > > client has to deal with the TTL indicated in the response...which=20 > > > is exactly the same as (1) and (2). > > > > > > > > > [Jon3] I think where I am struggling here is the overloaded use of = > > > TTL > > > - The TTL as per a DNS record and held as a part of=20 > > > alt-server-record and then the TTL after which that the alt-server = > > > should be handling the traffic before handling back to the=20 > > > original primary server. It either has to be one or the other, or = > > > they have to > have different names. > > > [Jon3] If we are only going to go for one variant for simplicity,=20 > > > then I would prefer that it should be at the level of = "alt-server". > > > Handling the TTL for DNS refresh is normally handled by a resolver = > > > library, updated by the DNS packets coming in - unusual for an=20 > > > application > > to have to do that. > > > > > > > > > > > > > > > > > > I > > > > > > don't think the DOTS mitigation provider will know=20 > > > > > > ahead-of-time the TTL value after which the DOTS client=20 > > > > > > should disconnect communicating with the alternate DOTS=20 > > > > > > server and re-establish (D)TLS session with the primary DOTS server. > > > > > > > > > > [Med] It depends on the nature of the redirect: overload,=20 > > > > > planned > > > > maintenance, > > > > > etc. For planned maintenance, the TTL is known in general. > > > > > > > > It's the primary DOTS server responsibility to point the DOTS=20 > > > > client to an optimal alternate server, where the client can=20 > > > > continue to send migration requests without a frequent ping-pong > between servers. > > > > > > [Med] Agree. This is a service configuration problem. > > > [Jon3] Agreed - and the 5 minute minimum ping-pong time is a good=20 > > > safety net. > > > ~jon3 > > > > > > > I have seen TURN servers being deployed for several years with > > > re-direction > > > > but without the need for TTL (see ALTERNATE-SERVER in > > > > https://tools.ietf.org/html/draft-ietf-tram-turnbis-11) > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > -Tiru > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of=20 > > > > > > > mohamed.boucadair@orange.com > > > > > > > Sent: Thursday, April 5, 2018 4:50 PM > > > > > > > To: Konda, Tirumaleswar Reddy=20 > > > > > > > ; > > > > > > > Jon Shallow ; dots@ietf.org > > > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected=20 > > > > > > > Signaling > > > > > > > > > > > > > > Tiru, > > > > > > > > > > > > > > I don't see the NEW text as a restriction but as a=20 > > > > > > > simplification of the > > > > > > client's > > > > > > > behavior. I don't want to over-specify the redirect = behavior. > > > > > > > > > > > > > > Adding another yet layer of resolution will raise other=20 > > > > > > > issues such as the > > > > > > need to > > > > > > > associate a TTL with the name itself. > > > > > > > > > > > > > > Cheers, > > > > > > > Med > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Konda, Tirumaleswar=20 > > > > > > > > Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > > > Envoy=E9=A0: jeudi 5 avril 2018 12:06 =C0=A0: Jon = Shallow;=20 > > > > > > > > BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet=A0: > > > RE: > > > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > > > > > > Sent: Thursday, April 5, 2018 1:35 PM > > > > > > > > > To: mohamed.boucadair@orange.com; Konda, Tirumaleswar=20 > > > > > > > > > Reddy ; > > > > > > > > > dots@ietf.org > > > > > > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected=20 > > > > > > > > > Signaling > > > > > > > > > > > > > > > > > > Hi Med, > > > > > > > > > > > > > > > > > > Thanks for this refresh to 4.6 Redirected Signaling > > > > > > > > > > > > > > > > > > Some comments > > > > > > > > > > > > > > > > > > #1 > > > > > > > > > > > > > > > > > > The DOTS server can return the error response code > > > > > > > > > 3.00 in > > > > response > > > > > > > > > to a PUT request from the DOTS client or convey the = > > > > > > > > > error > > > > response > > > > > > > > > code 3.00 in a unidirectional notification response = > > > > > > > > > from the > > > > DOTS > > > > > > > > > server. > > > > > > > > > > > > > > > > > > Why is this limited to a PUT request and/or=20 > > > > > > > > > unidirectional notification > > > > > > > > response? > > > > > > > > > - Surely, any response, unsolicited or otherwise can=20 > > > > > > > > > contain a > > > > > > > > > 3.00 > > > > > > > > > - If Observe is not in use, then any unsolicited=20 > > > > > > > > > notification response will potentially get rejected by = > > > > > > > > > the coap library layer, so a DOTS Server cannot > > > > > > > > signal > > > > > > > > > maintenance outage other than by closing the session. > > > > > > > > > - I missed this the last review - sorry > > > > > > > > > > > > > > > > > > > > > > > > > > #2 > > > > > > > > > > > > > > > > > > If the DOTS client has been redirected to a DOTS=20 > > > > > > > > > server to > > > which > > > > it > > > > > > > > > has already sent the mitigation request within the=20 > > > > > > > > > last five > > > (5) > > > > > > > > > minutes, it MUST ignore the redirection and try to=20 > > > > > > > > > contact other DOTS > > > > > > > > > > > > > > > > > > s/ has already sent the mitigation request/ has=20 > > > > > > > > > already communicated with/ > > > > > > > > > > > > > > > > > > #3 > > > > > > > > > > > > > > > > > > A DOTS client MUST NOT use an alternate IP=20 > > > > > > > > > address to > > > contact > > > > its > > > > > > > > > DOTS server upon expiry of the associated TTL. > > > > > > > > > > > > > > > > > > To remove ambiguity over the use of FQDN, this could=20 > > > > > > > > > read > > > > > > > > > > > > > > > > > > A DOTS client MUST NOT use an alternate IP=20 > > > > > > > > > address to > > > contact > > > > its > > > > > > > > > DOTS server upon expiry of the associated TTL. > > > > > > > > > Furthermore, a > > > > > > DOTS > > > > > > > > > Client MUST NOT use the alt-server FQDN if all=20 > > > > > > > > > of the > > > > > > > > > alt-server- > > > > > > > > records > > > > > > > > > have expired. > > > > > > > > > > > > > > > > > > Or alternatively > > > > > > > > > > > > > > > > > > alt-server: FQDN of an alternate DOTS server. > > > > > > > > > > > > > > > > > > This could read > > > > > > > > > > > > > > > > > > alt-server: FQDN of an alternate DOTS server. =20 > > > > > > > > > This FQDN is not to be > > > > > > > > used for > > > > > > > > > looking up IP addresses to use, but is there for the=20 > > > > > > > > > SNI extension > > > > > > (7.1. > > > > > > > > (D)TLS > > > > > > > > > Protocol Profile) > > > > > > > > > > > > > > > > I don't think the above restriction is correct for the=20 > > > > > > > > following > > > > reasons: > > > > > > > > > > > > > > > > 1) If the TTL value in the alt-server-record expires,=20 > > > > > > > > DNS lookup can be performed by the DOTS client using the = > > > > > > > > alternate DOTS > > > server > > > > FQDN. > > > > > > > > 2) If the DNS server is reachable, the client may want=20 > > > > > > > > to a DANE lookup to get the IP addresses and certificate = > > > > > > > > to validate the alternate DOTS server certificate sent > > > > > > > > in the DTLS handshake. > > > > > > > > > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > Jon > > > > > > > > > -----Original Message----- > > > > > > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf=20 > > > > > > > > > Of mohamed.boucadair@orange.com > > > > > > > > > Sent: 05 April 2018 08:20 > > > > > > > > > To: Konda, Tirumaleswar Reddy; Jon Shallow;=20 > > > > > > > > > dots@ietf.org > > > > > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected=20 > > > > > > > > > Signaling > > > > > > > > > > > > > > > > > > Hi Tiru, > > > > > > > > > > > > > > > > > > Works for me. > > > > > > > > > > > > > > > > > > I updated the draft with the text additions that were=20 > > > > > > > > > discussed in this thread. The changes can be found at: > > > > > > > > > https://github.com/boucadair/draft-ietf-dots-signal- > > > > > > > > channel/blob/master/draf > > > > > > > > > t-ietf-dots-signal-channel.txt > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > Med > > > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Konda, = Tirumaleswar=20 > > > > > > > > > > Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > > > > > Envoy=E9=A0: mercredi 4 avril 2018 17:40 =C0=A0: Jon = > > > > > > > > > > Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet=A0: RE: > > > > > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > > > > > > The TTL value returned under alt-server-record is=20 > > > > > > > > > > equivalent to the DNS TTL value. A DDoS mitigation=20 > > > > > > > > > > provider with multiple DOTS servers typically=20 > > > > > > > > > > re-directs a DOTS client to a different DOTS server=20 > > > > > > > > > > only if the alternate DOTS server has the capacity=20 > > > > > > > > > > to handle the requests from the > > > > > > > > > DOTS client. > > > > > > > > > > > > > > > > > > > > We can add the following lines to avoid loops : > > > > > > > > > > > > > > > > > > > > If the DOTS client has been redirected to a DOTS=20 > > > > > > > > > > server to which it has already sent the mitigation=20 > > > > > > > > > > request within the last five minutes, it MUST ignore = > > > > > > > > > > the redirection and try reaching others servers=20 > > > > > > > > > > listed in the local configuration or discovered=20 > > > > > > > > > > using dynamic means > > such as DHCP or SRV procedures. > > > > > > > > > > This prevents infinite ping-ponging between servers=20 > > > > > > > > > > in case of redirection loops. > > > > > > > > > > > > > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Dots [mailto:dots-bounces@ietf.org] On=20 > > > > > > > > > > > Behalf Of Jon Shallow > > > > > > > > > > > Sent: Wednesday, April 4, 2018 8:16 PM > > > > > > > > > > > To: mohamed.boucadair@orange.com; dots@ietf.org > > > > > > > > > > > Subject: Re: [Dots] Signal Channel - 300=20 > > > > > > > > > > > Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > Hi there, > > > > > > > > > > > > > > > > > > > > > > See inline [Jon] > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Dots [mailto: dots-bounces@ietf.org] On=20 > > > > > > > > > > > Behalf Of mohamed.boucadair@orange.com > > > > > > > > > > > Sent: 04 April 2018 15:07 > > > > > > > > > > > To: Jon Shallow; dots@ietf.org > > > > > > > > > > > Subject: Re: [Dots] Signal Channel - 300=20 > > > > > > > > > > > Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > Re-, > > > > > > > > > > > > > > > > > > > > > > Please see inline. > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > Med > > > > > > > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Dots=20 > > > > > > > > > > > > [mailto:dots-bounces@ietf.org] De la part de Jon = > > > > > > > > > > > > Shallow Envoy=E9=A0: mercredi 4 avril 2018 15:31 = =C0=A0: > > > > > > > > > > > > dots@ietf.org > > > > > > Objet=A0: > > > > > > > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > > > Hi there, > > > > > > > > > > > > > > > > > > > > > > > > I have implemented the 300 Redirected-Signal in=20 > > > > > > > > > > > > my DOTS > > > code. > > > > > > > > > > > > This then raises some questions about usability. > > > > > > > > > > > > > > > > > > > > > > > > Usability #1 > > > > > > > > > > > > > > > > > > > > > > > > Architecture 3.2.2 Redirected Signalling > > > > > > > > > > > > > > > > > > > > > > > > 4. Having redirected the DOTS client, DOTS=20 > > > > > > > > > > > > server A ceases > > > > > > > > sending > > > > > > > > > > > > server signals. The DOTS client likewise = > > > > > > > > > > > > stops sending > > > > > > client > > > > > > > > > > > > signals to DOTS server A. DOTS session 1 = > > > > > > > > > > > > is > > > > terminated. > > > > > > > > > > > > > > > > > > > > > > > > Clearly indicates that the original session=20 > > > > > > > > > > > > (Client to Server > > > > > > > > > > > > A) is no more once redirected and only Client to = > > > > > > > > > > > > Server B is in > > > > > > use. > > > > > > > > > > > > > > > > > > > > > > > > How is the traffic redirected back to Server A=20 > > > > > > > > > > > > once maintenance / overloading etc. has = finished? > > > > > > > > > > > > My assumption is that Server B sends a redirect=20 > > > > > > > > > > > > to go back to Server A as Server A has no way to = > > > > > > > > > > > > say over a now non-existent session to say > > > > > > > "come back". > > > > > > > > > > > > > > > > > > > > > > [Med] That's one possibility. This one does not=20 > > > > > > > > > > > require any update to the > > > > > > > > > > signal- > > > > > > > > > > > channel specification. > > > > > > > > > > > > > > > > > > > > > > Another approach would be to not require any=20 > > > > > > > > > > > redirect signal from server > > > > > > > > > B. > > > > > > > > > > > The client will remove server B's records upon the = > > > > > > > > > > > expiry of the TTL and > > > > > > > > > > will fall > > > > > > > > > > > back to the "base" DOTS servers configuration that = > > > > > > > > > > > was provisioned to the > > > > > > > > > > client > > > > > > > > > > > using DHCP or whatever mechanism. > > > > > > > > > > > [Jon] OK. The TTL is defined at, associated with = > > > > > > > > > > > the IP address level > > > > > > > > > > under alt- > > > > > > > > > > > server-record, not under > > > > > > > > > > > ietf-dots-signal-channel:redirected-signal. The = ttl > > > > definition is > > > > > > > > > > > ambiguous as to what it refers to and perhaps=20 > > > > > > > > > > > could be tightened up in the language (I read it=20 > > > > > > > > > > > as being associated with "addr" in the sense of a=20 > > > > > > > > > > > DNS > > > > > > > > > > TTL). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Do we need to keep the existing Client to Server = > > > > > > > > > > > > A session warm (or perhaps to probe=20 > > > > > > > > > > > > periodically) to see if Server A is capable of=20 > > > > > > > > > > > > handling the Client again by a server response=20 > > > > > > > > > > > > extension to the protocol (e.g. a 3.01) > > > > > > > > > > > > > > > > > > > > > > [Med] Redirect was initially introduced to manage=20 > > > > > > > > > > > a server overload, so I > > > > > > > > > > don't > > > > > > > > > > > think it makes sense to probe or maintain a=20 > > > > > > > > > > > session with > > > server > > > > A. > > > > > > > > > > > [Jon] Agreed, but I needed to raise the question. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Should there be a retry period parameter added=20 > > > > > > > > > > > > in to the > > > > > > > > > > > > 3.00 protocol (as I read it, ttl only refers to=20 > > > > > > > > > > > > the IP > > > > address)? > > > > > > > > > > > > > > > > > > > > > > [Med] The client will automatically switch to=20 > > > > > > > > > > > Server A when all alternate > > > > > > > > > > records > > > > > > > > > > > expire. > > > > > > > > > > > [Jon] OK - again the 4.6 text needs to get=20 > > > > > > > > > > > tightened up to reflect this as > > > > > > > > > > the > > > > > > > > > > > intent. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Usability #2 > > > > > > > > > > > > > > > > > > > > > > > > Server A says "Redirect to Server B" due to > overloading. > > > > > > > > > > > > Server B accepts things for a while and then is=20 > > > > > > > > > > > > instructed/decides to redirect traffic back to = A. > > > > > > > > > > > > Server A is left still overload configured to=20 > > > > > > > > > > > > redirect to B. How should the client handle=20 > > > > > > > > > > > > this as there is no suitable > > > > > > > > > > > Server? > > > > > > > > > > > > > > > > > > > > > > [Med] This is a service configuration problem. We=20 > > > > > > > > > > > may > ask: > > > > > > > > > > > * the client to log the error and notify the > > administrator. > > > > > > > > > > > * and/or stop the redirection after n cycles. > > > > > > > > > > > > > > > > > > > > > > Still, this does not solve the problem. > > > > > > > > > > > [Jon] Agreed there is a problem here > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I agree that there needs to be co-ordination=20 > > > > > > > > > > > > between Server A and Server B, but user error=20 > > > > > > > > > > > > may > creep in. > > > > > > > > > > > > > > > > > > > > > > > > Usability #3 > > > > > > > > > > > > > > > > > > > > > > > > Server A says "Redirect to Server B" as it going = > > > > > > > > > > > > to be shut down because of maintenance. Server=20 > > > > > > > > > > > > B accepts things for a while and then is=20 > > > > > > > > > > > > instructed (in probable user > > > > > > > > > > > > error) to redirect traffic back to A (perhaps=20 > > > > > > > > > > > > because it has hit an overload condition). How=20 > > > > > > > > > > > > should the client > > > > > > > > > > > handle this? > > > > > > > > > > > > > > > > > > > > > > [Med] Isn't this a sub-case or #2? > > > > > > > > > > > [Jon] Yes, but I wanted to bring in Server A being = > > > > > > > > > > > alive and able to > > > > > > > > > > respond > > > > > > > > > > > versus Server A down and not responding due to > > maintenance. > > > > > > > > > > > [Jon] With my better understanding of TTL we still = > > > > > > > > > > > have an issue if the TTL expires and Server A is=20 > > > > > > > > > > > having an extended > > > > outage. > > > > > > > > > > > How do we recover from that? > > > > > > > > > > > ~jon > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > Dots mailing list Dots@ietf.org=20 > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > Dots mailing list > > > > > > > > > > > Dots@ietf.org > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > Dots mailing list > > > > > > > > > > > Dots@ietf.org > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > Dots mailing list > > > > > > > > > Dots@ietf.org > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Dots mailing list > > > > > > > Dots@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > _______________________________________________ > > > > Dots mailing list > > > > Dots@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots > > >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Sun Apr 8 23:51:14 2018 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 046B412704A for ; Sun, 8 Apr 2018 23:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 iWfm4YqwNFHH for ; Sun, 8 Apr 2018 23:51:09 -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 CE982124319 for ; Sun, 8 Apr 2018 23:51:08 -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=1523256668; 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: dlp-product:dlp-version:dlp-reaction: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-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-Network-Message-Id: 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=OX+vC/UdXZ6dLgwyFxHmW77mDgjA2r3J0qMcaa q85QY=; b=qGir8MgI6kJWuI+yxB8ZUfTt/0o0xpP7H1DeeOIx PxB6tQ1cdZlJZfo2vbh7kKBELyqp6209OnEk7nXGj+F14qx9zU GUr6UjGdhq1qEdYgwZAWeYRWhoy37un1lnBtH6n5BJ5Zg2kbaO TlDZZBiim1VGk7cIDx1soR7GFHLEyho= Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 16ce_7e4c_40e23a16_7815_4174_a0c7_441f74a8a41b; Mon, 09 Apr 2018 01:51:07 -0500 Received: from DNVEXUSR1N11.corpzone.internalzone.com (10.44.48.84) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 9 Apr 2018 00:51:06 -0600 Received: from DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) by DNVEXUSR1N11.corpzone.internalzone.com (10.44.48.84) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 9 Apr 2018 00:51:05 -0600 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Mon, 9 Apr 2018 00:51:04 -0600 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 9 Apr 2018 00:51:04 -0600 Received: from BN6PR16MB1425.namprd16.prod.outlook.com (10.172.207.19) by BN6PR16MB1811.namprd16.prod.outlook.com (10.172.28.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.653.12; Mon, 9 Apr 2018 06:51:02 +0000 Received: from BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d]) by BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d%2]) with mapi id 15.20.0653.015; Mon, 9 Apr 2018 06:51:02 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: [Dots] Signal Channel - 300 Redirected Signaling Thread-Index: AdPMGSyCaQQbv+vLSW+0gkDbU7HOEwAAo7xAAAH7T4AAARdqYAAhoxEAAAGQiwAAAKyNYAAF3e1QACUKCFAAAZEMQAAIeXTgAARcGhAAAoG7gAABGXwAAAAjBIAAAa5ZgAAAiReAAABpmzAAL32aAABWbPEw Date: Mon, 9 Apr 2018 06:51:02 +0000 Message-ID: References: <014f01d3cc19$2e3880e0$8aa982a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7E7B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <019901d3cc23$a93ff8e0$fbbfeaa0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8524@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <004e01d3ccb4$d505e7f0$7f11b7d0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8758@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEF912A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEF93EE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <008501d3cda6$c860d210$59227630$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF951 1@OPEXCLILMA3 . corporate.adroot.infra.ftgroup> <00b001d3cdab$ba8caec0$2fa60c40$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF975C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <00b801d3cdb4$982dc4a0$c8894de0$@jpshallow.com> <015101d3ce74$351393c0$9f3abb40$@jpshallow.com> In-Reply-To: <015101d3ce74$351393c0$9f3abb40$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR16MB1811; 7:Hybve7Arqr1yvBFWgxNYFZ54ddqHCX7Eg/isAj+SBqTZdO5thMGAVDIm/i5UG37o+BsgQH3mgFwi+YxWezMDoU/GyVz197s38kotrYhWDK3i4hqtyEMkwvueEPYrS5Cf9Ys1GWs9KC3+WcReQXxj2Gxr6sWN3nCnG9O8wVdHhoVewxUlr6N+wy20vHpdZlfdhuttCkSZhp20piGxNz4EKkuGY4hcSLnyqRuGdow3+YeJZMBNqYzWwze9Atn2ObR+ x-ms-exchange-antispam-srfa-diagnostics: SOS; X-MS-Office365-Filtering-Correlation-Id: b7f5d919-a5f3-4bd4-9c2f-08d59de642a7 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BN6PR16MB1811; x-ms-traffictypediagnostic: BN6PR16MB1811: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(166708455590820)(18271650672692)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231221)(944501327)(52105095)(6041310)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(6072148)(201708071742011); SRVR:BN6PR16MB1811; BCL:0; PCL:0; RULEID:; SRVR:BN6PR16MB1811; x-forefront-prvs: 0637FCE711 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39860400002)(39380400002)(396003)(366004)(376002)(13464003)(57704003)(32952001)(189003)(199004)(55784002)(446003)(97736004)(316002)(68736007)(476003)(110136005)(102836004)(486006)(53546011)(6506007)(59450400001)(76176011)(8676002)(26005)(55016002)(8936002)(14454004)(6436002)(966005)(6306002)(81156014)(99286004)(81166006)(93886005)(11346002)(186003)(305945005)(7736002)(106356001)(74316002)(86362001)(3846002)(33656002)(3280700002)(6116002)(25786009)(9686003)(6246003)(3660700001)(2201001)(72206003)(16200700003)(478600001)(105586002)(53936002)(2906002)(53946003)(2501003)(229853002)(5660300001)(80792005)(66066001)(5250100002)(2900100001)(7696005)(85282002)(569006); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR16MB1811; H:BN6PR16MB1425.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: rJfKslPw39R0Im6W/j2AgPJY4CdH/stoMRtAIt8SQzGebB0zqYSmFINEcEgAfXIiiHuMip7oXbGh1m0A1nIXRfU3wEQqllmHjXyY1VWgQWF2DdKmGWbM8brlsBM0FnX+Od4QzmmHgfpkxgSCESF/uPi5Lh9fzxsyHyXSVQTtSiH8/lJioIglli0SSS+quMalUIl2X4dPECVZPi2vKN7U6Sl2xp10CWnF75V3F70tn8+slG02TDwJ6emOLwJuI92ZTnYVSMoyzaQqQoGsoYNf9zLLYe/j8Ea2DSfOJ7lgxNkdRzF9fCfqeCUPBElX/bBhp86tNDbVynfQSKKBaGVxavpl+45SpHqafOtszfgUHtrs2H54aG2N1teEnbZUw2WNou2q49lEoeolLRdlCZ2Mf23deufUaYWGUhXtQ9b5QyE= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: b7f5d919-a5f3-4bd4-9c2f-08d59de642a7 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2018 06:51:02.7721 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR16MB1811 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6259> : inlines <6554> : streams <1783535> : uri <2622386> Archived-At: Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling 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, 09 Apr 2018 06:51:13 -0000 Hi Jon, I partially agree with the suggested update. A IP address is cached until = the TTL value expires, the DOTS client need not disconnect existing session= s after the TTL expires, but after the TTL expires it must consider the IP = address stale and not=20 establish new (D)TLS sessions. Cheers, -Tiru > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow > Sent: Saturday, April 7, 2018 6:58 PM > To: Konda, Tirumaleswar Reddy ; > mohamed.boucadair@orange.com; dots@ietf.org > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling >=20 > Hi there, >=20 > My suggestion would be to make ttl of -1 'infinite', otherwise have a min= imum > value of 300 seconds. The text could read (including referring to the op= tional > etc. to be consistent with the rest of the document:- >=20 > alt-server: FQDN of an alternate DOTS server. >=20 > This is a required attribute. >=20 > alt-server-record: A list of IP addresses of an alternate DOTS > server. >=20 > This is an optional attribute. >=20 > ttl: Time to live (TTL) of the alternate DOTS server, represented as > an integer number of seconds. That is, the time interval that the > alternate DOTS server may be used by a DOTS client. >=20 > The minimum value is '300' seconds, or '-1'. >=20 > '-1' means that the alternate DOTS server is to be used until the a= lternate > DOTS server redirects the traffic with another 3.00 response. > There is no TTL expiry. >=20 > If no 'ttl' is returned in a redirect response, this is equivalent > to returning a 'ttl' parameter set to '-1'. >=20 > If the alternate DOTS server TTL has expired, the DOTS client MUST > use the DOTS server(s) that was provisioned using means discussed > in Section 4.1. >=20 > This is an optional attribute. >=20 >=20 >=20 > Regards >=20 > Jon >=20 > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumalesw= ar > Reddy > Sent: 06 April 2018 15:55 > To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling >=20 > The below proposed change does not look good to me, its causing the DOTS > client to ping-pong between multiple DOTS servers because of the TTL valu= e. > The alternate server should serve the DOTS client till there is a planned > maintenance, if it is getting over-subscribed it should re-direct the new= DOTS > clients to an alternate server and avoid bouncing the existing DOTS clien= ts which > have been sending mitigation requests to it. >=20 > -Tiru >=20 > > -----Original Message----- > > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > Sent: Friday, April 6, 2018 8:06 PM > > To: mohamed.boucadair@orange.com; Konda, Tirumaleswar Reddy > > ; dots@ietf.org > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > Hi Med, > > > > Thanks for this. I would like to see the ttl: definition tightened up > > (moved away from the DNS TTL version) > > > > Old > > > > ttl: Time to live (TTL) of alternate records, represented as an > > integer number of seconds. That is, the time interval that > > alternate IP addresses may be cached by a DOTS client. > > > > '0' means that an alternate IP address is only to be used for the > > request in progress, and consequently that IP address should not > > be cached. > > > > If no 'ttl' is returned in a redirect response, this is equivalen= t > > to returning a 'ttl' parameter set to '0'. > > > > If 'alt-server-record' has expired, the DOTS client MUST use the > > DOTS server(s) that was provisioned using means discussed in > > Section 4.1. Furthermore, a DOTS client MUST NOT use the alt- > > server FQDN if the 'alt-server-records' has expired. > > > > New > > > > ttl: Time to live (TTL) of the alternate DOTS server, represented > > as > an > > integer number of seconds. That is, the time interval that > > the alternate DOTS server may be cached for use by a DOTS client. > > > > '0' means that the alternate DOTS server is only to be used for t= he > > request in progress, and consequently the alternate DOTS server > > entry should not > > be cached. > > > > If no 'ttl' is returned in a redirect response, this is equivalen= t > > to returning a 'ttl' parameter set to '0'. > > > > If the alternate DOTS server TTL has expired, the DOTS client > > MUST > use the > > DOTS server(s) that was provisioned using means discussed in > > Section 4.1. > > > > > > Regards > > > > Jon > > > > -----Original Message----- > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > mohamed.boucadair@orange.com > > Sent: 06 April 2018 15:21 > > To: Jon Shallow; Konda, Tirumaleswar Reddy; dots@ietf.org > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > FWIW, I implemented the change at: > > https://github.com/boucadair/draft-ietf-dots-signal-channel/blob/maste > > r/draf > > t-ietf-dots-signal-channel.txt > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > Envoy=E9=A0: vendredi 6 avril 2018 15:33 =C0=A0: BOUCADAIR Mohamed IM= T/OLN; > > > Konda, Tirumaleswar Reddy; dots@ietf.org Objet=A0: RE: [Dots] Signal > > > Channel - 300 Redirected Signaling > > > > > > Excellent. > > > > > > Thanks > > > > > > Jon > > > > > > -----Original Message----- > > > From: mohamed.boucadair@orange.com [mailto: > > > mohamed.boucadair@orange.com] > > > Sent: 06 April 2018 14:29 > > > To: Jon Shallow; Konda, Tirumaleswar Reddy; rdd@cert.org > > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > Hi Jon, all, > > > > > > I'm fine to put ttl at the level of alt-server. > > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > Envoy=E9=A0: vendredi 6 avril 2018 14:57 =C0=A0: BOUCADAIR Mohamed > > > > IMT/OLN; Konda, Tirumaleswar Reddy; rdd@cert.org Objet=A0: RE: > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > Hi there, > > > > > > > > See inline [Jon3] > > > > > > > > Regards > > > > > > > > Jon > > > > > > > > > > > > > > > -----Message d'origine----- > > > > > > > De=A0: Konda, Tirumaleswar Reddy > > > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > > Envoy=E9=A0: vendredi 6 avril 2018 07:07 =C0=A0: BOUCADAIR Mo= hamed > > > > > > > IMT/OLN; Jon Shallow; dots@ietf.org Objet=A0: RE: > > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > Hi Med, > > > > > > > > > > > > > > The proposed update restricts the client no to do a DNS > > > > > > > lookup using the alternate FQDN, further associating a TTL > > > > > > > with the name complicates the functionality on the DOTS > > > > > > > client to re-establish (D)TLS session with the primary DOTS > > > > > > > server after the > > > TTL expires. > > > > > > > My suggestion is to let the DOTS client continue to use the > > > > > > > alternate DOTS > > > > > server > > > > > > till it gets re-directed. > > > > > > > > > > > > [Med] This is possible with the current spec. > > > > > > > > > > > > Triggers for redirect and for falling back to the nominal > > > > > > configuration are deployment-specific. The current spec allows > > > > > > for almost all the cases > > > > > discussed > > > > > > so far: > > > > > > > > > > > > (1) Redirect for the request in progress: A server does so by > > > > > > returning > > > > > TTL=3D0. > > > > > > (2) The alternate server is not involved in fall back to the > > > > > > nominal > > > > > server: upon > > > > > > expiry of ttl of all alternate IP addresses, then fall back > > > > > > automatically > > > > > to the > > > > > > nominal server. > > > > > > (3) Redirect to an alternate server, which in turn will > > > > > > instruct the client > > > > > to > > > > > > redirect to the "base" configuration: a TTL is provided and > > > > > > the alternate > > > > > server > > > > > > can reply with a redirect code any time before the expiry of > > > > > > the TTL. A > > > > > long TTL > > > > > > can be returned if the alternate server will be responsible > > > > > > for > > > > > coordinating fall > > > > > > back to the base server. > > > > > > (4) Stop infinite redirects > > > > > > > > > > Yes, but (1) and (2) complicate the functionality of the DOTS > client. > > > > > > > > [Med] (1) and (2) is exactly the same functionality required for > > > > caching DNS replies. > > > > > > > > The > > > > > only reason for adding alt-server-record in the response is DNS > > > > > server may not be reachable by the DOTS server because of a DDoS > > attack. > > > > > > > > > > > > > [Med] Yes. Note that even if the name resolution was allowed, the > > > > client has to deal with the TTL indicated in the response...which > > > > is exactly the same as (1) and (2). > > > > > > > > > > > > [Jon3] I think where I am struggling here is the overloaded use of > > > > TTL > > > > - The TTL as per a DNS record and held as a part of > > > > alt-server-record and then the TTL after which that the alt-server > > > > should be handling the traffic before handling back to the > > > > original primary server. It either has to be one or the other, or > > > > they have to > > have different names. > > > > [Jon3] If we are only going to go for one variant for simplicity, > > > > then I would prefer that it should be at the level of "alt-server". > > > > Handling the TTL for DNS refresh is normally handled by a resolver > > > > library, updated by the DNS packets coming in - unusual for an > > > > application > > > to have to do that. > > > > > > > > > > > > > > > > > > > > > > I > > > > > > > don't think the DOTS mitigation provider will know > > > > > > > ahead-of-time the TTL value after which the DOTS client > > > > > > > should disconnect communicating with the alternate DOTS > > > > > > > server and re-establish (D)TLS session with the primary DOTS > server. > > > > > > > > > > > > [Med] It depends on the nature of the redirect: overload, > > > > > > planned > > > > > maintenance, > > > > > > etc. For planned maintenance, the TTL is known in general. > > > > > > > > > > It's the primary DOTS server responsibility to point the DOTS > > > > > client to an optimal alternate server, where the client can > > > > > continue to send migration requests without a frequent ping-pong > > between servers. > > > > > > > > [Med] Agree. This is a service configuration problem. > > > > [Jon3] Agreed - and the 5 minute minimum ping-pong time is a good > > > > safety net. > > > > ~jon3 > > > > > > > > > I have seen TURN servers being deployed for several years with > > > > re-direction > > > > > but without the need for TTL (see ALTERNATE-SERVER in > > > > > https://tools.ietf.org/html/draft-ietf-tram-turnbis-11) > > > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > -Tiru > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of > > > > > > > > mohamed.boucadair@orange.com > > > > > > > > Sent: Thursday, April 5, 2018 4:50 PM > > > > > > > > To: Konda, Tirumaleswar Reddy > > > > > > > > ; > > > > > > > > Jon Shallow ; dots@ietf.org > > > > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected > > > > > > > > Signaling > > > > > > > > > > > > > > > > Tiru, > > > > > > > > > > > > > > > > I don't see the NEW text as a restriction but as a > > > > > > > > simplification of the > > > > > > > client's > > > > > > > > behavior. I don't want to over-specify the redirect behavio= r. > > > > > > > > > > > > > > > > Adding another yet layer of resolution will raise other > > > > > > > > issues such as the > > > > > > > need to > > > > > > > > associate a TTL with the name itself. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Med > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Konda, Tirumaleswar > > > > > > > > > Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > > > > Envoy=E9=A0: jeudi 5 avril 2018 12:06 =C0=A0: Jon Shallow= ; > > > > > > > > > BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet=A0: > > > > RE: > > > > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > > > > > > > Sent: Thursday, April 5, 2018 1:35 PM > > > > > > > > > > To: mohamed.boucadair@orange.com; Konda, Tirumaleswar > > > > > > > > > > Reddy ; > > > > > > > > > > dots@ietf.org > > > > > > > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected > > > > > > > > > > Signaling > > > > > > > > > > > > > > > > > > > > Hi Med, > > > > > > > > > > > > > > > > > > > > Thanks for this refresh to 4.6 Redirected Signaling > > > > > > > > > > > > > > > > > > > > Some comments > > > > > > > > > > > > > > > > > > > > #1 > > > > > > > > > > > > > > > > > > > > The DOTS server can return the error response code > > > > > > > > > > 3.00 in > > > > > response > > > > > > > > > > to a PUT request from the DOTS client or convey the > > > > > > > > > > error > > > > > response > > > > > > > > > > code 3.00 in a unidirectional notification response > > > > > > > > > > from the > > > > > DOTS > > > > > > > > > > server. > > > > > > > > > > > > > > > > > > > > Why is this limited to a PUT request and/or > > > > > > > > > > unidirectional notification > > > > > > > > > response? > > > > > > > > > > - Surely, any response, unsolicited or otherwise can > > > > > > > > > > contain a > > > > > > > > > > 3.00 > > > > > > > > > > - If Observe is not in use, then any unsolicited > > > > > > > > > > notification response will potentially get rejected by > > > > > > > > > > the coap library layer, so a DOTS Server cannot > > > > > > > > > signal > > > > > > > > > > maintenance outage other than by closing the session. > > > > > > > > > > - I missed this the last review - sorry > > > > > > > > > > > > > > > > > > > > > > > > > > > > > #2 > > > > > > > > > > > > > > > > > > > > If the DOTS client has been redirected to a DOTS > > > > > > > > > > server to > > > > which > > > > > it > > > > > > > > > > has already sent the mitigation request within the > > > > > > > > > > last five > > > > (5) > > > > > > > > > > minutes, it MUST ignore the redirection and try to > > > > > > > > > > contact other DOTS > > > > > > > > > > > > > > > > > > > > s/ has already sent the mitigation request/ has > > > > > > > > > > already communicated with/ > > > > > > > > > > > > > > > > > > > > #3 > > > > > > > > > > > > > > > > > > > > A DOTS client MUST NOT use an alternate IP > > > > > > > > > > address to > > > > contact > > > > > its > > > > > > > > > > DOTS server upon expiry of the associated TTL. > > > > > > > > > > > > > > > > > > > > To remove ambiguity over the use of FQDN, this could > > > > > > > > > > read > > > > > > > > > > > > > > > > > > > > A DOTS client MUST NOT use an alternate IP > > > > > > > > > > address to > > > > contact > > > > > its > > > > > > > > > > DOTS server upon expiry of the associated TTL. > > > > > > > > > > Furthermore, a > > > > > > > DOTS > > > > > > > > > > Client MUST NOT use the alt-server FQDN if all > > > > > > > > > > of the > > > > > > > > > > alt-server- > > > > > > > > > records > > > > > > > > > > have expired. > > > > > > > > > > > > > > > > > > > > Or alternatively > > > > > > > > > > > > > > > > > > > > alt-server: FQDN of an alternate DOTS server. > > > > > > > > > > > > > > > > > > > > This could read > > > > > > > > > > > > > > > > > > > > alt-server: FQDN of an alternate DOTS server. > > > > > > > > > > This FQDN is not to be > > > > > > > > > used for > > > > > > > > > > looking up IP addresses to use, but is there for the > > > > > > > > > > SNI extension > > > > > > > (7.1. > > > > > > > > > (D)TLS > > > > > > > > > > Protocol Profile) > > > > > > > > > > > > > > > > > > I don't think the above restriction is correct for the > > > > > > > > > following > > > > > reasons: > > > > > > > > > > > > > > > > > > 1) If the TTL value in the alt-server-record expires, > > > > > > > > > DNS lookup can be performed by the DOTS client using the > > > > > > > > > alternate DOTS > > > > server > > > > > FQDN. > > > > > > > > > 2) If the DNS server is reachable, the client may want > > > > > > > > > to a DANE lookup to get the IP addresses and certificate > > > > > > > > > to validate the alternate DOTS server certificate sent > > > > > > > > > in the DTLS handshake. > > > > > > > > > > > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > > > Jon > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf > > > > > > > > > > Of mohamed.boucadair@orange.com > > > > > > > > > > Sent: 05 April 2018 08:20 > > > > > > > > > > To: Konda, Tirumaleswar Reddy; Jon Shallow; > > > > > > > > > > dots@ietf.org > > > > > > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected > > > > > > > > > > Signaling > > > > > > > > > > > > > > > > > > > > Hi Tiru, > > > > > > > > > > > > > > > > > > > > Works for me. > > > > > > > > > > > > > > > > > > > > I updated the draft with the text additions that were > > > > > > > > > > discussed in this thread. The changes can be found at: > > > > > > > > > > https://github.com/boucadair/draft-ietf-dots-signal- > > > > > > > > > channel/blob/master/draf > > > > > > > > > > t-ietf-dots-signal-channel.txt > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > Med > > > > > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Konda, Tirumaleswa= r > > > > > > > > > > > Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > > > > > > Envoy=E9=A0: mercredi 4 avril 2018 17:40 =C0=A0: Jon > > > > > > > > > > > Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org > Objet=A0: RE: > > > > > > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > The TTL value returned under alt-server-record is > > > > > > > > > > > equivalent to the DNS TTL value. A DDoS mitigation > > > > > > > > > > > provider with multiple DOTS servers typically > > > > > > > > > > > re-directs a DOTS client to a different DOTS server > > > > > > > > > > > only if the alternate DOTS server has the capacity > > > > > > > > > > > to handle the requests from the > > > > > > > > > > DOTS client. > > > > > > > > > > > > > > > > > > > > > > We can add the following lines to avoid loops : > > > > > > > > > > > > > > > > > > > > > > If the DOTS client has been redirected to a DOTS > > > > > > > > > > > server to which it has already sent the mitigation > > > > > > > > > > > request within the last five minutes, it MUST ignore > > > > > > > > > > > the redirection and try reaching others servers > > > > > > > > > > > listed in the local configuration or discovered > > > > > > > > > > > using dynamic means > > > such as DHCP or SRV procedures. > > > > > > > > > > > This prevents infinite ping-ponging between servers > > > > > > > > > > > in case of redirection loops. > > > > > > > > > > > > > > > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: Dots [mailto:dots-bounces@ietf.org] On > > > > > > > > > > > > Behalf Of Jon Shallow > > > > > > > > > > > > Sent: Wednesday, April 4, 2018 8:16 PM > > > > > > > > > > > > To: mohamed.boucadair@orange.com; dots@ietf.org > > > > > > > > > > > > Subject: Re: [Dots] Signal Channel - 300 > > > > > > > > > > > > Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > > > Hi there, > > > > > > > > > > > > > > > > > > > > > > > > See inline [Jon] > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: Dots [mailto: dots-bounces@ietf.org] On > > > > > > > > > > > > Behalf Of mohamed.boucadair@orange.com > > > > > > > > > > > > Sent: 04 April 2018 15:07 > > > > > > > > > > > > To: Jon Shallow; dots@ietf.org > > > > > > > > > > > > Subject: Re: [Dots] Signal Channel - 300 > > > > > > > > > > > > Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > > > Re-, > > > > > > > > > > > > > > > > > > > > > > > > Please see inline. > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > Med > > > > > > > > > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Dots > > > > > > > > > > > > > [mailto:dots-bounces@ietf.org] De la part de Jon > > > > > > > > > > > > > Shallow Envoy=E9=A0: mercredi 4 avril 2018 15:31 = =C0=A0: > > > > > > > > > > > > > dots@ietf.org > > > > > > > Objet=A0: > > > > > > > > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > Hi there, > > > > > > > > > > > > > > > > > > > > > > > > > > I have implemented the 300 Redirected-Signal in > > > > > > > > > > > > > my DOTS > > > > code. > > > > > > > > > > > > > This then raises some questions about usability. > > > > > > > > > > > > > > > > > > > > > > > > > > Usability #1 > > > > > > > > > > > > > > > > > > > > > > > > > > Architecture 3.2.2 Redirected Signalling > > > > > > > > > > > > > > > > > > > > > > > > > > 4. Having redirected the DOTS client, DOTS > > > > > > > > > > > > > server A ceases > > > > > > > > > sending > > > > > > > > > > > > > server signals. The DOTS client likewise > > > > > > > > > > > > > stops sending > > > > > > > client > > > > > > > > > > > > > signals to DOTS server A. DOTS session 1 > > > > > > > > > > > > > is > > > > > terminated. > > > > > > > > > > > > > > > > > > > > > > > > > > Clearly indicates that the original session > > > > > > > > > > > > > (Client to Server > > > > > > > > > > > > > A) is no more once redirected and only Client to > > > > > > > > > > > > > Server B is in > > > > > > > use. > > > > > > > > > > > > > > > > > > > > > > > > > > How is the traffic redirected back to Server A > > > > > > > > > > > > > once maintenance / overloading etc. has finished? > > > > > > > > > > > > > My assumption is that Server B sends a redirect > > > > > > > > > > > > > to go back to Server A as Server A has no way to > > > > > > > > > > > > > say over a now non-existent session to say > > > > > > > > "come back". > > > > > > > > > > > > > > > > > > > > > > > > [Med] That's one possibility. This one does not > > > > > > > > > > > > require any update to the > > > > > > > > > > > signal- > > > > > > > > > > > > channel specification. > > > > > > > > > > > > > > > > > > > > > > > > Another approach would be to not require any > > > > > > > > > > > > redirect signal from server > > > > > > > > > > B. > > > > > > > > > > > > The client will remove server B's records upon the > > > > > > > > > > > > expiry of the TTL and > > > > > > > > > > > will fall > > > > > > > > > > > > back to the "base" DOTS servers configuration that > > > > > > > > > > > > was provisioned to the > > > > > > > > > > > client > > > > > > > > > > > > using DHCP or whatever mechanism. > > > > > > > > > > > > [Jon] OK. The TTL is defined at, associated with > > > > > > > > > > > > the IP address level > > > > > > > > > > > under alt- > > > > > > > > > > > > server-record, not under > > > > > > > > > > > > ietf-dots-signal-channel:redirected-signal. The t= tl > > > > > definition is > > > > > > > > > > > > ambiguous as to what it refers to and perhaps > > > > > > > > > > > > could be tightened up in the language (I read it > > > > > > > > > > > > as being associated with "addr" in the sense of a > > > > > > > > > > > > DNS > > > > > > > > > > > TTL). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Do we need to keep the existing Client to Server > > > > > > > > > > > > > A session warm (or perhaps to probe > > > > > > > > > > > > > periodically) to see if Server A is capable of > > > > > > > > > > > > > handling the Client again by a server response > > > > > > > > > > > > > extension to the protocol (e.g. a 3.01) > > > > > > > > > > > > > > > > > > > > > > > > [Med] Redirect was initially introduced to manage > > > > > > > > > > > > a server overload, so I > > > > > > > > > > > don't > > > > > > > > > > > > think it makes sense to probe or maintain a > > > > > > > > > > > > session with > > > > server > > > > > A. > > > > > > > > > > > > [Jon] Agreed, but I needed to raise the question. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Should there be a retry period parameter added > > > > > > > > > > > > > in to the > > > > > > > > > > > > > 3.00 protocol (as I read it, ttl only refers to > > > > > > > > > > > > > the IP > > > > > address)? > > > > > > > > > > > > > > > > > > > > > > > > [Med] The client will automatically switch to > > > > > > > > > > > > Server A when all alternate > > > > > > > > > > > records > > > > > > > > > > > > expire. > > > > > > > > > > > > [Jon] OK - again the 4.6 text needs to get > > > > > > > > > > > > tightened up to reflect this as > > > > > > > > > > > the > > > > > > > > > > > > intent. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Usability #2 > > > > > > > > > > > > > > > > > > > > > > > > > > Server A says "Redirect to Server B" due to > > overloading. > > > > > > > > > > > > > Server B accepts things for a while and then is > > > > > > > > > > > > > instructed/decides to redirect traffic back to A. > > > > > > > > > > > > > Server A is left still overload configured to > > > > > > > > > > > > > redirect to B. How should the client handle > > > > > > > > > > > > > this as there is no suitable > > > > > > > > > > > > Server? > > > > > > > > > > > > > > > > > > > > > > > > [Med] This is a service configuration problem. We > > > > > > > > > > > > may > > ask: > > > > > > > > > > > > * the client to log the error and notify the > > > administrator. > > > > > > > > > > > > * and/or stop the redirection after n cycles. > > > > > > > > > > > > > > > > > > > > > > > > Still, this does not solve the problem. > > > > > > > > > > > > [Jon] Agreed there is a problem here > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I agree that there needs to be co-ordination > > > > > > > > > > > > > between Server A and Server B, but user error > > > > > > > > > > > > > may > > creep in. > > > > > > > > > > > > > > > > > > > > > > > > > > Usability #3 > > > > > > > > > > > > > > > > > > > > > > > > > > Server A says "Redirect to Server B" as it going > > > > > > > > > > > > > to be shut down because of maintenance. Server > > > > > > > > > > > > > B accepts things for a while and then is > > > > > > > > > > > > > instructed (in probable user > > > > > > > > > > > > > error) to redirect traffic back to A (perhaps > > > > > > > > > > > > > because it has hit an overload condition). How > > > > > > > > > > > > > should the client > > > > > > > > > > > > handle this? > > > > > > > > > > > > > > > > > > > > > > > > [Med] Isn't this a sub-case or #2? > > > > > > > > > > > > [Jon] Yes, but I wanted to bring in Server A being > > > > > > > > > > > > alive and able to > > > > > > > > > > > respond > > > > > > > > > > > > versus Server A down and not responding due to > > > maintenance. > > > > > > > > > > > > [Jon] With my better understanding of TTL we still > > > > > > > > > > > > have an issue if the TTL expires and Server A is > > > > > > > > > > > > having an extended > > > > > outage. > > > > > > > > > > > > How do we recover from that? > > > > > > > > > > > > ~jon > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > Dots mailing list Dots@ietf.org > > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > Dots mailing list > > > > > > > > > > > > Dots@ietf.org > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > Dots mailing list > > > > > > > > > > > > Dots@ietf.org > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > Dots mailing list > > > > > > > > > > Dots@ietf.org > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Dots mailing list > > > > > > > > Dots@ietf.org > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > _______________________________________________ > > > > > Dots mailing list > > > > > Dots@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > _______________________________________________ > > > > Dots mailing list > > > > Dots@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Mon Apr 9 00:45:10 2018 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 DCF47127522 for ; Mon, 9 Apr 2018 00:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5OmuJ8unIdV for ; Mon, 9 Apr 2018 00:45:01 -0700 (PDT) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68D2F12711B for ; Mon, 9 Apr 2018 00:45:01 -0700 (PDT) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 10D1FC08FE; Mon, 9 Apr 2018 09:45:00 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.61]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id DEBCA180098; Mon, 9 Apr 2018 09:44:59 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7E.corporate.adroot.infra.ftgroup ([fe80::b91c:ea2c:ac8a:7462%19]) with mapi id 14.03.0382.000; Mon, 9 Apr 2018 09:44:59 +0200 From: To: "Konda, Tirumaleswar Reddy" , "Jon Shallow" , "dots@ietf.org" Thread-Topic: [Dots] Signal Channel - 300 Redirected Signaling Thread-Index: AQJ5xX4UsK17va5Vv37fpNudI6+9awAAo7xAAAH7T4AAARdqYAAhoxEAAAGQiwAAAKyNYAAF3e1QACUKCFAAAZEMQAAIeXTgAARcGhAAAoG7gAABGXwAAAAjBIAAAa5ZgAAAiReAAABpmzAAL32aAABWbPEwoqS3ekA= Date: Mon, 9 Apr 2018 07:44:58 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DEFA190@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <014f01d3cc19$2e3880e0$8aa982a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7E7B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <019901d3cc23$a93ff8e0$fbbfeaa0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8524@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <004e01d3ccb4$d505e7f0$7f11b7d0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8758@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEF912A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEF93EE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <008501d3cda6$c860d210$59227630$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF951 1@OPEXCLILMA3 . corporate.adroot.infra.ftgroup> <00b001d3cdab$ba8caec0$2fa60c40$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF975C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <00b801d3cdb4$982dc4a0$c8894de0$@jpshallow.com> <015101d3ce74$351393c0$9f3abb40$@jpshallow.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling 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, 09 Apr 2018 07:45:06 -0000 Tiru,=20 What about this update ones? =3D=3D=3D=3D=3D=3D=3D ttl: Time to live (TTL) of the alternate DOTS server, represented as an integer number of seconds. That is, the time interval that the alternate DOTS server may be cached for use by a DOTS client. A lifetime of negative one (-1) indicates indefinite TTL. This value means that the alternate DOTS server is to be used until the alternate DOTS server redirects the traffic with another 3.00 response. If no 'ttl' is returned in a redirect response, this is equivalent to returning a 'ttl' parameter set to '-1'. If the alternate DOTS server TTL has expired, the DOTS client MUST use the DOTS server(s), that was provisioned using means discussed in Section 4.1, for creating new requests. This is an optional attribute. =3D=3D=3D Cheers, Med > -----Message d'origine----- > De=A0: Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.c= om] > Envoy=E9=A0: lundi 9 avril 2018 08:51 > =C0=A0: Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org > Objet=A0: RE: [Dots] Signal Channel - 300 Redirected Signaling >=20 > Hi Jon, >=20 > I partially agree with the suggested update. A IP address is cached unti= l > the TTL value expires, the DOTS client need not disconnect existing sessi= ons > after the TTL expires, but after the TTL expires it must consider the IP > address stale and not > establish new (D)TLS sessions. >=20 > Cheers, > -Tiru >=20 > > -----Original Message----- > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow > > Sent: Saturday, April 7, 2018 6:58 PM > > To: Konda, Tirumaleswar Reddy ; > > mohamed.boucadair@orange.com; dots@ietf.org > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > Hi there, > > > > My suggestion would be to make ttl of -1 'infinite', otherwise have a > minimum > > value of 300 seconds. The text could read (including referring to the > optional > > etc. to be consistent with the rest of the document:- > > > > alt-server: FQDN of an alternate DOTS server. > > > > This is a required attribute. > > > > alt-server-record: A list of IP addresses of an alternate DOTS > > server. > > > > This is an optional attribute. > > > > ttl: Time to live (TTL) of the alternate DOTS server, represented a= s > > an integer number of seconds. That is, the time interval that th= e > > alternate DOTS server may be used by a DOTS client. > > > > The minimum value is '300' seconds, or '-1'. > > > > '-1' means that the alternate DOTS server is to be used until the > alternate > > DOTS server redirects the traffic with another 3.00 response. > > There is no TTL expiry. > > > > If no 'ttl' is returned in a redirect response, this is equivalen= t > > to returning a 'ttl' parameter set to '-1'. > > > > If the alternate DOTS server TTL has expired, the DOTS client MUS= T > > use the DOTS server(s) that was provisioned using means discussed > > in Section 4.1. > > > > This is an optional attribute. > > > > > > > > Regards > > > > Jon > > > > -----Original Message----- > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumale= swar > > Reddy > > Sent: 06 April 2018 15:55 > > To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > The below proposed change does not look good to me, its causing the DOT= S > > client to ping-pong between multiple DOTS servers because of the TTL va= lue. > > The alternate server should serve the DOTS client till there is a plann= ed > > maintenance, if it is getting over-subscribed it should re-direct the n= ew > DOTS > > clients to an alternate server and avoid bouncing the existing DOTS cli= ents > which > > have been sending mitigation requests to it. > > > > -Tiru > > > > > -----Original Message----- > > > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > Sent: Friday, April 6, 2018 8:06 PM > > > To: mohamed.boucadair@orange.com; Konda, Tirumaleswar Reddy > > > ; dots@ietf.org > > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > Hi Med, > > > > > > Thanks for this. I would like to see the ttl: definition tightened u= p > > > (moved away from the DNS TTL version) > > > > > > Old > > > > > > ttl: Time to live (TTL) of alternate records, represented as an > > > integer number of seconds. That is, the time interval that > > > alternate IP addresses may be cached by a DOTS client. > > > > > > '0' means that an alternate IP address is only to be used for t= he > > > request in progress, and consequently that IP address should no= t > > > be cached. > > > > > > If no 'ttl' is returned in a redirect response, this is equival= ent > > > to returning a 'ttl' parameter set to '0'. > > > > > > If 'alt-server-record' has expired, the DOTS client MUST use th= e > > > DOTS server(s) that was provisioned using means discussed in > > > Section 4.1. Furthermore, a DOTS client MUST NOT use the alt- > > > server FQDN if the 'alt-server-records' has expired. > > > > > > New > > > > > > ttl: Time to live (TTL) of the alternate DOTS server, represented > > > as > > an > > > integer number of seconds. That is, the time interval that > > > the alternate DOTS server may be cached for use by a DOTS clien= t. > > > > > > '0' means that the alternate DOTS server is only to be used for= the > > > request in progress, and consequently the alternate DOTS server > > > entry should not > > > be cached. > > > > > > If no 'ttl' is returned in a redirect response, this is equival= ent > > > to returning a 'ttl' parameter set to '0'. > > > > > > If the alternate DOTS server TTL has expired, the DOTS client > > > MUST > > use the > > > DOTS server(s) that was provisioned using means discussed in > > > Section 4.1. > > > > > > > > > Regards > > > > > > Jon > > > > > > -----Original Message----- > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > > mohamed.boucadair@orange.com > > > Sent: 06 April 2018 15:21 > > > To: Jon Shallow; Konda, Tirumaleswar Reddy; dots@ietf.org > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > FWIW, I implemented the change at: > > > https://github.com/boucadair/draft-ietf-dots-signal-channel/blob/mast= e > > > r/draf > > > t-ietf-dots-signal-channel.txt > > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > Envoy=E9=A0: vendredi 6 avril 2018 15:33 =C0=A0: BOUCADAIR Mohamed = IMT/OLN; > > > > Konda, Tirumaleswar Reddy; dots@ietf.org Objet=A0: RE: [Dots] Signa= l > > > > Channel - 300 Redirected Signaling > > > > > > > > Excellent. > > > > > > > > Thanks > > > > > > > > Jon > > > > > > > > -----Original Message----- > > > > From: mohamed.boucadair@orange.com [mailto: > > > > mohamed.boucadair@orange.com] > > > > Sent: 06 April 2018 14:29 > > > > To: Jon Shallow; Konda, Tirumaleswar Reddy; rdd@cert.org > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > Hi Jon, all, > > > > > > > > I'm fine to put ttl at the level of alt-server. > > > > > > > > Cheers, > > > > Med > > > > > > > > > -----Message d'origine----- > > > > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > > Envoy=E9=A0: vendredi 6 avril 2018 14:57 =C0=A0: BOUCADAIR Mohame= d > > > > > IMT/OLN; Konda, Tirumaleswar Reddy; rdd@cert.org Objet=A0: RE: > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > Hi there, > > > > > > > > > > See inline [Jon3] > > > > > > > > > > Regards > > > > > > > > > > Jon > > > > > > > > > > > > > > > > > > -----Message d'origine----- > > > > > > > > De=A0: Konda, Tirumaleswar Reddy > > > > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > > > Envoy=E9=A0: vendredi 6 avril 2018 07:07 =C0=A0: BOUCADAIR = Mohamed > > > > > > > > IMT/OLN; Jon Shallow; dots@ietf.org Objet=A0: RE: > > > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > > Hi Med, > > > > > > > > > > > > > > > > The proposed update restricts the client no to do a DNS > > > > > > > > lookup using the alternate FQDN, further associating a TTL > > > > > > > > with the name complicates the functionality on the DOTS > > > > > > > > client to re-establish (D)TLS session with the primary DOTS > > > > > > > > server after the > > > > TTL expires. > > > > > > > > My suggestion is to let the DOTS client continue to use the > > > > > > > > alternate DOTS > > > > > > server > > > > > > > till it gets re-directed. > > > > > > > > > > > > > > [Med] This is possible with the current spec. > > > > > > > > > > > > > > Triggers for redirect and for falling back to the nominal > > > > > > > configuration are deployment-specific. The current spec allow= s > > > > > > > for almost all the cases > > > > > > discussed > > > > > > > so far: > > > > > > > > > > > > > > (1) Redirect for the request in progress: A server does so by > > > > > > > returning > > > > > > TTL=3D0. > > > > > > > (2) The alternate server is not involved in fall back to the > > > > > > > nominal > > > > > > server: upon > > > > > > > expiry of ttl of all alternate IP addresses, then fall back > > > > > > > automatically > > > > > > to the > > > > > > > nominal server. > > > > > > > (3) Redirect to an alternate server, which in turn will > > > > > > > instruct the client > > > > > > to > > > > > > > redirect to the "base" configuration: a TTL is provided and > > > > > > > the alternate > > > > > > server > > > > > > > can reply with a redirect code any time before the expiry of > > > > > > > the TTL. A > > > > > > long TTL > > > > > > > can be returned if the alternate server will be responsible > > > > > > > for > > > > > > coordinating fall > > > > > > > back to the base server. > > > > > > > (4) Stop infinite redirects > > > > > > > > > > > > Yes, but (1) and (2) complicate the functionality of the DOTS > > client. > > > > > > > > > > [Med] (1) and (2) is exactly the same functionality required for > > > > > caching DNS replies. > > > > > > > > > > The > > > > > > only reason for adding alt-server-record in the response is DNS > > > > > > server may not be reachable by the DOTS server because of a DDo= S > > > attack. > > > > > > > > > > > > > > > > [Med] Yes. Note that even if the name resolution was allowed, the > > > > > client has to deal with the TTL indicated in the response...which > > > > > is exactly the same as (1) and (2). > > > > > > > > > > > > > > > [Jon3] I think where I am struggling here is the overloaded use o= f > > > > > TTL > > > > > - The TTL as per a DNS record and held as a part of > > > > > alt-server-record and then the TTL after which that the alt-serve= r > > > > > should be handling the traffic before handling back to the > > > > > original primary server. It either has to be one or the other, o= r > > > > > they have to > > > have different names. > > > > > [Jon3] If we are only going to go for one variant for simplicity, > > > > > then I would prefer that it should be at the level of "alt-server= ". > > > > > Handling the TTL for DNS refresh is normally handled by a resolve= r > > > > > library, updated by the DNS packets coming in - unusual for an > > > > > application > > > > to have to do that. > > > > > > > > > > > > > > > > > > > > > > > > > > I > > > > > > > > don't think the DOTS mitigation provider will know > > > > > > > > ahead-of-time the TTL value after which the DOTS client > > > > > > > > should disconnect communicating with the alternate DOTS > > > > > > > > server and re-establish (D)TLS session with the primary DOT= S > > server. > > > > > > > > > > > > > > [Med] It depends on the nature of the redirect: overload, > > > > > > > planned > > > > > > maintenance, > > > > > > > etc. For planned maintenance, the TTL is known in general. > > > > > > > > > > > > It's the primary DOTS server responsibility to point the DOTS > > > > > > client to an optimal alternate server, where the client can > > > > > > continue to send migration requests without a frequent ping-pon= g > > > between servers. > > > > > > > > > > [Med] Agree. This is a service configuration problem. > > > > > [Jon3] Agreed - and the 5 minute minimum ping-pong time is a good > > > > > safety net. > > > > > ~jon3 > > > > > > > > > > > I have seen TURN servers being deployed for several years with > > > > > re-direction > > > > > > but without the need for TTL (see ALTERNATE-SERVER in > > > > > > https://tools.ietf.org/html/draft-ietf-tram-turnbis-11) > > > > > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of > > > > > > > > > mohamed.boucadair@orange.com > > > > > > > > > Sent: Thursday, April 5, 2018 4:50 PM > > > > > > > > > To: Konda, Tirumaleswar Reddy > > > > > > > > > ; > > > > > > > > > Jon Shallow ; dots@ietf.org > > > > > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected > > > > > > > > > Signaling > > > > > > > > > > > > > > > > > > Tiru, > > > > > > > > > > > > > > > > > > I don't see the NEW text as a restriction but as a > > > > > > > > > simplification of the > > > > > > > > client's > > > > > > > > > behavior. I don't want to over-specify the redirect behav= ior. > > > > > > > > > > > > > > > > > > Adding another yet layer of resolution will raise other > > > > > > > > > issues such as the > > > > > > > > need to > > > > > > > > > associate a TTL with the name itself. > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > Med > > > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Konda, Tirumaleswar > > > > > > > > > > Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > > > > > Envoy=E9=A0: jeudi 5 avril 2018 12:06 =C0=A0: Jon Shall= ow; > > > > > > > > > > BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet=A0: > > > > > RE: > > > > > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > > > > > > > > Sent: Thursday, April 5, 2018 1:35 PM > > > > > > > > > > > To: mohamed.boucadair@orange.com; Konda, Tirumaleswar > > > > > > > > > > > Reddy ; > > > > > > > > > > > dots@ietf.org > > > > > > > > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected > > > > > > > > > > > Signaling > > > > > > > > > > > > > > > > > > > > > > Hi Med, > > > > > > > > > > > > > > > > > > > > > > Thanks for this refresh to 4.6 Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > Some comments > > > > > > > > > > > > > > > > > > > > > > #1 > > > > > > > > > > > > > > > > > > > > > > The DOTS server can return the error response code > > > > > > > > > > > 3.00 in > > > > > > response > > > > > > > > > > > to a PUT request from the DOTS client or convey th= e > > > > > > > > > > > error > > > > > > response > > > > > > > > > > > code 3.00 in a unidirectional notification respons= e > > > > > > > > > > > from the > > > > > > DOTS > > > > > > > > > > > server. > > > > > > > > > > > > > > > > > > > > > > Why is this limited to a PUT request and/or > > > > > > > > > > > unidirectional notification > > > > > > > > > > response? > > > > > > > > > > > - Surely, any response, unsolicited or otherwise can > > > > > > > > > > > contain a > > > > > > > > > > > 3.00 > > > > > > > > > > > - If Observe is not in use, then any unsolicited > > > > > > > > > > > notification response will potentially get rejected b= y > > > > > > > > > > > the coap library layer, so a DOTS Server cannot > > > > > > > > > > signal > > > > > > > > > > > maintenance outage other than by closing the session. > > > > > > > > > > > - I missed this the last review - sorry > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > #2 > > > > > > > > > > > > > > > > > > > > > > If the DOTS client has been redirected to a DOTS > > > > > > > > > > > server to > > > > > which > > > > > > it > > > > > > > > > > > has already sent the mitigation request within the > > > > > > > > > > > last five > > > > > (5) > > > > > > > > > > > minutes, it MUST ignore the redirection and try to > > > > > > > > > > > contact other DOTS > > > > > > > > > > > > > > > > > > > > > > s/ has already sent the mitigation request/ has > > > > > > > > > > > already communicated with/ > > > > > > > > > > > > > > > > > > > > > > #3 > > > > > > > > > > > > > > > > > > > > > > A DOTS client MUST NOT use an alternate IP > > > > > > > > > > > address to > > > > > contact > > > > > > its > > > > > > > > > > > DOTS server upon expiry of the associated TTL. > > > > > > > > > > > > > > > > > > > > > > To remove ambiguity over the use of FQDN, this could > > > > > > > > > > > read > > > > > > > > > > > > > > > > > > > > > > A DOTS client MUST NOT use an alternate IP > > > > > > > > > > > address to > > > > > contact > > > > > > its > > > > > > > > > > > DOTS server upon expiry of the associated TTL. > > > > > > > > > > > Furthermore, a > > > > > > > > DOTS > > > > > > > > > > > Client MUST NOT use the alt-server FQDN if all > > > > > > > > > > > of the > > > > > > > > > > > alt-server- > > > > > > > > > > records > > > > > > > > > > > have expired. > > > > > > > > > > > > > > > > > > > > > > Or alternatively > > > > > > > > > > > > > > > > > > > > > > alt-server: FQDN of an alternate DOTS server. > > > > > > > > > > > > > > > > > > > > > > This could read > > > > > > > > > > > > > > > > > > > > > > alt-server: FQDN of an alternate DOTS server. > > > > > > > > > > > This FQDN is not to be > > > > > > > > > > used for > > > > > > > > > > > looking up IP addresses to use, but is there for the > > > > > > > > > > > SNI extension > > > > > > > > (7.1. > > > > > > > > > > (D)TLS > > > > > > > > > > > Protocol Profile) > > > > > > > > > > > > > > > > > > > > I don't think the above restriction is correct for the > > > > > > > > > > following > > > > > > reasons: > > > > > > > > > > > > > > > > > > > > 1) If the TTL value in the alt-server-record expires, > > > > > > > > > > DNS lookup can be performed by the DOTS client using th= e > > > > > > > > > > alternate DOTS > > > > > server > > > > > > FQDN. > > > > > > > > > > 2) If the DNS server is reachable, the client may want > > > > > > > > > > to a DANE lookup to get the IP addresses and certificat= e > > > > > > > > > > to validate the alternate DOTS server certificate sent > > > > > > > > > > in the DTLS handshake. > > > > > > > > > > > > > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > > > > > Jon > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf > > > > > > > > > > > Of mohamed.boucadair@orange.com > > > > > > > > > > > Sent: 05 April 2018 08:20 > > > > > > > > > > > To: Konda, Tirumaleswar Reddy; Jon Shallow; > > > > > > > > > > > dots@ietf.org > > > > > > > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected > > > > > > > > > > > Signaling > > > > > > > > > > > > > > > > > > > > > > Hi Tiru, > > > > > > > > > > > > > > > > > > > > > > Works for me. > > > > > > > > > > > > > > > > > > > > > > I updated the draft with the text additions that were > > > > > > > > > > > discussed in this thread. The changes can be found at= : > > > > > > > > > > > https://github.com/boucadair/draft-ietf-dots-signal- > > > > > > > > > > channel/blob/master/draf > > > > > > > > > > > t-ietf-dots-signal-channel.txt > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > Med > > > > > > > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Konda, Tirumales= war > > > > > > > > > > > > Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > > > > > > > Envoy=E9=A0: mercredi 4 avril 2018 17:40 =C0=A0: Jo= n > > > > > > > > > > > > Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org > > Objet=A0: RE: > > > > > > > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > > > The TTL value returned under alt-server-record is > > > > > > > > > > > > equivalent to the DNS TTL value. A DDoS mitigation > > > > > > > > > > > > provider with multiple DOTS servers typically > > > > > > > > > > > > re-directs a DOTS client to a different DOTS server > > > > > > > > > > > > only if the alternate DOTS server has the capacity > > > > > > > > > > > > to handle the requests from the > > > > > > > > > > > DOTS client. > > > > > > > > > > > > > > > > > > > > > > > > We can add the following lines to avoid loops : > > > > > > > > > > > > > > > > > > > > > > > > If the DOTS client has been redirected to a DOTS > > > > > > > > > > > > server to which it has already sent the mitigation > > > > > > > > > > > > request within the last five minutes, it MUST ignor= e > > > > > > > > > > > > the redirection and try reaching others servers > > > > > > > > > > > > listed in the local configuration or discovered > > > > > > > > > > > > using dynamic means > > > > such as DHCP or SRV procedures. > > > > > > > > > > > > This prevents infinite ping-ponging between servers > > > > > > > > > > > > in case of redirection loops. > > > > > > > > > > > > > > > > > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > From: Dots [mailto:dots-bounces@ietf.org] On > > > > > > > > > > > > > Behalf Of Jon Shallow > > > > > > > > > > > > > Sent: Wednesday, April 4, 2018 8:16 PM > > > > > > > > > > > > > To: mohamed.boucadair@orange.com; dots@ietf.org > > > > > > > > > > > > > Subject: Re: [Dots] Signal Channel - 300 > > > > > > > > > > > > > Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > Hi there, > > > > > > > > > > > > > > > > > > > > > > > > > > See inline [Jon] > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > From: Dots [mailto: dots-bounces@ietf.org] On > > > > > > > > > > > > > Behalf Of mohamed.boucadair@orange.com > > > > > > > > > > > > > Sent: 04 April 2018 15:07 > > > > > > > > > > > > > To: Jon Shallow; dots@ietf.org > > > > > > > > > > > > > Subject: Re: [Dots] Signal Channel - 300 > > > > > > > > > > > > > Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > Re-, > > > > > > > > > > > > > > > > > > > > > > > > > > Please see inline. > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > Med > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Dots > > > > > > > > > > > > > > [mailto:dots-bounces@ietf.org] De la part de Jo= n > > > > > > > > > > > > > > Shallow Envoy=E9=A0: mercredi 4 avril 2018 15:3= 1 =C0=A0: > > > > > > > > > > > > > > dots@ietf.org > > > > > > > > Objet=A0: > > > > > > > > > > > > > > [Dots] Signal Channel - 300 Redirected Signalin= g > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi there, > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have implemented the 300 Redirected-Signal in > > > > > > > > > > > > > > my DOTS > > > > > code. > > > > > > > > > > > > > > This then raises some questions about usability= . > > > > > > > > > > > > > > > > > > > > > > > > > > > > Usability #1 > > > > > > > > > > > > > > > > > > > > > > > > > > > > Architecture 3.2.2 Redirected Signalling > > > > > > > > > > > > > > > > > > > > > > > > > > > > 4. Having redirected the DOTS client, DOTS > > > > > > > > > > > > > > server A ceases > > > > > > > > > > sending > > > > > > > > > > > > > > server signals. The DOTS client likewis= e > > > > > > > > > > > > > > stops sending > > > > > > > > client > > > > > > > > > > > > > > signals to DOTS server A. DOTS session = 1 > > > > > > > > > > > > > > is > > > > > > terminated. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Clearly indicates that the original session > > > > > > > > > > > > > > (Client to Server > > > > > > > > > > > > > > A) is no more once redirected and only Client t= o > > > > > > > > > > > > > > Server B is in > > > > > > > > use. > > > > > > > > > > > > > > > > > > > > > > > > > > > > How is the traffic redirected back to Server A > > > > > > > > > > > > > > once maintenance / overloading etc. has finishe= d? > > > > > > > > > > > > > > My assumption is that Server B sends a redirect > > > > > > > > > > > > > > to go back to Server A as Server A has no way t= o > > > > > > > > > > > > > > say over a now non-existent session to say > > > > > > > > > "come back". > > > > > > > > > > > > > > > > > > > > > > > > > > [Med] That's one possibility. This one does not > > > > > > > > > > > > > require any update to the > > > > > > > > > > > > signal- > > > > > > > > > > > > > channel specification. > > > > > > > > > > > > > > > > > > > > > > > > > > Another approach would be to not require any > > > > > > > > > > > > > redirect signal from server > > > > > > > > > > > B. > > > > > > > > > > > > > The client will remove server B's records upon th= e > > > > > > > > > > > > > expiry of the TTL and > > > > > > > > > > > > will fall > > > > > > > > > > > > > back to the "base" DOTS servers configuration tha= t > > > > > > > > > > > > > was provisioned to the > > > > > > > > > > > > client > > > > > > > > > > > > > using DHCP or whatever mechanism. > > > > > > > > > > > > > [Jon] OK. The TTL is defined at, associated wit= h > > > > > > > > > > > > > the IP address level > > > > > > > > > > > > under alt- > > > > > > > > > > > > > server-record, not under > > > > > > > > > > > > > ietf-dots-signal-channel:redirected-signal. The= ttl > > > > > > definition is > > > > > > > > > > > > > ambiguous as to what it refers to and perhaps > > > > > > > > > > > > > could be tightened up in the language (I read it > > > > > > > > > > > > > as being associated with "addr" in the sense of a > > > > > > > > > > > > > DNS > > > > > > > > > > > > TTL). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Do we need to keep the existing Client to Serve= r > > > > > > > > > > > > > > A session warm (or perhaps to probe > > > > > > > > > > > > > > periodically) to see if Server A is capable of > > > > > > > > > > > > > > handling the Client again by a server response > > > > > > > > > > > > > > extension to the protocol (e.g. a 3.01) > > > > > > > > > > > > > > > > > > > > > > > > > > [Med] Redirect was initially introduced to manage > > > > > > > > > > > > > a server overload, so I > > > > > > > > > > > > don't > > > > > > > > > > > > > think it makes sense to probe or maintain a > > > > > > > > > > > > > session with > > > > > server > > > > > > A. > > > > > > > > > > > > > [Jon] Agreed, but I needed to raise the question. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Should there be a retry period parameter added > > > > > > > > > > > > > > in to the > > > > > > > > > > > > > > 3.00 protocol (as I read it, ttl only refers to > > > > > > > > > > > > > > the IP > > > > > > address)? > > > > > > > > > > > > > > > > > > > > > > > > > > [Med] The client will automatically switch to > > > > > > > > > > > > > Server A when all alternate > > > > > > > > > > > > records > > > > > > > > > > > > > expire. > > > > > > > > > > > > > [Jon] OK - again the 4.6 text needs to get > > > > > > > > > > > > > tightened up to reflect this as > > > > > > > > > > > > the > > > > > > > > > > > > > intent. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Usability #2 > > > > > > > > > > > > > > > > > > > > > > > > > > > > Server A says "Redirect to Server B" due to > > > overloading. > > > > > > > > > > > > > > Server B accepts things for a while and then is > > > > > > > > > > > > > > instructed/decides to redirect traffic back to = A. > > > > > > > > > > > > > > Server A is left still overload configured to > > > > > > > > > > > > > > redirect to B. How should the client handle > > > > > > > > > > > > > > this as there is no suitable > > > > > > > > > > > > > Server? > > > > > > > > > > > > > > > > > > > > > > > > > > [Med] This is a service configuration problem. We > > > > > > > > > > > > > may > > > ask: > > > > > > > > > > > > > * the client to log the error and notify the > > > > administrator. > > > > > > > > > > > > > * and/or stop the redirection after n cycles. > > > > > > > > > > > > > > > > > > > > > > > > > > Still, this does not solve the problem. > > > > > > > > > > > > > [Jon] Agreed there is a problem here > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I agree that there needs to be co-ordination > > > > > > > > > > > > > > between Server A and Server B, but user error > > > > > > > > > > > > > > may > > > creep in. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Usability #3 > > > > > > > > > > > > > > > > > > > > > > > > > > > > Server A says "Redirect to Server B" as it goin= g > > > > > > > > > > > > > > to be shut down because of maintenance. Server > > > > > > > > > > > > > > B accepts things for a while and then is > > > > > > > > > > > > > > instructed (in probable user > > > > > > > > > > > > > > error) to redirect traffic back to A (perhaps > > > > > > > > > > > > > > because it has hit an overload condition). How > > > > > > > > > > > > > > should the client > > > > > > > > > > > > > handle this? > > > > > > > > > > > > > > > > > > > > > > > > > > [Med] Isn't this a sub-case or #2? > > > > > > > > > > > > > [Jon] Yes, but I wanted to bring in Server A bein= g > > > > > > > > > > > > > alive and able to > > > > > > > > > > > > respond > > > > > > > > > > > > > versus Server A down and not responding due to > > > > maintenance. > > > > > > > > > > > > > [Jon] With my better understanding of TTL we stil= l > > > > > > > > > > > > > have an issue if the TTL expires and Server A is > > > > > > > > > > > > > having an extended > > > > > > outage. > > > > > > > > > > > > > How do we recover from that? > > > > > > > > > > > > > ~jon > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > Dots mailing list Dots@ietf.org > > > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > Dots mailing list > > > > > > > > > > > > > Dots@ietf.org > > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > Dots mailing list > > > > > > > > > > > > > Dots@ietf.org > > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > Dots mailing list > > > > > > > > > > > Dots@ietf.org > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > Dots mailing list > > > > > > > > > Dots@ietf.org > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > _______________________________________________ > > > > > > Dots mailing list > > > > > > Dots@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > _______________________________________________ > > > > > Dots mailing list > > > > > Dots@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots From nobody Mon Apr 9 01:24:05 2018 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 80444127076 for ; Mon, 9 Apr 2018 01:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 p-kc9aNgOm_t for ; Mon, 9 Apr 2018 01:24:00 -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 93D891242F7 for ; Mon, 9 Apr 2018 01:23:59 -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=1523262238; 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: dlp-product:dlp-version:dlp-reaction: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-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-Network-Message-Id: 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=X CvUVKw+1mRnf3XhqmXFMyUgzHnQHuqt6GbiRfOaPh g=; b=f9lzB29YZFUtJq5No5WaL9HsgTMeaE95jwaaR9S1fIrk 2LnAG3J7K/ca8G2i/Jp0q5FIr2jqs/YrC3tOEz+k13lOtMDnVE aLw4PGbUQWkJ8dGDgBfY/HpzsKQajQyMMwaoAamC9DRFRwPaLi 8ZE+p/GBrEnBVQvmXaOobL/RG30= Received: from DNVEXAPP1N04.corpzone.internalzone.com (DNVEXAPP1N04.corpzone.internalzone.com [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 16d2_54b4_a4e4faaf_7174_4f4d_8ce0_233521015d81; Mon, 09 Apr 2018 03:23:58 -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; Mon, 9 Apr 2018 02:22:37 -0600 Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXUSR1N12.corpzone.internalzone.com (10.44.48.85) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 9 Apr 2018 02:22:36 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Mon, 9 Apr 2018 02:22:35 -0600 Received: from NAM02-BL2-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.1347.2; Mon, 9 Apr 2018 02:22:34 -0600 Received: from BN6PR16MB1425.namprd16.prod.outlook.com (10.172.207.19) by BN6PR16MB1809.namprd16.prod.outlook.com (10.172.28.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.653.12; Mon, 9 Apr 2018 08:22:34 +0000 Received: from BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d]) by BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d%2]) with mapi id 15.20.0653.015; Mon, 9 Apr 2018 08:22:34 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Signal Channel - 300 Redirected Signaling Thread-Index: AdPMGSyCaQQbv+vLSW+0gkDbU7HOEwAAo7xAAAH7T4AAARdqYAAhoxEAAAGQiwAAAKyNYAAF3e1QACUKCFAAAZEMQAAIeXTgAARcGhAAAoG7gAABGXwAAAAjBIAAAa5ZgAAAiReAAABpmzAAL32aAABWbPEwAAIv/gAAAPiKMA== Date: Mon, 9 Apr 2018 08:22:33 +0000 Message-ID: References: <014f01d3cc19$2e3880e0$8aa982a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7E7B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <019901d3cc23$a93ff8e0$fbbfeaa0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8524@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <004e01d3ccb4$d505e7f0$7f11b7d0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8758@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEF912A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEF93EE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <008501d3cda6$c860d210$59227630$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF951 1@OPEXCLILMA3 . corporate.adroot.infra.ftgroup> <00b001d3cdab$ba8caec0$2fa60c40$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF975C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <00b801d3cdb4$982dc4a0$c8894de0$@jpshallow.com> <015101d3ce74$351393c0$9f3abb40$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEFA190@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DEFA190@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR16MB1809; 7:hfMD3BiHXCWbg08taal4sZYxeJKhbR3peXYcuo7LZFj01MQYjgEIsq9VgS05oq1Pct3LcYkUe08HynSkxHFf8bFE6i9rlFZOxDTuC9nJOYU2JAWvFK6tBHS0CJd1PSSQwvL9jPfifCg+gf1SG0cLHq/mP+PpuwjHn1wT5fvdlNHNEbMZVwzy+jSDtGIEgAPCJ2zUgR38ctLvRyZsTMeyspZQy/JiJ12T5nYZ/6fvcX6UbY+EfLr8EKLsj+9e5u4b x-ms-exchange-antispam-srfa-diagnostics: SOS; X-MS-Office365-Filtering-Correlation-Id: 4c25aebe-203e-48d2-e009-08d59df30ba0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BN6PR16MB1809; x-ms-traffictypediagnostic: BN6PR16MB1809: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(166708455590820)(788757137089)(18271650672692)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231221)(944501327)(52105095)(3002001)(10201501046)(93006095)(93001095)(6041310)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(6072148)(201708071742011); SRVR:BN6PR16MB1809; BCL:0; PCL:0; RULEID:; SRVR:BN6PR16MB1809; x-forefront-prvs: 0637FCE711 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(366004)(396003)(39380400002)(39860400002)(55784002)(57704003)(32952001)(199004)(13464003)(189003)(53546011)(305945005)(81156014)(80792005)(6306002)(9686003)(8676002)(68736007)(86362001)(6436002)(3280700002)(76176011)(55016002)(6246003)(53936002)(53946003)(16200700003)(5660300001)(229853002)(446003)(102836004)(11346002)(81166006)(186003)(93886005)(486006)(5250100002)(74316002)(7736002)(97736004)(476003)(106356001)(26005)(99286004)(110136005)(2906002)(2900100001)(6116002)(8936002)(14454004)(25786009)(33656002)(3660700001)(6506007)(478600001)(2501003)(59450400001)(316002)(105586002)(72206003)(66066001)(7696005)(966005)(3846002)(85282002)(559001)(579004)(569006); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR16MB1809; H:BN6PR16MB1425.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: m+6WFctHd1mpiwGagBLC6IWWzly2ioPZNi2m9Y0bgZOmbyc+YWUB3p788titya8StXsYzv0hBHYtU9JHZHwp9jisYdz5wqu0jwk3K9mL3/hFmQOT40kJ80GuUnRAtW5k0S1dfZ74OBT/+qmPqb++HvyvTFX436Ub9Xva8uhtqHo/9MlrlIUDT24subkZ1SQEmFtCeJd5QhUhcBuSSJDEuhlVEwUfXAaHl4EMAiAMVI9DcvbMCf/g4FOUWI1DaBc2btSR3ADVpEf9v4GF5N/qoSuuS8SSwp66FKnG1w8H0geJh+FrtNpS3fbxVBN39CUcqfNPtjv8aQFfNHObz+Akr1IWTbhPLY4wyNiGvsHyN/g1PB39aKjhFjz8abp/byu+KlQIfYLZnzg58VLRcLCzoGS22zonyKbTXbPlHMAQZYw= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 4c25aebe-203e-48d2-e009-08d59df30ba0 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2018 08:22:33.9898 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR16MB1809 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 <6259> : inlines <6554> : streams <1783535> : uri <2622400> Archived-At: Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling 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, 09 Apr 2018 08:24:03 -0000 > -----Original Message----- > From: mohamed.boucadair@orange.com > [mailto:mohamed.boucadair@orange.com] > Sent: Monday, April 9, 2018 1:15 PM > To: Konda, Tirumaleswar Reddy ; > Jon Shallow ; dots@ietf.org > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling >=20 > Tiru, >=20 > What about this update ones? >=20 > =3D=3D=3D=3D=3D=3D=3D > ttl: Time to live (TTL) of the alternate DOTS server, represented as > an integer number of seconds. That is, the time interval that the > alternate DOTS server may be cached for use by a DOTS client. >=20 > A lifetime of negative one (-1) indicates indefinite TTL. This > value means that the alternate DOTS server is to be used until the > alternate DOTS server redirects the traffic with another 3.00 > response. >=20 > If no 'ttl' is returned in a redirect response, this is equivalent > to returning a 'ttl' parameter set to '-1'. Above text looks good. >=20 > If the alternate DOTS server TTL has expired, the DOTS client MUST > use the DOTS server(s), that was provisioned using means discussed > in Section 4.1, for creating new requests. It looks too restrictive, typically the DNS TTL values are short-lived (e.g= . few seconds) but the sessions are long-lived.=20 Why not replace "for creating new requests" with "for creating new DOTS ses= sion" ? --Tiru >=20 > This is an optional attribute. > =3D=3D=3D >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Konda, Tirumaleswar Reddy > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > Envoy=E9=A0: lundi 9 avril 2018 08:51 > > =C0=A0: Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet=A0:= RE: > > [Dots] Signal Channel - 300 Redirected Signaling > > > > Hi Jon, > > > > I partially agree with the suggested update. A IP address is cached > > until the TTL value expires, the DOTS client need not disconnect > > existing sessions after the TTL expires, but after the TTL expires it > > must consider the IP address stale and not establish new (D)TLS > > sessions. > > > > Cheers, > > -Tiru > > > > > -----Original Message----- > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow > > > Sent: Saturday, April 7, 2018 6:58 PM > > > To: Konda, Tirumaleswar Reddy ; > > > mohamed.boucadair@orange.com; dots@ietf.org > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > Hi there, > > > > > > My suggestion would be to make ttl of -1 'infinite', otherwise have > > > a > > minimum > > > value of 300 seconds. The text could read (including referring to > > > the > > optional > > > etc. to be consistent with the rest of the document:- > > > > > > alt-server: FQDN of an alternate DOTS server. > > > > > > This is a required attribute. > > > > > > alt-server-record: A list of IP addresses of an alternate DOTS > > > server. > > > > > > This is an optional attribute. > > > > > > ttl: Time to live (TTL) of the alternate DOTS server, represented= as > > > an integer number of seconds. That is, the time interval that = the > > > alternate DOTS server may be used by a DOTS client. > > > > > > The minimum value is '300' seconds, or '-1'. > > > > > > '-1' means that the alternate DOTS server is to be used until > > > the > > alternate > > > DOTS server redirects the traffic with another 3.00 response. > > > There is no TTL expiry. > > > > > > If no 'ttl' is returned in a redirect response, this is equival= ent > > > to returning a 'ttl' parameter set to '-1'. > > > > > > If the alternate DOTS server TTL has expired, the DOTS client M= UST > > > use the DOTS server(s) that was provisioned using means discuss= ed > > > in Section 4.1. > > > > > > This is an optional attribute. > > > > > > > > > > > > Regards > > > > > > Jon > > > > > > -----Original Message----- > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, > > > Tirumaleswar Reddy > > > Sent: 06 April 2018 15:55 > > > To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > The below proposed change does not look good to me, its causing the > > > DOTS client to ping-pong between multiple DOTS servers because of the= TTL > value. > > > The alternate server should serve the DOTS client till there is a > > > planned maintenance, if it is getting over-subscribed it should > > > re-direct the new > > DOTS > > > clients to an alternate server and avoid bouncing the existing DOTS > > > clients > > which > > > have been sending mitigation requests to it. > > > > > > -Tiru > > > > > > > -----Original Message----- > > > > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > Sent: Friday, April 6, 2018 8:06 PM > > > > To: mohamed.boucadair@orange.com; Konda, Tirumaleswar Reddy > > > > ; dots@ietf.org > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > Hi Med, > > > > > > > > Thanks for this. I would like to see the ttl: definition > > > > tightened up (moved away from the DNS TTL version) > > > > > > > > Old > > > > > > > > ttl: Time to live (TTL) of alternate records, represented as an > > > > integer number of seconds. That is, the time interval that > > > > alternate IP addresses may be cached by a DOTS client. > > > > > > > > '0' means that an alternate IP address is only to be used for= the > > > > request in progress, and consequently that IP address should = not > > > > be cached. > > > > > > > > If no 'ttl' is returned in a redirect response, this is equiv= alent > > > > to returning a 'ttl' parameter set to '0'. > > > > > > > > If 'alt-server-record' has expired, the DOTS client MUST use = the > > > > DOTS server(s) that was provisioned using means discussed in > > > > Section 4.1. Furthermore, a DOTS client MUST NOT use the alt= - > > > > server FQDN if the 'alt-server-records' has expired. > > > > > > > > New > > > > > > > > ttl: Time to live (TTL) of the alternate DOTS server, > > > > represented as > > > an > > > > integer number of seconds. That is, the time interval that > > > > the alternate DOTS server may be cached for use by a DOTS cli= ent. > > > > > > > > '0' means that the alternate DOTS server is only to be used f= or the > > > > request in progress, and consequently the alternate DOTS > > > > server entry should not > > > > be cached. > > > > > > > > If no 'ttl' is returned in a redirect response, this is equiv= alent > > > > to returning a 'ttl' parameter set to '0'. > > > > > > > > If the alternate DOTS server TTL has expired, the DOTS > > > > client MUST > > > use the > > > > DOTS server(s) that was provisioned using means discussed in > > > > Section 4.1. > > > > > > > > > > > > Regards > > > > > > > > Jon > > > > > > > > -----Original Message----- > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > > > mohamed.boucadair@orange.com > > > > Sent: 06 April 2018 15:21 > > > > To: Jon Shallow; Konda, Tirumaleswar Reddy; dots@ietf.org > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > FWIW, I implemented the change at: > > > > https://github.com/boucadair/draft-ietf-dots-signal-channel/blob/m > > > > aste > > > > r/draf > > > > t-ietf-dots-signal-channel.txt > > > > > > > > Cheers, > > > > Med > > > > > > > > > -----Message d'origine----- > > > > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > > Envoy=E9=A0: vendredi 6 avril 2018 15:33 =C0=A0: BOUCADAIR Mohame= d > > > > > IMT/OLN; Konda, Tirumaleswar Reddy; dots@ietf.org Objet=A0: RE: > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > Excellent. > > > > > > > > > > Thanks > > > > > > > > > > Jon > > > > > > > > > > -----Original Message----- > > > > > From: mohamed.boucadair@orange.com [mailto: > > > > > mohamed.boucadair@orange.com] > > > > > Sent: 06 April 2018 14:29 > > > > > To: Jon Shallow; Konda, Tirumaleswar Reddy; rdd@cert.org > > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > Hi Jon, all, > > > > > > > > > > I'm fine to put ttl at the level of alt-server. > > > > > > > > > > Cheers, > > > > > Med > > > > > > > > > > > -----Message d'origine----- > > > > > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > > > Envoy=E9=A0: vendredi 6 avril 2018 14:57 =C0=A0: BOUCADAIR Moha= med > > > > > > IMT/OLN; Konda, Tirumaleswar Reddy; rdd@cert.org Objet=A0: RE: > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > Hi there, > > > > > > > > > > > > See inline [Jon3] > > > > > > > > > > > > Regards > > > > > > > > > > > > Jon > > > > > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Konda, Tirumaleswar > > > > > > > > > Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > > > > Envoy=E9=A0: vendredi 6 avril 2018 07:07 =C0=A0: BOUCADAI= R > > > > > > > > > Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet=A0: RE: > > > > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > > > > Hi Med, > > > > > > > > > > > > > > > > > > The proposed update restricts the client no to do a DNS > > > > > > > > > lookup using the alternate FQDN, further associating a > > > > > > > > > TTL with the name complicates the functionality on the > > > > > > > > > DOTS client to re-establish (D)TLS session with the > > > > > > > > > primary DOTS server after the > > > > > TTL expires. > > > > > > > > > My suggestion is to let the DOTS client continue to use > > > > > > > > > the alternate DOTS > > > > > > > server > > > > > > > > till it gets re-directed. > > > > > > > > > > > > > > > > [Med] This is possible with the current spec. > > > > > > > > > > > > > > > > Triggers for redirect and for falling back to the nominal > > > > > > > > configuration are deployment-specific. The current spec > > > > > > > > allows for almost all the cases > > > > > > > discussed > > > > > > > > so far: > > > > > > > > > > > > > > > > (1) Redirect for the request in progress: A server does so > > > > > > > > by returning > > > > > > > TTL=3D0. > > > > > > > > (2) The alternate server is not involved in fall back to > > > > > > > > the nominal > > > > > > > server: upon > > > > > > > > expiry of ttl of all alternate IP addresses, then fall > > > > > > > > back automatically > > > > > > > to the > > > > > > > > nominal server. > > > > > > > > (3) Redirect to an alternate server, which in turn will > > > > > > > > instruct the client > > > > > > > to > > > > > > > > redirect to the "base" configuration: a TTL is provided > > > > > > > > and the alternate > > > > > > > server > > > > > > > > can reply with a redirect code any time before the expiry > > > > > > > > of the TTL. A > > > > > > > long TTL > > > > > > > > can be returned if the alternate server will be > > > > > > > > responsible for > > > > > > > coordinating fall > > > > > > > > back to the base server. > > > > > > > > (4) Stop infinite redirects > > > > > > > > > > > > > > Yes, but (1) and (2) complicate the functionality of the > > > > > > > DOTS > > > client. > > > > > > > > > > > > [Med] (1) and (2) is exactly the same functionality required > > > > > > for caching DNS replies. > > > > > > > > > > > > The > > > > > > > only reason for adding alt-server-record in the response is > > > > > > > DNS server may not be reachable by the DOTS server because > > > > > > > of a DDoS > > > > attack. > > > > > > > > > > > > > > > > > > > [Med] Yes. Note that even if the name resolution was allowed, > > > > > > the client has to deal with the TTL indicated in the > > > > > > response...which is exactly the same as (1) and (2). > > > > > > > > > > > > > > > > > > [Jon3] I think where I am struggling here is the overloaded > > > > > > use of TTL > > > > > > - The TTL as per a DNS record and held as a part of > > > > > > alt-server-record and then the TTL after which that the > > > > > > alt-server should be handling the traffic before handling back > > > > > > to the original primary server. It either has to be one or > > > > > > the other, or they have to > > > > have different names. > > > > > > [Jon3] If we are only going to go for one variant for > > > > > > simplicity, then I would prefer that it should be at the level = of "alt- > server". > > > > > > Handling the TTL for DNS refresh is normally handled by a > > > > > > resolver library, updated by the DNS packets coming in - > > > > > > unusual for an application > > > > > to have to do that. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I > > > > > > > > > don't think the DOTS mitigation provider will know > > > > > > > > > ahead-of-time the TTL value after which the DOTS client > > > > > > > > > should disconnect communicating with the alternate DOTS > > > > > > > > > server and re-establish (D)TLS session with the primary > > > > > > > > > DOTS > > > server. > > > > > > > > > > > > > > > > [Med] It depends on the nature of the redirect: overload, > > > > > > > > planned > > > > > > > maintenance, > > > > > > > > etc. For planned maintenance, the TTL is known in general. > > > > > > > > > > > > > > It's the primary DOTS server responsibility to point the > > > > > > > DOTS client to an optimal alternate server, where the client > > > > > > > can continue to send migration requests without a frequent > > > > > > > ping-pong > > > > between servers. > > > > > > > > > > > > [Med] Agree. This is a service configuration problem. > > > > > > [Jon3] Agreed - and the 5 minute minimum ping-pong time is a > > > > > > good safety net. > > > > > > ~jon3 > > > > > > > > > > > > > I have seen TURN servers being deployed for several years > > > > > > > with > > > > > > re-direction > > > > > > > but without the need for TTL (see ALTERNATE-SERVER in > > > > > > > https://tools.ietf.org/html/draft-ietf-tram-turnbis-11) > > > > > > > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of > > > > > > > > > > mohamed.boucadair@orange.com > > > > > > > > > > Sent: Thursday, April 5, 2018 4:50 PM > > > > > > > > > > To: Konda, Tirumaleswar Reddy > > > > > > > > > > ; > > > > > > > > > > Jon Shallow ; dots@ietf.org > > > > > > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected > > > > > > > > > > Signaling > > > > > > > > > > > > > > > > > > > > Tiru, > > > > > > > > > > > > > > > > > > > > I don't see the NEW text as a restriction but as a > > > > > > > > > > simplification of the > > > > > > > > > client's > > > > > > > > > > behavior. I don't want to over-specify the redirect beh= avior. > > > > > > > > > > > > > > > > > > > > Adding another yet layer of resolution will raise > > > > > > > > > > other issues such as the > > > > > > > > > need to > > > > > > > > > > associate a TTL with the name itself. > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > Med > > > > > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Konda, Tirumaleswa= r > > > > > > > > > > > Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > > > > > > Envoy=E9=A0: jeudi 5 avril 2018 12:06 =C0=A0: Jon Sha= llow; > > > > > > > > > > > BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet=A0: > > > > > > RE: > > > > > > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: Jon Shallow > > > > > > > > > > > > [mailto:supjps-ietf@jpshallow.com] > > > > > > > > > > > > Sent: Thursday, April 5, 2018 1:35 PM > > > > > > > > > > > > To: mohamed.boucadair@orange.com; Konda, > > > > > > > > > > > > Tirumaleswar Reddy > > > > > > > > > > > > ; > > > > > > > > > > > > dots@ietf.org > > > > > > > > > > > > Subject: RE: [Dots] Signal Channel - 300 > > > > > > > > > > > > Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > > > Hi Med, > > > > > > > > > > > > > > > > > > > > > > > > Thanks for this refresh to 4.6 Redirected > > > > > > > > > > > > Signaling > > > > > > > > > > > > > > > > > > > > > > > > Some comments > > > > > > > > > > > > > > > > > > > > > > > > #1 > > > > > > > > > > > > > > > > > > > > > > > > The DOTS server can return the error response > > > > > > > > > > > > code > > > > > > > > > > > > 3.00 in > > > > > > > response > > > > > > > > > > > > to a PUT request from the DOTS client or convey > > > > > > > > > > > > the error > > > > > > > response > > > > > > > > > > > > code 3.00 in a unidirectional notification > > > > > > > > > > > > response from the > > > > > > > DOTS > > > > > > > > > > > > server. > > > > > > > > > > > > > > > > > > > > > > > > Why is this limited to a PUT request and/or > > > > > > > > > > > > unidirectional notification > > > > > > > > > > > response? > > > > > > > > > > > > - Surely, any response, unsolicited or otherwise > > > > > > > > > > > > can contain a > > > > > > > > > > > > 3.00 > > > > > > > > > > > > - If Observe is not in use, then any unsolicited > > > > > > > > > > > > notification response will potentially get > > > > > > > > > > > > rejected by the coap library layer, so a DOTS > > > > > > > > > > > > Server cannot > > > > > > > > > > > signal > > > > > > > > > > > > maintenance outage other than by closing the sessio= n. > > > > > > > > > > > > - I missed this the last review - sorry > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > #2 > > > > > > > > > > > > > > > > > > > > > > > > If the DOTS client has been redirected to a > > > > > > > > > > > > DOTS server to > > > > > > which > > > > > > > it > > > > > > > > > > > > has already sent the mitigation request within > > > > > > > > > > > > the last five > > > > > > (5) > > > > > > > > > > > > minutes, it MUST ignore the redirection and try > > > > > > > > > > > > to contact other DOTS > > > > > > > > > > > > > > > > > > > > > > > > s/ has already sent the mitigation request/ has > > > > > > > > > > > > already communicated with/ > > > > > > > > > > > > > > > > > > > > > > > > #3 > > > > > > > > > > > > > > > > > > > > > > > > A DOTS client MUST NOT use an alternate IP > > > > > > > > > > > > address to > > > > > > contact > > > > > > > its > > > > > > > > > > > > DOTS server upon expiry of the associated TTL= . > > > > > > > > > > > > > > > > > > > > > > > > To remove ambiguity over the use of FQDN, this > > > > > > > > > > > > could read > > > > > > > > > > > > > > > > > > > > > > > > A DOTS client MUST NOT use an alternate IP > > > > > > > > > > > > address to > > > > > > contact > > > > > > > its > > > > > > > > > > > > DOTS server upon expiry of the associated TTL= . > > > > > > > > > > > > Furthermore, a > > > > > > > > > DOTS > > > > > > > > > > > > Client MUST NOT use the alt-server FQDN if > > > > > > > > > > > > all of the > > > > > > > > > > > > alt-server- > > > > > > > > > > > records > > > > > > > > > > > > have expired. > > > > > > > > > > > > > > > > > > > > > > > > Or alternatively > > > > > > > > > > > > > > > > > > > > > > > > alt-server: FQDN of an alternate DOTS server. > > > > > > > > > > > > > > > > > > > > > > > > This could read > > > > > > > > > > > > > > > > > > > > > > > > alt-server: FQDN of an alternate DOTS server. > > > > > > > > > > > > This FQDN is not to be > > > > > > > > > > > used for > > > > > > > > > > > > looking up IP addresses to use, but is there for > > > > > > > > > > > > the SNI extension > > > > > > > > > (7.1. > > > > > > > > > > > (D)TLS > > > > > > > > > > > > Protocol Profile) > > > > > > > > > > > > > > > > > > > > > > I don't think the above restriction is correct for > > > > > > > > > > > the following > > > > > > > reasons: > > > > > > > > > > > > > > > > > > > > > > 1) If the TTL value in the alt-server-record > > > > > > > > > > > expires, DNS lookup can be performed by the DOTS > > > > > > > > > > > client using the alternate DOTS > > > > > > server > > > > > > > FQDN. > > > > > > > > > > > 2) If the DNS server is reachable, the client may > > > > > > > > > > > want to a DANE lookup to get the IP addresses and > > > > > > > > > > > certificate to validate the alternate DOTS server cer= tificate > sent > > > > > > > > > > > in the DTLS handshake. > > > > > > > > > > > > > > > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > > > > > > > Jon > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: Dots [mailto: dots-bounces@ietf.org] On > > > > > > > > > > > > Behalf Of mohamed.boucadair@orange.com > > > > > > > > > > > > Sent: 05 April 2018 08:20 > > > > > > > > > > > > To: Konda, Tirumaleswar Reddy; Jon Shallow; > > > > > > > > > > > > dots@ietf.org > > > > > > > > > > > > Subject: Re: [Dots] Signal Channel - 300 > > > > > > > > > > > > Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > > > Hi Tiru, > > > > > > > > > > > > > > > > > > > > > > > > Works for me. > > > > > > > > > > > > > > > > > > > > > > > > I updated the draft with the text additions that > > > > > > > > > > > > were discussed in this thread. The changes can be f= ound at: > > > > > > > > > > > > https://github.com/boucadair/draft-ietf-dots-signa > > > > > > > > > > > > l- > > > > > > > > > > > channel/blob/master/draf > > > > > > > > > > > > t-ietf-dots-signal-channel.txt > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > Med > > > > > > > > > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Konda, > > > > > > > > > > > > > Tirumaleswar Reddy > > > > > > > > > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > > > > > > > > Envoy=E9=A0: mercredi 4 avril 2018 17:40 =C0=A0: = Jon > > > > > > > > > > > > > Shallow; BOUCADAIR Mohamed IMT/OLN; > > > > > > > > > > > > > dots@ietf.org > > > Objet=A0: RE: > > > > > > > > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > The TTL value returned under alt-server-record > > > > > > > > > > > > > is equivalent to the DNS TTL value. A DDoS > > > > > > > > > > > > > mitigation provider with multiple DOTS servers > > > > > > > > > > > > > typically re-directs a DOTS client to a > > > > > > > > > > > > > different DOTS server only if the alternate DOTS > > > > > > > > > > > > > server has the capacity to handle the requests > > > > > > > > > > > > > from the > > > > > > > > > > > > DOTS client. > > > > > > > > > > > > > > > > > > > > > > > > > > We can add the following lines to avoid loops : > > > > > > > > > > > > > > > > > > > > > > > > > > If the DOTS client has been redirected to a DOTS > > > > > > > > > > > > > server to which it has already sent the > > > > > > > > > > > > > mitigation request within the last five minutes, > > > > > > > > > > > > > it MUST ignore the redirection and try reaching > > > > > > > > > > > > > others servers listed in the local configuration > > > > > > > > > > > > > or discovered using dynamic means > > > > > such as DHCP or SRV procedures. > > > > > > > > > > > > > This prevents infinite ping-ponging between > > > > > > > > > > > > > servers in case of redirection loops. > > > > > > > > > > > > > > > > > > > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > From: Dots [mailto:dots-bounces@ietf.org] On > > > > > > > > > > > > > > Behalf Of Jon Shallow > > > > > > > > > > > > > > Sent: Wednesday, April 4, 2018 8:16 PM > > > > > > > > > > > > > > To: mohamed.boucadair@orange.com; > > > > > > > > > > > > > > dots@ietf.org > > > > > > > > > > > > > > Subject: Re: [Dots] Signal Channel - 300 > > > > > > > > > > > > > > Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi there, > > > > > > > > > > > > > > > > > > > > > > > > > > > > See inline [Jon] > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > From: Dots [mailto: dots-bounces@ietf.org] On > > > > > > > > > > > > > > Behalf Of mohamed.boucadair@orange.com > > > > > > > > > > > > > > Sent: 04 April 2018 15:07 > > > > > > > > > > > > > > To: Jon Shallow; dots@ietf.org > > > > > > > > > > > > > > Subject: Re: [Dots] Signal Channel - 300 > > > > > > > > > > > > > > Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > > > Re-, > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please see inline. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > Med > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Dots > > > > > > > > > > > > > > > [mailto:dots-bounces@ietf.org] De la part de > > > > > > > > > > > > > > > Jon Shallow Envoy=E9=A0: mercredi 4 avril 201= 8 15:31 =C0=A0: > > > > > > > > > > > > > > > dots@ietf.org > > > > > > > > > Objet=A0: > > > > > > > > > > > > > > > [Dots] Signal Channel - 300 Redirected > > > > > > > > > > > > > > > Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi there, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have implemented the 300 Redirected-Signal > > > > > > > > > > > > > > > in my DOTS > > > > > > code. > > > > > > > > > > > > > > > This then raises some questions about usabili= ty. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Usability #1 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Architecture 3.2.2 Redirected Signalling > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 4. Having redirected the DOTS client, > > > > > > > > > > > > > > > DOTS server A ceases > > > > > > > > > > > sending > > > > > > > > > > > > > > > server signals. The DOTS client > > > > > > > > > > > > > > > likewise stops sending > > > > > > > > > client > > > > > > > > > > > > > > > signals to DOTS server A. DOTS > > > > > > > > > > > > > > > session 1 is > > > > > > > terminated. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Clearly indicates that the original session > > > > > > > > > > > > > > > (Client to Server > > > > > > > > > > > > > > > A) is no more once redirected and only > > > > > > > > > > > > > > > Client to Server B is in > > > > > > > > > use. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > How is the traffic redirected back to Server > > > > > > > > > > > > > > > A once maintenance / overloading etc. has fin= ished? > > > > > > > > > > > > > > > My assumption is that Server B sends a > > > > > > > > > > > > > > > redirect to go back to Server A as Server A > > > > > > > > > > > > > > > has no way to say over a now non-existent > > > > > > > > > > > > > > > session to say > > > > > > > > > > "come back". > > > > > > > > > > > > > > > > > > > > > > > > > > > > [Med] That's one possibility. This one does > > > > > > > > > > > > > > not require any update to the > > > > > > > > > > > > > signal- > > > > > > > > > > > > > > channel specification. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Another approach would be to not require any > > > > > > > > > > > > > > redirect signal from server > > > > > > > > > > > > B. > > > > > > > > > > > > > > The client will remove server B's records upon > > > > > > > > > > > > > > the expiry of the TTL and > > > > > > > > > > > > > will fall > > > > > > > > > > > > > > back to the "base" DOTS servers configuration > > > > > > > > > > > > > > that was provisioned to the > > > > > > > > > > > > > client > > > > > > > > > > > > > > using DHCP or whatever mechanism. > > > > > > > > > > > > > > [Jon] OK. The TTL is defined at, associated > > > > > > > > > > > > > > with the IP address level > > > > > > > > > > > > > under alt- > > > > > > > > > > > > > > server-record, not under > > > > > > > > > > > > > > ietf-dots-signal-channel:redirected-signal. T= he ttl > > > > > > > definition is > > > > > > > > > > > > > > ambiguous as to what it refers to and perhaps > > > > > > > > > > > > > > could be tightened up in the language (I read > > > > > > > > > > > > > > it as being associated with "addr" in the > > > > > > > > > > > > > > sense of a DNS > > > > > > > > > > > > > TTL). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Do we need to keep the existing Client to > > > > > > > > > > > > > > > Server A session warm (or perhaps to probe > > > > > > > > > > > > > > > periodically) to see if Server A is capable > > > > > > > > > > > > > > > of handling the Client again by a server > > > > > > > > > > > > > > > response extension to the protocol (e.g. a > > > > > > > > > > > > > > > 3.01) > > > > > > > > > > > > > > > > > > > > > > > > > > > > [Med] Redirect was initially introduced to > > > > > > > > > > > > > > manage a server overload, so I > > > > > > > > > > > > > don't > > > > > > > > > > > > > > think it makes sense to probe or maintain a > > > > > > > > > > > > > > session with > > > > > > server > > > > > > > A. > > > > > > > > > > > > > > [Jon] Agreed, but I needed to raise the questio= n. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Should there be a retry period parameter > > > > > > > > > > > > > > > added in to the > > > > > > > > > > > > > > > 3.00 protocol (as I read it, ttl only refers > > > > > > > > > > > > > > > to the IP > > > > > > > address)? > > > > > > > > > > > > > > > > > > > > > > > > > > > > [Med] The client will automatically switch to > > > > > > > > > > > > > > Server A when all alternate > > > > > > > > > > > > > records > > > > > > > > > > > > > > expire. > > > > > > > > > > > > > > [Jon] OK - again the 4.6 text needs to get > > > > > > > > > > > > > > tightened up to reflect this as > > > > > > > > > > > > > the > > > > > > > > > > > > > > intent. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Usability #2 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Server A says "Redirect to Server B" due to > > > > overloading. > > > > > > > > > > > > > > > Server B accepts things for a while and then > > > > > > > > > > > > > > > is instructed/decides to redirect traffic bac= k to A. > > > > > > > > > > > > > > > Server A is left still overload configured > > > > > > > > > > > > > > > to redirect to B. How should the client > > > > > > > > > > > > > > > handle this as there is no suitable > > > > > > > > > > > > > > Server? > > > > > > > > > > > > > > > > > > > > > > > > > > > > [Med] This is a service configuration problem. > > > > > > > > > > > > > > We may > > > > ask: > > > > > > > > > > > > > > * the client to log the error and notify the > > > > > administrator. > > > > > > > > > > > > > > * and/or stop the redirection after n cycles. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Still, this does not solve the problem. > > > > > > > > > > > > > > [Jon] Agreed there is a problem here > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I agree that there needs to be co-ordination > > > > > > > > > > > > > > > between Server A and Server B, but user > > > > > > > > > > > > > > > error may > > > > creep in. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Usability #3 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Server A says "Redirect to Server B" as it > > > > > > > > > > > > > > > going to be shut down because of > > > > > > > > > > > > > > > maintenance. Server B accepts things for a > > > > > > > > > > > > > > > while and then is instructed (in probable > > > > > > > > > > > > > > > user > > > > > > > > > > > > > > > error) to redirect traffic back to A > > > > > > > > > > > > > > > (perhaps because it has hit an overload > > > > > > > > > > > > > > > condition). How should the client > > > > > > > > > > > > > > handle this? > > > > > > > > > > > > > > > > > > > > > > > > > > > > [Med] Isn't this a sub-case or #2? > > > > > > > > > > > > > > [Jon] Yes, but I wanted to bring in Server A > > > > > > > > > > > > > > being alive and able to > > > > > > > > > > > > > respond > > > > > > > > > > > > > > versus Server A down and not responding due to > > > > > maintenance. > > > > > > > > > > > > > > [Jon] With my better understanding of TTL we > > > > > > > > > > > > > > still have an issue if the TTL expires and > > > > > > > > > > > > > > Server A is having an extended > > > > > > > outage. > > > > > > > > > > > > > > How do we recover from that? > > > > > > > > > > > > > > ~jon > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ____________________________________________ > > > > > > > > > > > > > > > ___ Dots mailing list Dots@ietf.org > > > > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > > > > > > > > > > > > > ______________________________________________ > > > > > > > > > > > > > > _ Dots mailing list Dots@ietf.org > > > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > > > > > > > > > > > > > ______________________________________________ > > > > > > > > > > > > > > _ Dots mailing list Dots@ietf.org > > > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > Dots mailing list > > > > > > > > > > > > Dots@ietf.org > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > Dots mailing list > > > > > > > > > > Dots@ietf.org > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Dots mailing list > > > > > > > Dots@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > _______________________________________________ > > > > > > Dots mailing list > > > > > > Dots@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > _______________________________________________ > > > > Dots mailing list > > > > Dots@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots From nobody Mon Apr 9 01:39:26 2018 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 2F722127419 for ; Mon, 9 Apr 2018 01:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxLqA5KY9LH2 for ; Mon, 9 Apr 2018 01:39: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 0193B126C19 for ; Mon, 9 Apr 2018 01:39:21 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.90_1) (envelope-from ) id 1f5SKb-0003PP-HQ; Mon, 09 Apr 2018 09:39:17 +0100 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , , References: <014f01d3cc19$2e3880e0$8aa982a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7E7B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <019901d3cc23$a93ff8e0$fbbfeaa0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8524@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <004e01d3ccb4$d505e7f0$7f11b7d0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8758@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEF912A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEF93EE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <008501d3cda6$c860d210$59227630$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF951 1@OPEXCLILMA3 . corporate.adroot.infra.ftgroup> <00b001d3cdab$ba8caec0$2fa60c40$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF975C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <00b801d3cdb4$982dc4a0$c8894de0$@jpshallow.com> <015101d3ce74$351393c0$9f3abb40$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEFA190@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Date: Mon, 9 Apr 2018 09:39:18 +0100 Message-ID: <01f501d3cfde$4014ca30$c03e5e90$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ5xX4UsK17va5Vv37fpNudI6+9awKIdnG+AkIt6UkCuIhgoQJj4oJpArGJQHwA3D0H4gGs0H5ZApHDVXYB/IC8TgE0bwOgAlFzC1QBmQ12ZgGCQ5TmAa02vLICgeu4wAFxD+3yAcnB1kgBbHrBnwH1+oe0Ao3oNgYBtwYJxKFhGe/A Content-Language: en-gb Archived-At: Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling 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, 09 Apr 2018 08:39:25 -0000 Hi all, Should 'ttl' actually be 'lifetime' to remove any confusion over whether this is DNS TTL usage or not ? Otherwise see inline [Jon] Regards Jon -----Original Message----- From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 09 April 2018 09:23 To: mohamed.boucadair@orange.com; Jon Shallow; dots@ietf.org Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > -----Original Message----- > From: mohamed.boucadair@orange.com > [mailto:mohamed.boucadair@orange.com] > Sent: Monday, April 9, 2018 1:15 PM > To: Konda, Tirumaleswar Reddy ; > Jon Shallow ; dots@ietf.org > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling >=20 > Tiru, >=20 > What about this update ones? >=20 > =3D=3D=3D=3D=3D=3D=3D > ttl: Time to live (TTL) of the alternate DOTS server, represented = as > an integer number of seconds. That is, the time interval that = the > alternate DOTS server may be cached for use by a DOTS client. >=20 > A lifetime of negative one (-1) indicates indefinite TTL. This > value means that the alternate DOTS server is to be used until = the > alternate DOTS server redirects the traffic with another 3.00 > response. >=20 > If no 'ttl' is returned in a redirect response, this is = equivalent > to returning a 'ttl' parameter set to '-1'. Above text looks good. [Jon] Later in the text, there is reference to a minimum of 5 minutes before being able to switch back to the original DOTS server. Don't we = need to say a 5 minute (300 secs) minimum here? >=20 > If the alternate DOTS server TTL has expired, the DOTS client = MUST > use the DOTS server(s), that was provisioned using means = discussed > in Section 4.1, for creating new requests. It looks too restrictive, typically the DNS TTL values are short-lived (e.g.. few seconds) but the sessions are long-lived.=20 Why not replace "for creating new requests" with "for creating new DOTS session" ? [Jon] I think that once the alternate DOTS server's lifetime has = expired, the DOTS client should try to establish a connection with the = appropriate "normal" DOTS servers, if that fails, continue to use the alternate DOTS server, but periodically retry the "normal" servers to try to maintain resilience of service. After all, the outage (e.g. maintenance window) = of the original DOTS server may have to be extended, and being down, cannot respond with a 3.00 to instruct DOTS client to stay with the alternate = DOTS server. --Tiru >=20 > This is an optional attribute. > =3D=3D=3D >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Konda, Tirumaleswar Reddy > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > Envoy=E9=A0: lundi 9 avril 2018 08:51 > > =C0=A0: Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org = Objet=A0: RE: > > [Dots] Signal Channel - 300 Redirected Signaling > > > > Hi Jon, > > > > I partially agree with the suggested update. A IP address is cached = > > until the TTL value expires, the DOTS client need not disconnect=20 > > existing sessions after the TTL expires, but after the TTL expires=20 > > it must consider the IP address stale and not establish new (D)TLS=20 > > sessions. > > > > Cheers, > > -Tiru > > > > > -----Original Message----- > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow > > > Sent: Saturday, April 7, 2018 6:58 PM > > > To: Konda, Tirumaleswar Reddy=20 > > > ; > > > mohamed.boucadair@orange.com; dots@ietf.org > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > Hi there, > > > > > > My suggestion would be to make ttl of -1 'infinite', otherwise=20 > > > have a > > minimum > > > value of 300 seconds. The text could read (including referring to = > > > the > > optional > > > etc. to be consistent with the rest of the document:- > > > > > > alt-server: FQDN of an alternate DOTS server. > > > > > > This is a required attribute. > > > > > > alt-server-record: A list of IP addresses of an alternate DOTS > > > server. > > > > > > This is an optional attribute. > > > > > > ttl: Time to live (TTL) of the alternate DOTS server, = represented as > > > an integer number of seconds. That is, the time interval = that the > > > alternate DOTS server may be used by a DOTS client. > > > > > > The minimum value is '300' seconds, or '-1'. > > > > > > '-1' means that the alternate DOTS server is to be used=20 > > > until the > > alternate > > > DOTS server redirects the traffic with another 3.00 response. > > > There is no TTL expiry. > > > > > > If no 'ttl' is returned in a redirect response, this is equivalent > > > to returning a 'ttl' parameter set to '-1'. > > > > > > If the alternate DOTS server TTL has expired, the DOTS = client MUST > > > use the DOTS server(s) that was provisioned using means discussed > > > in Section 4.1. > > > > > > This is an optional attribute. > > > > > > > > > > > > Regards > > > > > > Jon > > > > > > -----Original Message----- > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda,=20 > > > Tirumaleswar Reddy > > > Sent: 06 April 2018 15:55 > > > To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > The below proposed change does not look good to me, its causing=20 > > > the DOTS client to ping-pong between multiple DOTS servers because = > > > of the TTL > value. > > > The alternate server should serve the DOTS client till there is a=20 > > > planned maintenance, if it is getting over-subscribed it should=20 > > > re-direct the new > > DOTS > > > clients to an alternate server and avoid bouncing the existing=20 > > > DOTS clients > > which > > > have been sending mitigation requests to it. > > > > > > -Tiru > > > > > > > -----Original Message----- > > > > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > Sent: Friday, April 6, 2018 8:06 PM > > > > To: mohamed.boucadair@orange.com; Konda, Tirumaleswar Reddy=20 > > > > ; dots@ietf.org > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > Hi Med, > > > > > > > > Thanks for this. I would like to see the ttl: definition=20 > > > > tightened up (moved away from the DNS TTL version) > > > > > > > > Old > > > > > > > > ttl: Time to live (TTL) of alternate records, represented as = an > > > > integer number of seconds. That is, the time interval = that > > > > alternate IP addresses may be cached by a DOTS client. > > > > > > > > '0' means that an alternate IP address is only to be used = for the > > > > request in progress, and consequently that IP address = should not > > > > be cached. > > > > > > > > If no 'ttl' is returned in a redirect response, this is equivalent > > > > to returning a 'ttl' parameter set to '0'. > > > > > > > > If 'alt-server-record' has expired, the DOTS client MUST = use the > > > > DOTS server(s) that was provisioned using means discussed = in > > > > Section 4.1. Furthermore, a DOTS client MUST NOT use the = alt- > > > > server FQDN if the 'alt-server-records' has expired. > > > > > > > > New > > > > > > > > ttl: Time to live (TTL) of the alternate DOTS server,=20 > > > > represented as > > > an > > > > integer number of seconds. That is, the time interval = that > > > > the alternate DOTS server may be cached for use by a DOTS client. > > > > > > > > '0' means that the alternate DOTS server is only to be = used for the > > > > request in progress, and consequently the alternate DOTS=20 > > > > server entry should not > > > > be cached. > > > > > > > > If no 'ttl' is returned in a redirect response, this is equivalent > > > > to returning a 'ttl' parameter set to '0'. > > > > > > > > If the alternate DOTS server TTL has expired, the DOTS=20 > > > > client MUST > > > use the > > > > DOTS server(s) that was provisioned using means discussed = in > > > > Section 4.1. > > > > > > > > > > > > Regards > > > > > > > > Jon > > > > > > > > -----Original Message----- > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of=20 > > > > mohamed.boucadair@orange.com > > > > Sent: 06 April 2018 15:21 > > > > To: Jon Shallow; Konda, Tirumaleswar Reddy; dots@ietf.org > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > FWIW, I implemented the change at: > > > > https://github.com/boucadair/draft-ietf-dots-signal-channel/blob > > > > /m > > > > aste > > > > r/draf > > > > t-ietf-dots-signal-channel.txt > > > > > > > > Cheers, > > > > Med > > > > > > > > > -----Message d'origine----- > > > > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > > Envoy=E9=A0: vendredi 6 avril 2018 15:33 =C0=A0: BOUCADAIR = Mohamed=20 > > > > > IMT/OLN; Konda, Tirumaleswar Reddy; dots@ietf.org Objet=A0: = RE: > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > Excellent. > > > > > > > > > > Thanks > > > > > > > > > > Jon > > > > > > > > > > -----Original Message----- > > > > > From: mohamed.boucadair@orange.com [mailto: > > > > > mohamed.boucadair@orange.com] > > > > > Sent: 06 April 2018 14:29 > > > > > To: Jon Shallow; Konda, Tirumaleswar Reddy; rdd@cert.org > > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > Hi Jon, all, > > > > > > > > > > I'm fine to put ttl at the level of alt-server. > > > > > > > > > > Cheers, > > > > > Med > > > > > > > > > > > -----Message d'origine----- > > > > > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > > > Envoy=E9=A0: vendredi 6 avril 2018 14:57 =C0=A0: BOUCADAIR = Mohamed=20 > > > > > > IMT/OLN; Konda, Tirumaleswar Reddy; rdd@cert.org Objet=A0: = RE: > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > Hi there, > > > > > > > > > > > > See inline [Jon3] > > > > > > > > > > > > Regards > > > > > > > > > > > > Jon > > > > > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Konda, Tirumaleswar = > > > > > > > > > Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > > > > Envoy=E9=A0: vendredi 6 avril 2018 07:07 =C0=A0: = BOUCADAIR=20 > > > > > > > > > Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet=A0: = RE: > > > > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > > > > Hi Med, > > > > > > > > > > > > > > > > > > The proposed update restricts the client no to do a=20 > > > > > > > > > DNS lookup using the alternate FQDN, further=20 > > > > > > > > > associating a TTL with the name complicates the=20 > > > > > > > > > functionality on the DOTS client to re-establish=20 > > > > > > > > > (D)TLS session with the primary DOTS server after the > > > > > TTL expires. > > > > > > > > > My suggestion is to let the DOTS client continue to=20 > > > > > > > > > use the alternate DOTS > > > > > > > server > > > > > > > > till it gets re-directed. > > > > > > > > > > > > > > > > [Med] This is possible with the current spec. > > > > > > > > > > > > > > > > Triggers for redirect and for falling back to the=20 > > > > > > > > nominal configuration are deployment-specific. The=20 > > > > > > > > current spec allows for almost all the cases > > > > > > > discussed > > > > > > > > so far: > > > > > > > > > > > > > > > > (1) Redirect for the request in progress: A server does=20 > > > > > > > > so by returning > > > > > > > TTL=3D0. > > > > > > > > (2) The alternate server is not involved in fall back to = > > > > > > > > the nominal > > > > > > > server: upon > > > > > > > > expiry of ttl of all alternate IP addresses, then fall=20 > > > > > > > > back automatically > > > > > > > to the > > > > > > > > nominal server. > > > > > > > > (3) Redirect to an alternate server, which in turn will=20 > > > > > > > > instruct the client > > > > > > > to > > > > > > > > redirect to the "base" configuration: a TTL is provided = > > > > > > > > and the alternate > > > > > > > server > > > > > > > > can reply with a redirect code any time before the=20 > > > > > > > > expiry of the TTL. A > > > > > > > long TTL > > > > > > > > can be returned if the alternate server will be=20 > > > > > > > > responsible for > > > > > > > coordinating fall > > > > > > > > back to the base server. > > > > > > > > (4) Stop infinite redirects > > > > > > > > > > > > > > Yes, but (1) and (2) complicate the functionality of the=20 > > > > > > > DOTS > > > client. > > > > > > > > > > > > [Med] (1) and (2) is exactly the same functionality required = > > > > > > for caching DNS replies. > > > > > > > > > > > > The > > > > > > > only reason for adding alt-server-record in the response=20 > > > > > > > is DNS server may not be reachable by the DOTS server=20 > > > > > > > because of a DDoS > > > > attack. > > > > > > > > > > > > > > > > > > > [Med] Yes. Note that even if the name resolution was=20 > > > > > > allowed, the client has to deal with the TTL indicated in=20 > > > > > > the response...which is exactly the same as (1) and (2). > > > > > > > > > > > > > > > > > > [Jon3] I think where I am struggling here is the overloaded=20 > > > > > > use of TTL > > > > > > - The TTL as per a DNS record and held as a part of=20 > > > > > > alt-server-record and then the TTL after which that the=20 > > > > > > alt-server should be handling the traffic before handling=20 > > > > > > back to the original primary server. It either has to be=20 > > > > > > one or the other, or they have to > > > > have different names. > > > > > > [Jon3] If we are only going to go for one variant for=20 > > > > > > simplicity, then I would prefer that it should be at the=20 > > > > > > level of "alt- > server". > > > > > > Handling the TTL for DNS refresh is normally handled by a=20 > > > > > > resolver library, updated by the DNS packets coming in -=20 > > > > > > unusual for an application > > > > > to have to do that. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I > > > > > > > > > don't think the DOTS mitigation provider will know=20 > > > > > > > > > ahead-of-time the TTL value after which the DOTS=20 > > > > > > > > > client should disconnect communicating with the=20 > > > > > > > > > alternate DOTS server and re-establish (D)TLS session=20 > > > > > > > > > with the primary DOTS > > > server. > > > > > > > > > > > > > > > > [Med] It depends on the nature of the redirect:=20 > > > > > > > > overload, planned > > > > > > > maintenance, > > > > > > > > etc. For planned maintenance, the TTL is known in = general. > > > > > > > > > > > > > > It's the primary DOTS server responsibility to point the=20 > > > > > > > DOTS client to an optimal alternate server, where the=20 > > > > > > > client can continue to send migration requests without a=20 > > > > > > > frequent ping-pong > > > > between servers. > > > > > > > > > > > > [Med] Agree. This is a service configuration problem. > > > > > > [Jon3] Agreed - and the 5 minute minimum ping-pong time is a = > > > > > > good safety net. > > > > > > ~jon3 > > > > > > > > > > > > > I have seen TURN servers being deployed for several years=20 > > > > > > > with > > > > > > re-direction > > > > > > > but without the need for TTL (see ALTERNATE-SERVER in > > > > > > > https://tools.ietf.org/html/draft-ietf-tram-turnbis-11) > > > > > > > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf=20 > > > > > > > > > > Of mohamed.boucadair@orange.com > > > > > > > > > > Sent: Thursday, April 5, 2018 4:50 PM > > > > > > > > > > To: Konda, Tirumaleswar Reddy=20 > > > > > > > > > > ; > > > > > > > > > > Jon Shallow ;=20 > > > > > > > > > > dots@ietf.org > > > > > > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected=20 > > > > > > > > > > Signaling > > > > > > > > > > > > > > > > > > > > Tiru, > > > > > > > > > > > > > > > > > > > > I don't see the NEW text as a restriction but as a=20 > > > > > > > > > > simplification of the > > > > > > > > > client's > > > > > > > > > > behavior. I don't want to over-specify the redirect behavior. > > > > > > > > > > > > > > > > > > > > Adding another yet layer of resolution will raise=20 > > > > > > > > > > other issues such as the > > > > > > > > > need to > > > > > > > > > > associate a TTL with the name itself. > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > Med > > > > > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Konda,=20 > > > > > > > > > > > Tirumaleswar Reddy=20 > > > > > > > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > > > > > > Envoy=E9=A0: jeudi 5 avril 2018 12:06 =C0=A0: Jon = Shallow;=20 > > > > > > > > > > > BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet=A0: > > > > > > RE: > > > > > > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: Jon Shallow=20 > > > > > > > > > > > > [mailto:supjps-ietf@jpshallow.com] > > > > > > > > > > > > Sent: Thursday, April 5, 2018 1:35 PM > > > > > > > > > > > > To: mohamed.boucadair@orange.com; Konda,=20 > > > > > > > > > > > > Tirumaleswar Reddy=20 > > > > > > > > > > > > ; > > > > > > > > > > > > dots@ietf.org > > > > > > > > > > > > Subject: RE: [Dots] Signal Channel - 300=20 > > > > > > > > > > > > Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > > > Hi Med, > > > > > > > > > > > > > > > > > > > > > > > > Thanks for this refresh to 4.6 Redirected=20 > > > > > > > > > > > > Signaling > > > > > > > > > > > > > > > > > > > > > > > > Some comments > > > > > > > > > > > > > > > > > > > > > > > > #1 > > > > > > > > > > > > > > > > > > > > > > > > The DOTS server can return the error response = > > > > > > > > > > > > code > > > > > > > > > > > > 3.00 in > > > > > > > response > > > > > > > > > > > > to a PUT request from the DOTS client or=20 > > > > > > > > > > > > convey the error > > > > > > > response > > > > > > > > > > > > code 3.00 in a unidirectional notification=20 > > > > > > > > > > > > response from the > > > > > > > DOTS > > > > > > > > > > > > server. > > > > > > > > > > > > > > > > > > > > > > > > Why is this limited to a PUT request and/or=20 > > > > > > > > > > > > unidirectional notification > > > > > > > > > > > response? > > > > > > > > > > > > - Surely, any response, unsolicited or otherwise = > > > > > > > > > > > > can contain a > > > > > > > > > > > > 3.00 > > > > > > > > > > > > - If Observe is not in use, then any unsolicited = > > > > > > > > > > > > notification response will potentially get=20 > > > > > > > > > > > > rejected by the coap library layer, so a DOTS=20 > > > > > > > > > > > > Server cannot > > > > > > > > > > > signal > > > > > > > > > > > > maintenance outage other than by closing the session. > > > > > > > > > > > > - I missed this the last review - sorry > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > #2 > > > > > > > > > > > > > > > > > > > > > > > > If the DOTS client has been redirected to a=20 > > > > > > > > > > > > DOTS server to > > > > > > which > > > > > > > it > > > > > > > > > > > > has already sent the mitigation request=20 > > > > > > > > > > > > within the last five > > > > > > (5) > > > > > > > > > > > > minutes, it MUST ignore the redirection and=20 > > > > > > > > > > > > try to contact other DOTS > > > > > > > > > > > > > > > > > > > > > > > > s/ has already sent the mitigation request/ has=20 > > > > > > > > > > > > already communicated with/ > > > > > > > > > > > > > > > > > > > > > > > > #3 > > > > > > > > > > > > > > > > > > > > > > > > A DOTS client MUST NOT use an alternate IP = > > > > > > > > > > > > address to > > > > > > contact > > > > > > > its > > > > > > > > > > > > DOTS server upon expiry of the associated = TTL. > > > > > > > > > > > > > > > > > > > > > > > > To remove ambiguity over the use of FQDN, this=20 > > > > > > > > > > > > could read > > > > > > > > > > > > > > > > > > > > > > > > A DOTS client MUST NOT use an alternate IP = > > > > > > > > > > > > address to > > > > > > contact > > > > > > > its > > > > > > > > > > > > DOTS server upon expiry of the associated = TTL. > > > > > > > > > > > > Furthermore, a > > > > > > > > > DOTS > > > > > > > > > > > > Client MUST NOT use the alt-server FQDN if = > > > > > > > > > > > > all of the > > > > > > > > > > > > alt-server- > > > > > > > > > > > records > > > > > > > > > > > > have expired. > > > > > > > > > > > > > > > > > > > > > > > > Or alternatively > > > > > > > > > > > > > > > > > > > > > > > > alt-server: FQDN of an alternate DOTS = server. > > > > > > > > > > > > > > > > > > > > > > > > This could read > > > > > > > > > > > > > > > > > > > > > > > > alt-server: FQDN of an alternate DOTS = server. > > > > > > > > > > > > This FQDN is not to be > > > > > > > > > > > used for > > > > > > > > > > > > looking up IP addresses to use, but is there for = > > > > > > > > > > > > the SNI extension > > > > > > > > > (7.1. > > > > > > > > > > > (D)TLS > > > > > > > > > > > > Protocol Profile) > > > > > > > > > > > > > > > > > > > > > > I don't think the above restriction is correct for = > > > > > > > > > > > the following > > > > > > > reasons: > > > > > > > > > > > > > > > > > > > > > > 1) If the TTL value in the alt-server-record=20 > > > > > > > > > > > expires, DNS lookup can be performed by the DOTS=20 > > > > > > > > > > > client using the alternate DOTS > > > > > > server > > > > > > > FQDN. > > > > > > > > > > > 2) If the DNS server is reachable, the client may=20 > > > > > > > > > > > want to a DANE lookup to get the IP addresses and=20 > > > > > > > > > > > certificate to validate the alternate DOTS server=20 > > > > > > > > > > > certificate > sent > > > > > > > > > > > in the DTLS handshake. > > > > > > > > > > > > > > > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > > > > > > > Jon > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: Dots [mailto: dots-bounces@ietf.org] On=20 > > > > > > > > > > > > Behalf Of mohamed.boucadair@orange.com > > > > > > > > > > > > Sent: 05 April 2018 08:20 > > > > > > > > > > > > To: Konda, Tirumaleswar Reddy; Jon Shallow;=20 > > > > > > > > > > > > dots@ietf.org > > > > > > > > > > > > Subject: Re: [Dots] Signal Channel - 300=20 > > > > > > > > > > > > Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > > > Hi Tiru, > > > > > > > > > > > > > > > > > > > > > > > > Works for me. > > > > > > > > > > > > > > > > > > > > > > > > I updated the draft with the text additions that = > > > > > > > > > > > > were discussed in this thread. The changes can = be found at: > > > > > > > > > > > > https://github.com/boucadair/draft-ietf-dots-sig > > > > > > > > > > > > na > > > > > > > > > > > > l- > > > > > > > > > > > channel/blob/master/draf > > > > > > > > > > > > t-ietf-dots-signal-channel.txt > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > Med > > > > > > > > > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Konda,=20 > > > > > > > > > > > > > Tirumaleswar Reddy=20 > > > > > > > > > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > > > > > > > > Envoy=E9=A0: mercredi 4 avril 2018 17:40 = =C0=A0: Jon=20 > > > > > > > > > > > > > Shallow; BOUCADAIR Mohamed IMT/OLN;=20 > > > > > > > > > > > > > dots@ietf.org > > > Objet=A0: RE: > > > > > > > > > > > > > [Dots] Signal Channel - 300 Redirected=20 > > > > > > > > > > > > > Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > The TTL value returned under alt-server-record = > > > > > > > > > > > > > is equivalent to the DNS TTL value. A DDoS=20 > > > > > > > > > > > > > mitigation provider with multiple DOTS servers = > > > > > > > > > > > > > typically re-directs a DOTS client to a=20 > > > > > > > > > > > > > different DOTS server only if the alternate=20 > > > > > > > > > > > > > DOTS server has the capacity to handle the=20 > > > > > > > > > > > > > requests from the > > > > > > > > > > > > DOTS client. > > > > > > > > > > > > > > > > > > > > > > > > > > We can add the following lines to avoid loops = : > > > > > > > > > > > > > > > > > > > > > > > > > > If the DOTS client has been redirected to a=20 > > > > > > > > > > > > > DOTS server to which it has already sent the=20 > > > > > > > > > > > > > mitigation request within the last five=20 > > > > > > > > > > > > > minutes, it MUST ignore the redirection and=20 > > > > > > > > > > > > > try reaching others servers listed in the=20 > > > > > > > > > > > > > local configuration or discovered using=20 > > > > > > > > > > > > > dynamic means > > > > > such as DHCP or SRV procedures. > > > > > > > > > > > > > This prevents infinite ping-ponging between=20 > > > > > > > > > > > > > servers in case of redirection loops. > > > > > > > > > > > > > > > > > > > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > From: Dots [mailto:dots-bounces@ietf.org] On = > > > > > > > > > > > > > > Behalf Of Jon Shallow > > > > > > > > > > > > > > Sent: Wednesday, April 4, 2018 8:16 PM > > > > > > > > > > > > > > To: mohamed.boucadair@orange.com;=20 > > > > > > > > > > > > > > dots@ietf.org > > > > > > > > > > > > > > Subject: Re: [Dots] Signal Channel - 300=20 > > > > > > > > > > > > > > Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi there, > > > > > > > > > > > > > > > > > > > > > > > > > > > > See inline [Jon] > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > From: Dots [mailto: dots-bounces@ietf.org]=20 > > > > > > > > > > > > > > On Behalf Of mohamed.boucadair@orange.com > > > > > > > > > > > > > > Sent: 04 April 2018 15:07 > > > > > > > > > > > > > > To: Jon Shallow; dots@ietf.org > > > > > > > > > > > > > > Subject: Re: [Dots] Signal Channel - 300=20 > > > > > > > > > > > > > > Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > > > Re-, > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please see inline. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > Med > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Dots=20 > > > > > > > > > > > > > > > [mailto:dots-bounces@ietf.org] De la part=20 > > > > > > > > > > > > > > > de Jon Shallow Envoy=E9=A0: mercredi 4 = avril 2018 15:31 =C0=A0: > > > > > > > > > > > > > > > dots@ietf.org > > > > > > > > > Objet=A0: > > > > > > > > > > > > > > > [Dots] Signal Channel - 300 Redirected=20 > > > > > > > > > > > > > > > Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi there, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have implemented the 300=20 > > > > > > > > > > > > > > > Redirected-Signal in my DOTS > > > > > > code. > > > > > > > > > > > > > > > This then raises some questions about usability. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Usability #1 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Architecture 3.2.2 Redirected Signalling > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 4. Having redirected the DOTS client,=20 > > > > > > > > > > > > > > > DOTS server A ceases > > > > > > > > > > > sending > > > > > > > > > > > > > > > server signals. The DOTS client=20 > > > > > > > > > > > > > > > likewise stops sending > > > > > > > > > client > > > > > > > > > > > > > > > signals to DOTS server A. DOTS=20 > > > > > > > > > > > > > > > session 1 is > > > > > > > terminated. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Clearly indicates that the original=20 > > > > > > > > > > > > > > > session (Client to Server > > > > > > > > > > > > > > > A) is no more once redirected and only=20 > > > > > > > > > > > > > > > Client to Server B is in > > > > > > > > > use. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > How is the traffic redirected back to=20 > > > > > > > > > > > > > > > Server A once maintenance / overloading = etc. has finished? > > > > > > > > > > > > > > > My assumption is that Server B sends a=20 > > > > > > > > > > > > > > > redirect to go back to Server A as Server=20 > > > > > > > > > > > > > > > A has no way to say over a now=20 > > > > > > > > > > > > > > > non-existent session to say > > > > > > > > > > "come back". > > > > > > > > > > > > > > > > > > > > > > > > > > > > [Med] That's one possibility. This one does=20 > > > > > > > > > > > > > > not require any update to the > > > > > > > > > > > > > signal- > > > > > > > > > > > > > > channel specification. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Another approach would be to not require any = > > > > > > > > > > > > > > redirect signal from server > > > > > > > > > > > > B. > > > > > > > > > > > > > > The client will remove server B's records=20 > > > > > > > > > > > > > > upon the expiry of the TTL and > > > > > > > > > > > > > will fall > > > > > > > > > > > > > > back to the "base" DOTS servers=20 > > > > > > > > > > > > > > configuration that was provisioned to the > > > > > > > > > > > > > client > > > > > > > > > > > > > > using DHCP or whatever mechanism. > > > > > > > > > > > > > > [Jon] OK. The TTL is defined at,=20 > > > > > > > > > > > > > > associated with the IP address level > > > > > > > > > > > > > under alt- > > > > > > > > > > > > > > server-record, not under > > > > > > > > > > > > > > ietf-dots-signal-channel:redirected-signal. The ttl > > > > > > > definition is > > > > > > > > > > > > > > ambiguous as to what it refers to and=20 > > > > > > > > > > > > > > perhaps could be tightened up in the=20 > > > > > > > > > > > > > > language (I read it as being associated with = > > > > > > > > > > > > > > "addr" in the sense of a DNS > > > > > > > > > > > > > TTL). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Do we need to keep the existing Client to=20 > > > > > > > > > > > > > > > Server A session warm (or perhaps to probe > > > > > > > > > > > > > > > periodically) to see if Server A is=20 > > > > > > > > > > > > > > > capable of handling the Client again by a=20 > > > > > > > > > > > > > > > server response extension to the protocol=20 > > > > > > > > > > > > > > > (e.g. a > > > > > > > > > > > > > > > 3.01) > > > > > > > > > > > > > > > > > > > > > > > > > > > > [Med] Redirect was initially introduced to=20 > > > > > > > > > > > > > > manage a server overload, so I > > > > > > > > > > > > > don't > > > > > > > > > > > > > > think it makes sense to probe or maintain a=20 > > > > > > > > > > > > > > session with > > > > > > server > > > > > > > A. > > > > > > > > > > > > > > [Jon] Agreed, but I needed to raise the question. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Should there be a retry period parameter=20 > > > > > > > > > > > > > > > added in to the > > > > > > > > > > > > > > > 3.00 protocol (as I read it, ttl only=20 > > > > > > > > > > > > > > > refers to the IP > > > > > > > address)? > > > > > > > > > > > > > > > > > > > > > > > > > > > > [Med] The client will automatically switch=20 > > > > > > > > > > > > > > to Server A when all alternate > > > > > > > > > > > > > records > > > > > > > > > > > > > > expire. > > > > > > > > > > > > > > [Jon] OK - again the 4.6 text needs to get=20 > > > > > > > > > > > > > > tightened up to reflect this as > > > > > > > > > > > > > the > > > > > > > > > > > > > > intent. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Usability #2 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Server A says "Redirect to Server B" due=20 > > > > > > > > > > > > > > > to > > > > overloading. > > > > > > > > > > > > > > > Server B accepts things for a while and=20 > > > > > > > > > > > > > > > then is instructed/decides to redirect = traffic back to A. > > > > > > > > > > > > > > > Server A is left still overload configured = > > > > > > > > > > > > > > > to redirect to B. How should the client=20 > > > > > > > > > > > > > > > handle this as there is no suitable > > > > > > > > > > > > > > Server? > > > > > > > > > > > > > > > > > > > > > > > > > > > > [Med] This is a service configuration = problem. > > > > > > > > > > > > > > We may > > > > ask: > > > > > > > > > > > > > > * the client to log the error and notify the > > > > > administrator. > > > > > > > > > > > > > > * and/or stop the redirection after n = cycles. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Still, this does not solve the problem. > > > > > > > > > > > > > > [Jon] Agreed there is a problem here > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I agree that there needs to be=20 > > > > > > > > > > > > > > > co-ordination between Server A and Server=20 > > > > > > > > > > > > > > > B, but user error may > > > > creep in. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Usability #3 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Server A says "Redirect to Server B" as it = > > > > > > > > > > > > > > > going to be shut down because of=20 > > > > > > > > > > > > > > > maintenance. Server B accepts things for=20 > > > > > > > > > > > > > > > a while and then is instructed (in=20 > > > > > > > > > > > > > > > probable user > > > > > > > > > > > > > > > error) to redirect traffic back to A=20 > > > > > > > > > > > > > > > (perhaps because it has hit an overload=20 > > > > > > > > > > > > > > > condition). How should the client > > > > > > > > > > > > > > handle this? > > > > > > > > > > > > > > > > > > > > > > > > > > > > [Med] Isn't this a sub-case or #2? > > > > > > > > > > > > > > [Jon] Yes, but I wanted to bring in Server A = > > > > > > > > > > > > > > being alive and able to > > > > > > > > > > > > > respond > > > > > > > > > > > > > > versus Server A down and not responding due=20 > > > > > > > > > > > > > > to > > > > > maintenance. > > > > > > > > > > > > > > [Jon] With my better understanding of TTL we = > > > > > > > > > > > > > > still have an issue if the TTL expires and=20 > > > > > > > > > > > > > > Server A is having an extended > > > > > > > outage. > > > > > > > > > > > > > > How do we recover from that? > > > > > > > > > > > > > > ~jon > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > __________________________________________ > > > > > > > > > > > > > > > __ ___ Dots mailing list Dots@ietf.org=20 > > > > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > > > > > > > > > > > > > ____________________________________________ > > > > > > > > > > > > > > __ _ Dots mailing list Dots@ietf.org=20 > > > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > > > > > > > > > > > > > ____________________________________________ > > > > > > > > > > > > > > __ _ Dots mailing list Dots@ietf.org=20 > > > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > Dots mailing list Dots@ietf.org=20 > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > Dots mailing list > > > > > > > > > > Dots@ietf.org > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Dots mailing list > > > > > > > Dots@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > _______________________________________________ > > > > > > Dots mailing list > > > > > > Dots@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > _______________________________________________ > > > > Dots mailing list > > > > Dots@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Mon Apr 9 01:56:48 2018 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 AC0BC1276AF for ; Mon, 9 Apr 2018 01:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxsBO18HguBm for ; Mon, 9 Apr 2018 01:56:42 -0700 (PDT) Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3284E126C19 for ; Mon, 9 Apr 2018 01:56:42 -0700 (PDT) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 9260C120416; Mon, 9 Apr 2018 10:56:40 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.43]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 6B874180061; Mon, 9 Apr 2018 10:56:40 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5F.corporate.adroot.infra.ftgroup ([fe80::e172:f13e:8be6:71cc%18]) with mapi id 14.03.0382.000; Mon, 9 Apr 2018 10:56:39 +0200 From: To: Jon Shallow , "'Konda, Tirumaleswar Reddy'" , "dots@ietf.org" Thread-Topic: [Dots] Signal Channel - 300 Redirected Signaling Thread-Index: AQJ5xX4UsK17va5Vv37fpNudI6+9awKIdnG+AkIt6UkCuIhgoQJj4oJpArGJQHwA3D0H4gGs0H5ZApHDVXYB/IC8TgE0bwOgAlFzC1QBmQ12ZgGCQ5TmAa02vLICgeu4wAFxD+3yAcnB1kgBbHrBnwH1+oe0Ao3oNgYBtwYJxKFhGe/AgAAFucA= Date: Mon, 9 Apr 2018 08:56:39 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DEFA2DF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <014f01d3cc19$2e3880e0$8aa982a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7E7B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <019901d3cc23$a93ff8e0$fbbfeaa0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8524@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <004e01d3ccb4$d505e7f0$7f11b7d0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8758@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEF912A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEF93EE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <008501d3cda6$c860d210$59227630$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF951 1@OPEXCLILMA3 . corporate.adroot.infra.ftgroup> <00b001d3cdab$ba8caec0$2fa60c40$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF975C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <00b801d3cdb4$982dc4a0$c8894de0$@jpshallow.com> <015101d3ce74$351393c0$9f3abb40$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEFA190@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <01f501d3cfde$4014ca30$c03e5e90$@jpshallow.com> In-Reply-To: <01f501d3cfde$4014ca30$c03e5e90$@jpshallow.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling 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, 09 Apr 2018 08:56:47 -0000 Re-, Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > Envoy=E9=A0: lundi 9 avril 2018 10:39 > =C0=A0: 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf= .org > Objet=A0: RE: [Dots] Signal Channel - 300 Redirected Signaling >=20 > Hi all, >=20 > Should 'ttl' actually be 'lifetime' to remove any confusion over whether > this is DNS TTL usage or not ? [Med] we do already have a lifetime in the cbor mapping table. So, I sugges= t to maintain ttl but focus on its definition to avoid confusion.=20 >=20 > Otherwise see inline [Jon] >=20 > Regards >=20 > Jon >=20 > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumalesw= ar > Reddy > Sent: 09 April 2018 09:23 > To: mohamed.boucadair@orange.com; Jon Shallow; dots@ietf.org > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling >=20 > > -----Original Message----- > > From: mohamed.boucadair@orange.com > > [mailto:mohamed.boucadair@orange.com] > > Sent: Monday, April 9, 2018 1:15 PM > > To: Konda, Tirumaleswar Reddy ; > > Jon Shallow ; dots@ietf.org > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > Tiru, > > > > What about this update ones? > > > > =3D=3D=3D=3D=3D=3D=3D > > ttl: Time to live (TTL) of the alternate DOTS server, represented a= s > > an integer number of seconds. That is, the time interval that th= e > > alternate DOTS server may be cached for use by a DOTS client. > > > > A lifetime of negative one (-1) indicates indefinite TTL. This > > value means that the alternate DOTS server is to be used until th= e > > alternate DOTS server redirects the traffic with another 3.00 > > response. > > > > If no 'ttl' is returned in a redirect response, this is equivalen= t > > to returning a 'ttl' parameter set to '-1'. >=20 > Above text looks good. >=20 > [Jon] Later in the text, there is reference to a minimum of 5 minutes > before being able to switch back to the original DOTS server. Don't we n= eed > to say a 5 minute (300 secs) minimum here? [Med] That reference is when explicit redirect signals are involved.=20 >=20 > > > > If the alternate DOTS server TTL has expired, the DOTS client MUS= T > > use the DOTS server(s), that was provisioned using means discusse= d > > in Section 4.1, for creating new requests. >=20 > It looks too restrictive, typically the DNS TTL values are short-lived > (e.g.. few seconds) but the sessions are long-lived. > Why not replace "for creating new requests" with "for creating new DOTS > session" ? >=20 > [Jon] I think that once the alternate DOTS server's lifetime has expired, > the DOTS client should try to establish a connection with the appropriate > "normal" DOTS servers, [Med] Bingo. if that fails, continue to use the alternate DOTS > server, but periodically retry the "normal" servers to try to maintain > resilience of service.=20 [Med] The document does not specify the behavior for selecting among multip= le servers. So, this details are out of scope.=20 After all, the outage (e.g. maintenance window) of > the original DOTS server may have to be extended, and being down, cannot > respond with a 3.00 to instruct DOTS client to stay with the alternate DO= TS > server. >=20 [Med] For such cases, it is safe to return an indefinite TTL + alternate se= rver to coordinate the fallback behavior.=20 > --Tiru >=20 > > > > This is an optional attribute. > > =3D=3D=3D > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: Konda, Tirumaleswar Reddy > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > Envoy=E9=A0: lundi 9 avril 2018 08:51 > > > =C0=A0: Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet= =A0: RE: > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > Hi Jon, > > > > > > I partially agree with the suggested update. A IP address is cached > > > until the TTL value expires, the DOTS client need not disconnect > > > existing sessions after the TTL expires, but after the TTL expires > > > it must consider the IP address stale and not establish new (D)TLS > > > sessions. > > > > > > Cheers, > > > -Tiru > > > > > > > -----Original Message----- > > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow > > > > Sent: Saturday, April 7, 2018 6:58 PM > > > > To: Konda, Tirumaleswar Reddy > > > > ; > > > > mohamed.boucadair@orange.com; dots@ietf.org > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > Hi there, > > > > > > > > My suggestion would be to make ttl of -1 'infinite', otherwise > > > > have a > > > minimum > > > > value of 300 seconds. The text could read (including referring to > > > > the > > > optional > > > > etc. to be consistent with the rest of the document:- > > > > > > > > alt-server: FQDN of an alternate DOTS server. > > > > > > > > This is a required attribute. > > > > > > > > alt-server-record: A list of IP addresses of an alternate DOTS > > > > server. > > > > > > > > This is an optional attribute. > > > > > > > > ttl: Time to live (TTL) of the alternate DOTS server, represent= ed > as > > > > an integer number of seconds. That is, the time interval tha= t > the > > > > alternate DOTS server may be used by a DOTS client. > > > > > > > > The minimum value is '300' seconds, or '-1'. > > > > > > > > '-1' means that the alternate DOTS server is to be used > > > > until the > > > alternate > > > > DOTS server redirects the traffic with another 3.00 response. > > > > There is no TTL expiry. > > > > > > > > If no 'ttl' is returned in a redirect response, this is > equivalent > > > > to returning a 'ttl' parameter set to '-1'. > > > > > > > > If the alternate DOTS server TTL has expired, the DOTS client > MUST > > > > use the DOTS server(s) that was provisioned using means > discussed > > > > in Section 4.1. > > > > > > > > This is an optional attribute. > > > > > > > > > > > > > > > > Regards > > > > > > > > Jon > > > > > > > > -----Original Message----- > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, > > > > Tirumaleswar Reddy > > > > Sent: 06 April 2018 15:55 > > > > To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > The below proposed change does not look good to me, its causing > > > > the DOTS client to ping-pong between multiple DOTS servers because > > > > of the TTL > > value. > > > > The alternate server should serve the DOTS client till there is a > > > > planned maintenance, if it is getting over-subscribed it should > > > > re-direct the new > > > DOTS > > > > clients to an alternate server and avoid bouncing the existing > > > > DOTS clients > > > which > > > > have been sending mitigation requests to it. > > > > > > > > -Tiru > > > > > > > > > -----Original Message----- > > > > > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > > Sent: Friday, April 6, 2018 8:06 PM > > > > > To: mohamed.boucadair@orange.com; Konda, Tirumaleswar Reddy > > > > > ; dots@ietf.org > > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > Hi Med, > > > > > > > > > > Thanks for this. I would like to see the ttl: definition > > > > > tightened up (moved away from the DNS TTL version) > > > > > > > > > > Old > > > > > > > > > > ttl: Time to live (TTL) of alternate records, represented as = an > > > > > integer number of seconds. That is, the time interval that > > > > > alternate IP addresses may be cached by a DOTS client. > > > > > > > > > > '0' means that an alternate IP address is only to be used f= or > the > > > > > request in progress, and consequently that IP address shoul= d > not > > > > > be cached. > > > > > > > > > > If no 'ttl' is returned in a redirect response, this is > equivalent > > > > > to returning a 'ttl' parameter set to '0'. > > > > > > > > > > If 'alt-server-record' has expired, the DOTS client MUST us= e > the > > > > > DOTS server(s) that was provisioned using means discussed i= n > > > > > Section 4.1. Furthermore, a DOTS client MUST NOT use the a= lt- > > > > > server FQDN if the 'alt-server-records' has expired. > > > > > > > > > > New > > > > > > > > > > ttl: Time to live (TTL) of the alternate DOTS server, > > > > > represented as > > > > an > > > > > integer number of seconds. That is, the time interval that > > > > > the alternate DOTS server may be cached for use by a DOTS > client. > > > > > > > > > > '0' means that the alternate DOTS server is only to be used > for the > > > > > request in progress, and consequently the alternate DOTS > > > > > server entry should not > > > > > be cached. > > > > > > > > > > If no 'ttl' is returned in a redirect response, this is > equivalent > > > > > to returning a 'ttl' parameter set to '0'. > > > > > > > > > > If the alternate DOTS server TTL has expired, the DOTS > > > > > client MUST > > > > use the > > > > > DOTS server(s) that was provisioned using means discussed i= n > > > > > Section 4.1. > > > > > > > > > > > > > > > Regards > > > > > > > > > > Jon > > > > > > > > > > -----Original Message----- > > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > > > > mohamed.boucadair@orange.com > > > > > Sent: 06 April 2018 15:21 > > > > > To: Jon Shallow; Konda, Tirumaleswar Reddy; dots@ietf.org > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > FWIW, I implemented the change at: > > > > > https://github.com/boucadair/draft-ietf-dots-signal-channel/blob > > > > > /m > > > > > aste > > > > > r/draf > > > > > t-ietf-dots-signal-channel.txt > > > > > > > > > > Cheers, > > > > > Med > > > > > > > > > > > -----Message d'origine----- > > > > > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > > > Envoy=E9=A0: vendredi 6 avril 2018 15:33 =C0=A0: BOUCADAIR Moha= med > > > > > > IMT/OLN; Konda, Tirumaleswar Reddy; dots@ietf.org Objet=A0: RE: > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > Excellent. > > > > > > > > > > > > Thanks > > > > > > > > > > > > Jon > > > > > > > > > > > > -----Original Message----- > > > > > > From: mohamed.boucadair@orange.com [mailto: > > > > > > mohamed.boucadair@orange.com] > > > > > > Sent: 06 April 2018 14:29 > > > > > > To: Jon Shallow; Konda, Tirumaleswar Reddy; rdd@cert.org > > > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > Hi Jon, all, > > > > > > > > > > > > I'm fine to put ttl at the level of alt-server. > > > > > > > > > > > > Cheers, > > > > > > Med > > > > > > > > > > > > > -----Message d'origine----- > > > > > > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > > > > Envoy=E9=A0: vendredi 6 avril 2018 14:57 =C0=A0: BOUCADAIR Mo= hamed > > > > > > > IMT/OLN; Konda, Tirumaleswar Reddy; rdd@cert.org Objet=A0: RE= : > > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > Hi there, > > > > > > > > > > > > > > See inline [Jon3] > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Konda, Tirumaleswar > > > > > > > > > > Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > > > > > Envoy=E9=A0: vendredi 6 avril 2018 07:07 =C0=A0: BOUCAD= AIR > > > > > > > > > > Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet=A0: R= E: > > > > > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > > > > > > Hi Med, > > > > > > > > > > > > > > > > > > > > The proposed update restricts the client no to do a > > > > > > > > > > DNS lookup using the alternate FQDN, further > > > > > > > > > > associating a TTL with the name complicates the > > > > > > > > > > functionality on the DOTS client to re-establish > > > > > > > > > > (D)TLS session with the primary DOTS server after the > > > > > > TTL expires. > > > > > > > > > > My suggestion is to let the DOTS client continue to > > > > > > > > > > use the alternate DOTS > > > > > > > > server > > > > > > > > > till it gets re-directed. > > > > > > > > > > > > > > > > > > [Med] This is possible with the current spec. > > > > > > > > > > > > > > > > > > Triggers for redirect and for falling back to the > > > > > > > > > nominal configuration are deployment-specific. The > > > > > > > > > current spec allows for almost all the cases > > > > > > > > discussed > > > > > > > > > so far: > > > > > > > > > > > > > > > > > > (1) Redirect for the request in progress: A server does > > > > > > > > > so by returning > > > > > > > > TTL=3D0. > > > > > > > > > (2) The alternate server is not involved in fall back to > > > > > > > > > the nominal > > > > > > > > server: upon > > > > > > > > > expiry of ttl of all alternate IP addresses, then fall > > > > > > > > > back automatically > > > > > > > > to the > > > > > > > > > nominal server. > > > > > > > > > (3) Redirect to an alternate server, which in turn will > > > > > > > > > instruct the client > > > > > > > > to > > > > > > > > > redirect to the "base" configuration: a TTL is provided > > > > > > > > > and the alternate > > > > > > > > server > > > > > > > > > can reply with a redirect code any time before the > > > > > > > > > expiry of the TTL. A > > > > > > > > long TTL > > > > > > > > > can be returned if the alternate server will be > > > > > > > > > responsible for > > > > > > > > coordinating fall > > > > > > > > > back to the base server. > > > > > > > > > (4) Stop infinite redirects > > > > > > > > > > > > > > > > Yes, but (1) and (2) complicate the functionality of the > > > > > > > > DOTS > > > > client. > > > > > > > > > > > > > > [Med] (1) and (2) is exactly the same functionality required > > > > > > > for caching DNS replies. > > > > > > > > > > > > > > The > > > > > > > > only reason for adding alt-server-record in the response > > > > > > > > is DNS server may not be reachable by the DOTS server > > > > > > > > because of a DDoS > > > > > attack. > > > > > > > > > > > > > > > > > > > > > > [Med] Yes. Note that even if the name resolution was > > > > > > > allowed, the client has to deal with the TTL indicated in > > > > > > > the response...which is exactly the same as (1) and (2). > > > > > > > > > > > > > > > > > > > > > [Jon3] I think where I am struggling here is the overloaded > > > > > > > use of TTL > > > > > > > - The TTL as per a DNS record and held as a part of > > > > > > > alt-server-record and then the TTL after which that the > > > > > > > alt-server should be handling the traffic before handling > > > > > > > back to the original primary server. It either has to be > > > > > > > one or the other, or they have to > > > > > have different names. > > > > > > > [Jon3] If we are only going to go for one variant for > > > > > > > simplicity, then I would prefer that it should be at the > > > > > > > level of "alt- > > server". > > > > > > > Handling the TTL for DNS refresh is normally handled by a > > > > > > > resolver library, updated by the DNS packets coming in - > > > > > > > unusual for an application > > > > > > to have to do that. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I > > > > > > > > > > don't think the DOTS mitigation provider will know > > > > > > > > > > ahead-of-time the TTL value after which the DOTS > > > > > > > > > > client should disconnect communicating with the > > > > > > > > > > alternate DOTS server and re-establish (D)TLS session > > > > > > > > > > with the primary DOTS > > > > server. > > > > > > > > > > > > > > > > > > [Med] It depends on the nature of the redirect: > > > > > > > > > overload, planned > > > > > > > > maintenance, > > > > > > > > > etc. For planned maintenance, the TTL is known in general= . > > > > > > > > > > > > > > > > It's the primary DOTS server responsibility to point the > > > > > > > > DOTS client to an optimal alternate server, where the > > > > > > > > client can continue to send migration requests without a > > > > > > > > frequent ping-pong > > > > > between servers. > > > > > > > > > > > > > > [Med] Agree. This is a service configuration problem. > > > > > > > [Jon3] Agreed - and the 5 minute minimum ping-pong time is a > > > > > > > good safety net. > > > > > > > ~jon3 > > > > > > > > > > > > > > > I have seen TURN servers being deployed for several years > > > > > > > > with > > > > > > > re-direction > > > > > > > > but without the need for TTL (see ALTERNATE-SERVER in > > > > > > > > https://tools.ietf.org/html/draft-ietf-tram-turnbis-11) > > > > > > > > > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf > > > > > > > > > > > Of mohamed.boucadair@orange.com > > > > > > > > > > > Sent: Thursday, April 5, 2018 4:50 PM > > > > > > > > > > > To: Konda, Tirumaleswar Reddy > > > > > > > > > > > ; > > > > > > > > > > > Jon Shallow ; > > > > > > > > > > > dots@ietf.org > > > > > > > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected > > > > > > > > > > > Signaling > > > > > > > > > > > > > > > > > > > > > > Tiru, > > > > > > > > > > > > > > > > > > > > > > I don't see the NEW text as a restriction but as a > > > > > > > > > > > simplification of the > > > > > > > > > > client's > > > > > > > > > > > behavior. I don't want to over-specify the redirect > behavior. > > > > > > > > > > > > > > > > > > > > > > Adding another yet layer of resolution will raise > > > > > > > > > > > other issues such as the > > > > > > > > > > need to > > > > > > > > > > > associate a TTL with the name itself. > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > Med > > > > > > > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Konda, > > > > > > > > > > > > Tirumaleswar Reddy > > > > > > > > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > > > > > > > Envoy=E9=A0: jeudi 5 avril 2018 12:06 =C0=A0: Jon S= hallow; > > > > > > > > > > > > BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet=A0: > > > > > > > RE: > > > > > > > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > From: Jon Shallow > > > > > > > > > > > > > [mailto:supjps-ietf@jpshallow.com] > > > > > > > > > > > > > Sent: Thursday, April 5, 2018 1:35 PM > > > > > > > > > > > > > To: mohamed.boucadair@orange.com; Konda, > > > > > > > > > > > > > Tirumaleswar Reddy > > > > > > > > > > > > > ; > > > > > > > > > > > > > dots@ietf.org > > > > > > > > > > > > > Subject: RE: [Dots] Signal Channel - 300 > > > > > > > > > > > > > Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Med, > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks for this refresh to 4.6 Redirected > > > > > > > > > > > > > Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > Some comments > > > > > > > > > > > > > > > > > > > > > > > > > > #1 > > > > > > > > > > > > > > > > > > > > > > > > > > The DOTS server can return the error response > > > > > > > > > > > > > code > > > > > > > > > > > > > 3.00 in > > > > > > > > response > > > > > > > > > > > > > to a PUT request from the DOTS client or > > > > > > > > > > > > > convey the error > > > > > > > > response > > > > > > > > > > > > > code 3.00 in a unidirectional notification > > > > > > > > > > > > > response from the > > > > > > > > DOTS > > > > > > > > > > > > > server. > > > > > > > > > > > > > > > > > > > > > > > > > > Why is this limited to a PUT request and/or > > > > > > > > > > > > > unidirectional notification > > > > > > > > > > > > response? > > > > > > > > > > > > > - Surely, any response, unsolicited or otherwise > > > > > > > > > > > > > can contain a > > > > > > > > > > > > > 3.00 > > > > > > > > > > > > > - If Observe is not in use, then any unsolicited > > > > > > > > > > > > > notification response will potentially get > > > > > > > > > > > > > rejected by the coap library layer, so a DOTS > > > > > > > > > > > > > Server cannot > > > > > > > > > > > > signal > > > > > > > > > > > > > maintenance outage other than by closing the > session. > > > > > > > > > > > > > - I missed this the last review - sorry > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > #2 > > > > > > > > > > > > > > > > > > > > > > > > > > If the DOTS client has been redirected to a > > > > > > > > > > > > > DOTS server to > > > > > > > which > > > > > > > > it > > > > > > > > > > > > > has already sent the mitigation request > > > > > > > > > > > > > within the last five > > > > > > > (5) > > > > > > > > > > > > > minutes, it MUST ignore the redirection and > > > > > > > > > > > > > try to contact other DOTS > > > > > > > > > > > > > > > > > > > > > > > > > > s/ has already sent the mitigation request/ has > > > > > > > > > > > > > already communicated with/ > > > > > > > > > > > > > > > > > > > > > > > > > > #3 > > > > > > > > > > > > > > > > > > > > > > > > > > A DOTS client MUST NOT use an alternate IP > > > > > > > > > > > > > address to > > > > > > > contact > > > > > > > > its > > > > > > > > > > > > > DOTS server upon expiry of the associated T= TL. > > > > > > > > > > > > > > > > > > > > > > > > > > To remove ambiguity over the use of FQDN, this > > > > > > > > > > > > > could read > > > > > > > > > > > > > > > > > > > > > > > > > > A DOTS client MUST NOT use an alternate IP > > > > > > > > > > > > > address to > > > > > > > contact > > > > > > > > its > > > > > > > > > > > > > DOTS server upon expiry of the associated T= TL. > > > > > > > > > > > > > Furthermore, a > > > > > > > > > > DOTS > > > > > > > > > > > > > Client MUST NOT use the alt-server FQDN if > > > > > > > > > > > > > all of the > > > > > > > > > > > > > alt-server- > > > > > > > > > > > > records > > > > > > > > > > > > > have expired. > > > > > > > > > > > > > > > > > > > > > > > > > > Or alternatively > > > > > > > > > > > > > > > > > > > > > > > > > > alt-server: FQDN of an alternate DOTS server. > > > > > > > > > > > > > > > > > > > > > > > > > > This could read > > > > > > > > > > > > > > > > > > > > > > > > > > alt-server: FQDN of an alternate DOTS server. > > > > > > > > > > > > > This FQDN is not to be > > > > > > > > > > > > used for > > > > > > > > > > > > > looking up IP addresses to use, but is there for > > > > > > > > > > > > > the SNI extension > > > > > > > > > > (7.1. > > > > > > > > > > > > (D)TLS > > > > > > > > > > > > > Protocol Profile) > > > > > > > > > > > > > > > > > > > > > > > > I don't think the above restriction is correct for > > > > > > > > > > > > the following > > > > > > > > reasons: > > > > > > > > > > > > > > > > > > > > > > > > 1) If the TTL value in the alt-server-record > > > > > > > > > > > > expires, DNS lookup can be performed by the DOTS > > > > > > > > > > > > client using the alternate DOTS > > > > > > > server > > > > > > > > FQDN. > > > > > > > > > > > > 2) If the DNS server is reachable, the client may > > > > > > > > > > > > want to a DANE lookup to get the IP addresses and > > > > > > > > > > > > certificate to validate the alternate DOTS server > > > > > > > > > > > > certificate > > sent > > > > > > > > > > > > in the DTLS handshake. > > > > > > > > > > > > > > > > > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > From: Dots [mailto: dots-bounces@ietf.org] On > > > > > > > > > > > > > Behalf Of mohamed.boucadair@orange.com > > > > > > > > > > > > > Sent: 05 April 2018 08:20 > > > > > > > > > > > > > To: Konda, Tirumaleswar Reddy; Jon Shallow; > > > > > > > > > > > > > dots@ietf.org > > > > > > > > > > > > > Subject: Re: [Dots] Signal Channel - 300 > > > > > > > > > > > > > Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Tiru, > > > > > > > > > > > > > > > > > > > > > > > > > > Works for me. > > > > > > > > > > > > > > > > > > > > > > > > > > I updated the draft with the text additions that > > > > > > > > > > > > > were discussed in this thread. The changes can be > found at: > > > > > > > > > > > > > https://github.com/boucadair/draft-ietf-dots-sig > > > > > > > > > > > > > na > > > > > > > > > > > > > l- > > > > > > > > > > > > channel/blob/master/draf > > > > > > > > > > > > > t-ietf-dots-signal-channel.txt > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > Med > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Konda, > > > > > > > > > > > > > > Tirumaleswar Reddy > > > > > > > > > > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > > > > > > > > > Envoy=E9=A0: mercredi 4 avril 2018 17:40 =C0=A0= : Jon > > > > > > > > > > > > > > Shallow; BOUCADAIR Mohamed IMT/OLN; > > > > > > > > > > > > > > dots@ietf.org > > > > Objet=A0: RE: > > > > > > > > > > > > > > [Dots] Signal Channel - 300 Redirected > > > > > > > > > > > > > > Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > > > The TTL value returned under alt-server-record > > > > > > > > > > > > > > is equivalent to the DNS TTL value. A DDoS > > > > > > > > > > > > > > mitigation provider with multiple DOTS servers > > > > > > > > > > > > > > typically re-directs a DOTS client to a > > > > > > > > > > > > > > different DOTS server only if the alternate > > > > > > > > > > > > > > DOTS server has the capacity to handle the > > > > > > > > > > > > > > requests from the > > > > > > > > > > > > > DOTS client. > > > > > > > > > > > > > > > > > > > > > > > > > > > > We can add the following lines to avoid loops : > > > > > > > > > > > > > > > > > > > > > > > > > > > > If the DOTS client has been redirected to a > > > > > > > > > > > > > > DOTS server to which it has already sent the > > > > > > > > > > > > > > mitigation request within the last five > > > > > > > > > > > > > > minutes, it MUST ignore the redirection and > > > > > > > > > > > > > > try reaching others servers listed in the > > > > > > > > > > > > > > local configuration or discovered using > > > > > > > > > > > > > > dynamic means > > > > > > such as DHCP or SRV procedures. > > > > > > > > > > > > > > This prevents infinite ping-ponging between > > > > > > > > > > > > > > servers in case of redirection loops. > > > > > > > > > > > > > > > > > > > > > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > > From: Dots [mailto:dots-bounces@ietf.org] On > > > > > > > > > > > > > > > Behalf Of Jon Shallow > > > > > > > > > > > > > > > Sent: Wednesday, April 4, 2018 8:16 PM > > > > > > > > > > > > > > > To: mohamed.boucadair@orange.com; > > > > > > > > > > > > > > > dots@ietf.org > > > > > > > > > > > > > > > Subject: Re: [Dots] Signal Channel - 300 > > > > > > > > > > > > > > > Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi there, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > See inline [Jon] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > > From: Dots [mailto: dots-bounces@ietf.org] > > > > > > > > > > > > > > > On Behalf Of mohamed.boucadair@orange.com > > > > > > > > > > > > > > > Sent: 04 April 2018 15:07 > > > > > > > > > > > > > > > To: Jon Shallow; dots@ietf.org > > > > > > > > > > > > > > > Subject: Re: [Dots] Signal Channel - 300 > > > > > > > > > > > > > > > Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Re-, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please see inline. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > Med > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Dots > > > > > > > > > > > > > > > > [mailto:dots-bounces@ietf.org] De la part > > > > > > > > > > > > > > > > de Jon Shallow Envoy=E9=A0: mercredi 4 avri= l 2018 > 15:31 =C0=A0: > > > > > > > > > > > > > > > > dots@ietf.org > > > > > > > > > > Objet=A0: > > > > > > > > > > > > > > > > [Dots] Signal Channel - 300 Redirected > > > > > > > > > > > > > > > > Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi there, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have implemented the 300 > > > > > > > > > > > > > > > > Redirected-Signal in my DOTS > > > > > > > code. > > > > > > > > > > > > > > > > This then raises some questions about > usability. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Usability #1 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Architecture 3.2.2 Redirected Signalling > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 4. Having redirected the DOTS client, > > > > > > > > > > > > > > > > DOTS server A ceases > > > > > > > > > > > > sending > > > > > > > > > > > > > > > > server signals. The DOTS client > > > > > > > > > > > > > > > > likewise stops sending > > > > > > > > > > client > > > > > > > > > > > > > > > > signals to DOTS server A. DOTS > > > > > > > > > > > > > > > > session 1 is > > > > > > > > terminated. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Clearly indicates that the original > > > > > > > > > > > > > > > > session (Client to Server > > > > > > > > > > > > > > > > A) is no more once redirected and only > > > > > > > > > > > > > > > > Client to Server B is in > > > > > > > > > > use. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > How is the traffic redirected back to > > > > > > > > > > > > > > > > Server A once maintenance / overloading etc= . > has finished? > > > > > > > > > > > > > > > > My assumption is that Server B sends a > > > > > > > > > > > > > > > > redirect to go back to Server A as Server > > > > > > > > > > > > > > > > A has no way to say over a now > > > > > > > > > > > > > > > > non-existent session to say > > > > > > > > > > > "come back". > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [Med] That's one possibility. This one does > > > > > > > > > > > > > > > not require any update to the > > > > > > > > > > > > > > signal- > > > > > > > > > > > > > > > channel specification. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Another approach would be to not require any > > > > > > > > > > > > > > > redirect signal from server > > > > > > > > > > > > > B. > > > > > > > > > > > > > > > The client will remove server B's records > > > > > > > > > > > > > > > upon the expiry of the TTL and > > > > > > > > > > > > > > will fall > > > > > > > > > > > > > > > back to the "base" DOTS servers > > > > > > > > > > > > > > > configuration that was provisioned to the > > > > > > > > > > > > > > client > > > > > > > > > > > > > > > using DHCP or whatever mechanism. > > > > > > > > > > > > > > > [Jon] OK. The TTL is defined at, > > > > > > > > > > > > > > > associated with the IP address level > > > > > > > > > > > > > > under alt- > > > > > > > > > > > > > > > server-record, not under > > > > > > > > > > > > > > > ietf-dots-signal-channel:redirected-signal. > The ttl > > > > > > > > definition is > > > > > > > > > > > > > > > ambiguous as to what it refers to and > > > > > > > > > > > > > > > perhaps could be tightened up in the > > > > > > > > > > > > > > > language (I read it as being associated with > > > > > > > > > > > > > > > "addr" in the sense of a DNS > > > > > > > > > > > > > > TTL). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Do we need to keep the existing Client to > > > > > > > > > > > > > > > > Server A session warm (or perhaps to probe > > > > > > > > > > > > > > > > periodically) to see if Server A is > > > > > > > > > > > > > > > > capable of handling the Client again by a > > > > > > > > > > > > > > > > server response extension to the protocol > > > > > > > > > > > > > > > > (e.g. a > > > > > > > > > > > > > > > > 3.01) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [Med] Redirect was initially introduced to > > > > > > > > > > > > > > > manage a server overload, so I > > > > > > > > > > > > > > don't > > > > > > > > > > > > > > > think it makes sense to probe or maintain a > > > > > > > > > > > > > > > session with > > > > > > > server > > > > > > > > A. > > > > > > > > > > > > > > > [Jon] Agreed, but I needed to raise the > question. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Should there be a retry period parameter > > > > > > > > > > > > > > > > added in to the > > > > > > > > > > > > > > > > 3.00 protocol (as I read it, ttl only > > > > > > > > > > > > > > > > refers to the IP > > > > > > > > address)? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [Med] The client will automatically switch > > > > > > > > > > > > > > > to Server A when all alternate > > > > > > > > > > > > > > records > > > > > > > > > > > > > > > expire. > > > > > > > > > > > > > > > [Jon] OK - again the 4.6 text needs to get > > > > > > > > > > > > > > > tightened up to reflect this as > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > intent. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Usability #2 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Server A says "Redirect to Server B" due > > > > > > > > > > > > > > > > to > > > > > overloading. > > > > > > > > > > > > > > > > Server B accepts things for a while and > > > > > > > > > > > > > > > > then is instructed/decides to redirect traf= fic > back to A. > > > > > > > > > > > > > > > > Server A is left still overload configured > > > > > > > > > > > > > > > > to redirect to B. How should the client > > > > > > > > > > > > > > > > handle this as there is no suitable > > > > > > > > > > > > > > > Server? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [Med] This is a service configuration problem= . > > > > > > > > > > > > > > > We may > > > > > ask: > > > > > > > > > > > > > > > * the client to log the error and notify the > > > > > > administrator. > > > > > > > > > > > > > > > * and/or stop the redirection after n cycles. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Still, this does not solve the problem. > > > > > > > > > > > > > > > [Jon] Agreed there is a problem here > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I agree that there needs to be > > > > > > > > > > > > > > > > co-ordination between Server A and Server > > > > > > > > > > > > > > > > B, but user error may > > > > > creep in. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Usability #3 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Server A says "Redirect to Server B" as it > > > > > > > > > > > > > > > > going to be shut down because of > > > > > > > > > > > > > > > > maintenance. Server B accepts things for > > > > > > > > > > > > > > > > a while and then is instructed (in > > > > > > > > > > > > > > > > probable user > > > > > > > > > > > > > > > > error) to redirect traffic back to A > > > > > > > > > > > > > > > > (perhaps because it has hit an overload > > > > > > > > > > > > > > > > condition). How should the client > > > > > > > > > > > > > > > handle this? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [Med] Isn't this a sub-case or #2? > > > > > > > > > > > > > > > [Jon] Yes, but I wanted to bring in Server A > > > > > > > > > > > > > > > being alive and able to > > > > > > > > > > > > > > respond > > > > > > > > > > > > > > > versus Server A down and not responding due > > > > > > > > > > > > > > > to > > > > > > maintenance. > > > > > > > > > > > > > > > [Jon] With my better understanding of TTL we > > > > > > > > > > > > > > > still have an issue if the TTL expires and > > > > > > > > > > > > > > > Server A is having an extended > > > > > > > > outage. > > > > > > > > > > > > > > > How do we recover from that? > > > > > > > > > > > > > > > ~jon > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > __________________________________________ > > > > > > > > > > > > > > > > __ ___ Dots mailing list Dots@ietf.org > > > > > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ____________________________________________ > > > > > > > > > > > > > > > __ _ Dots mailing list Dots@ietf.org > > > > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ____________________________________________ > > > > > > > > > > > > > > > __ _ Dots mailing list Dots@ietf.org > > > > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > Dots mailing list Dots@ietf.org > > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > Dots mailing list > > > > > > > > > > > Dots@ietf.org > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Dots mailing list > > > > > > > > Dots@ietf.org > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Dots mailing list > > > > > > > Dots@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Dots mailing list > > > > > Dots@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > _______________________________________________ > > > > Dots mailing list > > > > Dots@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > _______________________________________________ > > > > Dots mailing list > > > > Dots@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Mon Apr 9 02:25:14 2018 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 E3548126C26 for ; Mon, 9 Apr 2018 02:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MkldO0EwORnL for ; Mon, 9 Apr 2018 02:25:09 -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 34E4F127698 for ; Mon, 9 Apr 2018 02:25:09 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.90_1) (envelope-from ) id 1f5T2x-0003R4-Cn; Mon, 09 Apr 2018 10:25:07 +0100 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , , References: <008401d3c4fd$216d0840$644718c0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF1067@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <014801d3c5b7$94c67f00$be537d00$@jpshallow.com> <009a01d3cdab$150b4c40$3f21e4c0$@jpshallow.com> <00cf01d3cdbe$24876650$6d9632f0$@jpshallow.com> In-Reply-To: Date: Mon, 9 Apr 2018 10:25:08 +0100 Message-ID: <01fd01d3cfe4$a71b6580$f5523080$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01FE_01D3CFED.08E28CA0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGlexwLZckIYJuvKwEmwuQr1rXL6AKpdMHOAgMRKpIBsBKRFgKXgqsdAxHSSssB/GODugGyw551AT90vc+jylNrAA== Content-Language: en-gb Archived-At: Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 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, 09 Apr 2018 09:25:13 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01FE_01D3CFED.08E28CA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Tiru, =20 If a DOTS client knows the full scope of the Networks that it is allowed = to use in a ACL or mitigate request, and the DOTS server limits any update = from that client to the scope of Networks (with any unexpected side effects = that may have), then there is no difference in my mind as to whether the DOTS clients fills in the destination-network, or the DOTS server does so on = the DOTS client=92s behalf before ACL instantiation if destination-network = is not defined. =20 For a client behind a client domain DOTS gateway, there may be non = public IP addresses that the (DMS) client is responsible for, but these should = never be sent out through the DOTS gateway (and should be rejected by the DOTS server as out of scope). There does have to be a common agreement = between DOTS client & DOTS server as to what Networks are in scope, but the DOTS client currently cannot request this from the DOTS server and has to be agreed out of band. =20 There is no reason as to why the DOTS server cannot maintain a valid = scope of Networks that the client domain DOTS gateway is allowed to request = for validity checking =96 unless I am missing something? =20 Troubleshooting has kept me in a job for more years than I care to = remember, anything to aid troubleshooting is what I am interested in and so = totally agree that rogue DOTS client=92s capabilities need to be kept under = control with suitable logging to aid diagnosis is a major plus. However in this case, the implicit rule is no different to the DOTS client requesting = the full Networks scope in an ACL request. =20 Regards =20 Jon =20 From: Konda, Tirumaleswar Reddy [mailto: = TirumaleswarReddy_Konda@mcafee.com] Sent: 07 April 2018 06:48 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 =20 Hi Jon, =20 DOTS clients (intelligent DDoS mitigation system, application server) = will know the destination networks, what kind of DOTS clients will not know = the destination networks they are allowed to use ? DOTS clients could be behind client-domain DOTS gateway, DOTS server = will have no way to validate the DOTS client identity sending the ACE request = to determine the destination IP addresses in its scope, it will only know = the destination IP addresses in the DOTS client domain scope.=20 Further, the implicit rule can be misused by compromised DOTS clients = (e.g. black-list good traffic to the entire DOTS client domain) and it=92s a troubleshooting nightmare to find the culprit device adversely impacting = the entire network. =20 Cheers, -Tiru =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Friday, April 6, 2018 9:14 PM To: Konda, Tirumaleswar Reddy ; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 =20 Hi Tiru, =20 The DOTS server is likely to have a scope of IP addresses that are valid = for the client to ask for protection for based on the cuid or cdid. =20 The DOTS client may have some knowledge of the scope IPs by some out of = band method, but programmatically cannot ask the server what they are.=20 =20 If a client specifies a destination network that is out of the valid = scope of IP addresses, then the ACE request will get rejected. The client may then have a challenge to work out what destination networks it is = allowed to use. =20 How does a client set up a blacklist for all the IPS within his allowed scope if it does not know what the scope is? =20 If the client has not provided a destination network, then the DOTS = server can auto-fill in the missing information at the time of the ACE instantiation =96 and this then handles if the scope of IP addresses = change. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 06 April 2018 16:19 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 =20 I don=92t understand how the DOTS server/mitigation will fill it in at = time of ACE instantiation, and why can=92t the DOTS client fill the destination network details ? =20 -Tiru =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Friday, April 6, 2018 6:58 PM To: Konda, Tirumaleswar Reddy ; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 =20 Hi there, =20 There is no current way to request of a DOTS Server as to what is the = set of IP networks that a DOTS client can use either within a mitigation = request or to set up an ACL other than by =93testing for ok or not ok=94 with lots = of different IP addresses. =20 There is a reasonable likelihood of the scope of valid IPs from the = Server=92s perspective will change over time. So, unless a DOTS client wants to control a specific destination network, then my suggestion would be to = leave the ACE destination network empty and for the DOTS Server / DOTS = mitigator (how is out of scope) to fill it in at time of ACE instantiation. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 27 March 2018 13:49 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 =20 Please see inline [TR] =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Tuesday, March 27, 2018 4:07 PM To: Konda, Tirumaleswar Reddy ; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 =20 Hi Tiru / Med =20 See inline [Jon] =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 27 March 2018 09:47 To: mohamed.boucadair@orange.com; Jon Shallow; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 =20 I also support to mandate destination-network for immediately enforced filtering rules. [Jon] This can be enforced / inserted by the DOTS Server for all the destination networks of the domain that the DOTS client =91belongs=92 = to. That said, it would be good to always have the destination network in an ACL = as it can be validated and cross-checked whenever the legitimate set of = domain protected IPs are updated. [Jon] However, what happens to the Destination network in the case of a = call home DOTS client that becomes a quasi DOTS server and the Destination networks are somewhere out on the Internet? =20 [TR] DDOS is a targeted attack, so the DOTS client can specify the destination network targeted by devices in the DOTS server domain and = the DOTS server can validate if the destination network is indeed targeted = by its devices. =20 -Tiru =20 From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed...boucadair@orange.com =20 Sent: Tuesday, March 27, 2018 1:09 PM To: Jon Shallow ; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 =20 Hi Jon,=20 =20 Thank you for the comments. =20 Please see inline. =20 Cheers, Med =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : lundi 26 mars 2018 14:23 =C0 : dots@ietf.org Objet : [Dots] IETF 101 Presentation Data Channel Issue #4 =20 Hi there, =20 As per Med=92s presentation to the IETF 101 =20 Issue #4: Per-Domain or Per-client Filters? =20 =95 Conclusion =96 Filters that are activated only during mitigation time are on a = per-client basis =95 Filters are per-domain when are immediately applied =20 =93Filters are per-domain when are immediately applied=94 is what I have = an challenge with. =20 If we have a compromised or rogue DOTS client, the simple use of = something like curl, along with the client certificates etc. can be used to = generate any ACL with activation-type :=3D =91immediate=92 which is then = immediately applied for all traffic within the domain as per the above. =20 [Med] Yes. FWIW, this attack is called out in the security = considerations section:=20 =20 =93Nevertheless, an attacker who can access a DOTS client is technically capable of launching various attacks, such as: =20 ..; =20 o Set invalid ACL entries, which may prevent legitimate traffic from being forwarded. Likewise, invalid ACL entries may lead to forward DDoS traffic. =93 [Jon] Agreed that the attack is covered off in the Security section, but = we should be limiting the possibility / scope of the attack vector by = enforcing some rules as to what is / is not allowed. Allowing a DOTS client to be able to affect all the traffic within the domain is a huge risk to me = and should not be allowed. =20 So, a ACL that blacklists the DNS server, or drops all port 443 traffic = etc. can easily cause all of the other clients / devices within the domain to = be taken off air. Putting the intelligence into the DOTS server to not = allow this to happen could be a challenge. [The signal channel is much harder to compromise and affect traffic = flows to other areas within the domain] =20 I believe that an ACL instantiated by a DOTS client (immediate or when-mitigating) should only apply to the DOTS client=92s traffic which = means that the destination-network has to be a part of the ACL, whether = implicitly added by the DOTS server, or by the DOTS client and suitably validated. =20 [Med] Putting aside that I don=92t parse =93DOTS client=92s traffic=94, [Jon] I was referring to all the traffic flows that a DOTS client can legitimately request control of to the DOTS server that are within the = scope of what the DOTS client is protecting (which may or may not be the DOTS client=92s IP address). I interpret your answer as a support to this question raised for issue = #4: * =93Should we mandate destination-network to be present for immediately enforced filters?=94 [Jon] See response to Tiru=92s Agreement above. ~Jon There is nothing to stop the DOTS server or DOTS mitigator merging = common ACLs to reduce the number of ACLs within the mitigation device. =20 As a side note =93mitigation-time=94 is perhaps a bad name as it implies = a time period =96 something like =93when-mitigating=94 to me is clearer. [Med] Fixed in my local copy. Thank you. =20 Regards =20 Jon ------=_NextPart_000_01FE_01D3CFED.08E28CA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

If a DOTS client knows = the full scope of the Networks that it is allowed to use in a ACL or = mitigate request, and the DOTS server limits any update from that client = to the scope of Networks (with any unexpected side effects that may = have), then there is no difference in my mind as to whether the DOTS = clients fills in the destination-network, or the DOTS server does so on = the DOTS client’s behalf before ACL instantiation if = destination-network is not defined.

 

For a client behind a = client domain DOTS gateway, there may be non public IP addresses that = the (DMS) client is responsible for, but these should never be sent out = through the DOTS gateway (and should be rejected by the DOTS server as = out of scope).=A0 There does have to be a common agreement between DOTS = client & DOTS server as to what Networks are in scope, but the DOTS = client currently cannot request this from the DOTS server and has to be = agreed out of band.

 

There is no reason as to = why the DOTS server cannot maintain a valid scope of Networks that the = client domain DOTS gateway is allowed to request for validity checking = – unless I am missing something?

 

Troubleshooting has kept = me in a job for more years than I care to remember, anything to aid = troubleshooting is what I am interested in and so totally agree that = rogue DOTS client’s capabilities need to be kept under control = with suitable logging to aid diagnosis is a major plus.=A0 However in = this case, the implicit rule is no different to the DOTS client = requesting the full Networks scope in an ACL = request.

 

Regards

 

Jon

 

From: Konda, Tirumaleswar Reddy [mailto: = TirumaleswarReddy_Konda@mcafee.com]
Sent: 07 April 2018 = 06:48
To: Jon Shallow; mohamed.boucadair@orange.com; = dots@ietf.org
Subject: RE: [Dots] IETF 101 Presentation Data = Channel Issue #4

 

Hi = Jon,

 

DOTS clients (intelligent DDoS = mitigation system, application server) will know the destination = networks, what kind of DOTS clients will not know the destination = networks they are allowed to use ?

DOTS clients could be behind = client-domain DOTS gateway, DOTS server will have no way to validate the = DOTS client identity sending the ACE request to determine the = destination IP addresses in its scope, it will only know the destination = IP addresses in the DOTS client domain scope.

Further, the implicit rule can be = misused by compromised DOTS clients (e.g. black-list good traffic to the = entire DOTS client domain) and it’s a  troubleshooting = nightmare to find the culprit device adversely impacting the entire = network.

 

Cheers,

-Tiru

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Friday, April 6, 2018 9:14 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: RE: = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

Hi Tiru,

 

The DOTS server is = likely to have a scope of IP addresses that are valid for the client to = ask for protection for based on the cuid or = cdid.

 

The DOTS client may have = some knowledge of the scope IPs by some out of band method, but = programmatically cannot ask the server what they are. =

 

If a client specifies a = destination network that is out of the valid scope of IP addresses, then = the ACE request will get rejected.  The client may then have a = challenge to work out what destination networks it is allowed to = use.

 

How does a client set up = a blacklist for all the IPS within his allowed scope if it does not know = what the scope is?

 

If the client has not = provided a destination network, then the DOTS server can auto-fill in = the missing information at the time of the ACE instantiation – and = this then handles if the scope of IP addresses = change.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 06 April 2018 = 16:19
To: Jon Shallow; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: Re: = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

I don’t = understand how the DOTS server/mitigation will fill it in at time of ACE = instantiation, and why can’t the DOTS client fill the destination = network details ?

 

-Tiru

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Friday, April 6, 2018 6:58 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: RE: = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

Hi there,

 

There is no current way = to request of a DOTS Server as to what is the set of IP networks that a = DOTS client can use either within a mitigation request or to set up an = ACL other than by “testing for ok or not ok” with lots of = different IP addresses.

 

There is a reasonable = likelihood of the scope of valid IPs from the Server’s perspective = will change over time.  So, unless a DOTS client wants to control a = specific destination network, then my suggestion would be to leave the = ACE destination network empty and for the DOTS Server / DOTS mitigator = (how is out of scope) to fill it in at time of ACE = instantiation.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 27 March 2018 = 13:49
To: Jon Shallow; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: Re: = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

Please see inline = [TR]

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Tuesday, March 27, 2018 4:07 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: RE: = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

Hi Tiru / Med

 

See inline = [Jon]

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 27 March 2018 = 09:47
To: mohamed.boucadair@orange.com= ; Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

I also support to = mandate destination-network for immediately enforced filtering = rules.

[Jon] This can be = enforced / inserted by the DOTS Server for all the destination networks = of the domain that the DOTS client ‘belongs’ to.  That = said, it would be good to always have the destination network in an ACL = as it can be validated and cross-checked whenever the legitimate set of = domain protected IPs are updated.

[Jon] However, what = happens to the Destination network in the case of a call home DOTS = client that becomes a quasi DOTS server and the Destination networks are = somewhere out on the Internet?

 

[TR] DDOS is a targeted attack, so = the DOTS client can specify the destination network targeted by devices = in the DOTS server domain and the DOTS server can validate if the = destination network is indeed targeted by its = devices.

 

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of mohamed...boucadair@orange.c= om
Sent: Tuesday, March 27, 2018 1:09 PM
To: Jon = Shallow <supjps-ietf@jpshallow.com&g= t;; dots@ietf.org
Subject: Re: = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

Hi Jon,

 

Thank you for the comments.

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] = De la part de Jon Shallow
Envoy=E9 : lundi 26 mars = 2018 14:23
=C0 : dots@ietf.org
Objet : = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

Hi = there,

 

As per Med’s presentation to the IETF = 101

 

Issue #4: Per-Domain or Per-client = Filters?

 

• Conclusion

– Filters that are activated only during = mitigation time are on a per-client basis

   • Filters are per-domain when are = immediately applied

 

“Filters are per-domain when are immediately = applied” is what I have an challenge with.

 

If we have a = compromised or rogue DOTS client, the simple use of something like curl, = along with the client certificates etc. can be used to generate any ACL = with activation-type :=3D ‘immediate’ which is then = immediately applied for all traffic within the domain as per the = above.

 

[Med] = Yes. FWIW, this attack is called out in the security considerations = section:

 

“Nevertheless, =
an

   attacker who can access a = DOTS client is technically capable of

   launching various attacks, = such as:

 

..;

 

   o  Set invalid ACL entries, which may =
prevent legitimate traffic from
      being forwarded.  =
Likewise, invalid ACL entries may lead =
to
      forward DDoS traffic.

“

[Jon] Agreed that the = attack is covered off in the Security section, but we should be limiting = the possibility / scope of the attack vector by enforcing some rules as = to what is / is not allowed.  Allowing a DOTS client to be able to = affect all the traffic within the domain is a huge risk to me and should = not be allowed.

 

So, a ACL = that blacklists the DNS server, or drops all port 443 traffic etc. can = easily cause all of the other clients / devices within the domain to be = taken off air.  Putting the intelligence into the DOTS server to = not allow this to happen could be a challenge.

[The signal channel is much harder to compromise and = affect traffic flows to other areas within the domain]

 

I believe = that an ACL instantiated by a DOTS client (immediate or when-mitigating) = should only apply to the DOTS client’s traffic which means that = the destination-network has to be a part of the ACL, whether implicitly = added by the DOTS server, or by the DOTS client and suitably = validated.

 

[Med] = Putting aside that I don’t parse “DOTS client’s = traffic”,

[Jon] I was referring to all the traffic flows = that a DOTS client can legitimately request control of to the DOTS = server that are within the scope of what the DOTS client is protecting = (which may or may not be the DOTS client’s IP = address).

I = interpret your answer as a support to this question raised for issue = #4:

    • “Should = we mandate destination-network to be present for immediately enforced = filters?”

[Jon] See response to = Tiru’s Agreement above.

~Jon

There is nothing to stop the DOTS server or DOTS = mitigator merging common ACLs to reduce the number of ACLs within the = mitigation device.

 

As a side = note “mitigation-time” is perhaps a bad name as it implies a = time period – something like “when-mitigating” to me = is clearer.

[Med] = Fixed in my local copy. Thank you.

 

Regards

 

Jon

<= /body> ------=_NextPart_000_01FE_01D3CFED.08E28CA0-- From nobody Mon Apr 9 02:45:35 2018 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 167C7124207 for ; Mon, 9 Apr 2018 02:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSbSS0Qw0or7 for ; Mon, 9 Apr 2018 02:45:29 -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 8494B127775 for ; Mon, 9 Apr 2018 02:45:18 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.90_1) (envelope-from ) id 1f5TMS-0003Rf-MQ; Mon, 09 Apr 2018 10:45:16 +0100 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , , References: <016401d3cc1c$03321200$09963600$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7F97@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <01a701d3cc29$ba915b10$2fb41130$@jpshallow.com> <007501d3ccc2$b49f0b00$1ddd2100$@jpshallow.com> In-Reply-To: Date: Mon, 9 Apr 2018 10:45:17 +0100 Message-ID: <021301d3cfe7$77e5cbe0$67b163a0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0214_01D3CFEF.D9AD6830" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEYhrWXRSNBek+fWBybzdJS41Z0KAI4GsKdAX18SvQDE9KikwNzyn9FAeCfBHelCyS+YA== Content-Language: en-gb Archived-At: Subject: Re: [Dots] Data Channel ACL fragments 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, 09 Apr 2018 09:45:33 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0214_01D3CFEF.D9AD6830 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Tiru, =20 See inline [Jon1] =20 Regards =20 Jon =20 From: Konda, Tirumaleswar Reddy [mailto: = TirumaleswarReddy_Konda@mcafee.com] Sent: 07 April 2018 07:55 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] Data Channel ACL fragments =20 Hi Jon, =20 Please see inline [TR] =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Thursday, April 5, 2018 3:15 PM To: Konda, Tirumaleswar Reddy ; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] Data Channel ACL fragments =20 Hi Tiru, =20 Actually no, as there is a disconnect between the Cisco document and = what we have currently got set up. =20 The Cisco Document refers to ACL, which is an ACE in = netmod-acl-model/DOTS speak. A DOTS ACL can be a list of separate matching ACEs. =20 With netmod-acl, we have layer 3 definitions and then separately layer 4 definitions =96 there is now no concept of L3+L4 within the same ACE. =20 So, the Cisco statement =93Note: When there is both Layer 3 and Layer 4 information in the ACL line and the fragments keyword is present=94 will = never be true for an ACE entry. =20 [TR] No, as per the ACE definition in draft-ietf-netmod-acl-model-16, = The choice statements within the match container allow for selection of one header within each of "l2", "l3", or "l4" headers.=20 It is possible to specify both L3 and L4 information in the ACE (each = ACE has a group of match criteria). =20 [Jon1] =96 My bad =96 I was reading =93Choice=94 as choosing L3 or L4, = not that the choice was referring to the sub-elements within the choice. So, yes, L3 = + L4 are supported. =20 ---- =20 I still do not understand from the Cisco Document how you can build a = set of ACLs that say (but I may be missing something) =93All traffic to port 53 is allowed unless it is fragmented, in which = case all fragments are to be dropped=94 =20 I can create a set of ACLs that say =93All traffic to port 53 is allowed unless it is fragmented, in which = case all non-initial fragments are to be dropped=94 Which does set things up for a DoS of the target with all the initial fragments waiting re-assembly. =20 [TR] The don=92t think a ACL should blindly drop all fragmented packets, fragmentation may or may not happen because of a DoS attack. Do vendors currently support what you are asking ? =20 [Jon1] If (IP_MF | IP_OFFMASK) is set in frag_off (linux) in an IPv4 = packet, then the packet is a part of a fragmented packet sequence. Dropping any packets with (IP_MF | IP_OFFMASK) !=3D 0 will safely drop all the = fragmented packets. This then protects the target=92s IP reassembly logic=92s RAM = usage. Similarly, for IPv6 there is the detection of protocol 44. =20 [Jon1] NCC=92s mitigation appliances can disable fragmented packets = either manually or when there is an ongoing fragmentation attack where the = complete set of fragments for a packet are not seen. =20 [Jon1] I still question as to whether we should be using netmod-acl=92s version of fragmentation instead of using a DOTS extension. =20 ~jon1 =20 -Tiru =20 ---- =20 Which then gets more complicated to construct something when we can only = do either L3 or L4 matching on a per ACE. =20 Regards =20 Jon =20 From: Dots [ mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 05 April 2018 09:23 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] Data Channel ACL fragments =20 Hi Jon, =20 The fragment definition to protect the target from attacks that use non-initial fragments only. We followed the Security considerations for IP filtering given in = Section 2 of https://www.ietf.org/rfc/rfc1858.txt to drop the initial fragment, so = the non-initial fragments will be discarded by the destination host (its implemented and discussed in https://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulati= on- gre/8014-acl-wp.html). =20 -Tiru =20 From: Dots [ = mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Wednesday, April 4, 2018 9:00 PM To: mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] Data Channel ACL fragments =20 Hi Med et all, =20 See inline [Jon] =20 Regards =20 Jon =20 From: Dots [mailto: = dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 04 April 2018 15:27 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Data Channel ACL fragments =20 Re-, =20 I guess we do still need this because we wanted to achieve this functionality (especially for the non-initial fragments): =20 =3D=3D This document supports fragment filtering which adds an additional layer of protection against a DoS attack that uses non-initial fragments only. When there is only layer 3 information in the ACL entry and the fragments keyword is present, for non-initial fragments matching the ACE entry, the 'deny' or 'accept' action associated with the ACE entry will be enforced. For initial or non-fragment matching the ACE entry, the next ACE entry will be processed. When there is both layer 3 and layer 4 information in the ACE entry and the fragments keyword is present, the ACE action is conservative for both 'accept' and 'deny' actions. The actions are conservative to not accidentally deny a fragmented portion of a flow because the fragments do not contain sufficient information to match all of the filter attributes. In the 'deny' action case, instead of denying a non-initial fragment, the next ACE entry is processed. In the 'accept' case, it is assumed that the layer 4 information in the non- initial fragment, if available, matches the layer 4 information in the ACE entry. =3D=3D =20 [Jon] Actually, as I read the text above, if the additional layer of protection is required against fragmented attacks and v-[46]-fragment is = set with action =93drop=94, then any non-initial fragment is dropped =96 = fine. =20 However, the initial fragment skips this ACE test and goes onto the next ACE. Assuming that there is a =93accept=94 that matches everything else = (i.e. we like the packet apart from when it is fragmented), then the initial fragment is let through. =20 The target IP then consumes lots of RAM whilst waiting for the missing fragment segments=85=85..D(D)oS Success. =20 There is no way to drop the initial fragment with the above text other = than to =93drop=94 genuine non fragmented traffic as well. I think that = logic is flawed to drop just subsequent fragments. =20 [Jon] I also wonder how the above is going to get implemented =96 it = would be easier to say any fragmented packet sequence is not allowed (including = the initial packet) rather than only a part of the sequence which then leads = to a DoS in its own rights. =20 No? =20 [Jon] See above. I do agree that flags -> fragment -> 1 is a bit = ambiguous is its definition when used to match a packet as an acl/ace, but I do = think the match intent is that the packet is not fragmented. =20 =20 Cheers, Med =20 De : Dots [ mailto:dots-bounces@ietf.org] = De la part de Jon Shallow Envoy=E9 : mercredi 4 avril 2018 15:51 =C0 : dots@ietf.org Objet : [Dots] Data Channel ACL fragments =20 Hi there, =20 Do we still need to have the fragment definition for ACEs in the data channel? =20 draft-ietf-netmod-acl-model-18 now supports fragments for ipv4 (flags + options) and implicitly in ipv6 through the next header field protocol = set to 44 (fragment extension header). =20 IPV4 =3D=3D=3D=3D grouping acl-ipv4-header-fields { description "Fields in IPv4 header."; ... leaf flags { type bits { bit reserved { position 0; description "Reserved. Must be zero."; } bit fragment { position 1; description "Setting value to 0 indicates may fragment, while setting the value to 1 indicates do not fragment."; } bit more { position 2; description "Setting the value to 0 indicates this is the last fragment, and setting the value to 1 indicates more fragments are coming."; } } description "Bit definitions for the flags field in IPv4 header."; } =20 leaf offset { type uint16 { range "20..65535"; } description "The fragment offset is measured in units of 8 octets (64 bits). The first fragment has offset zero. The length is 13 bits"; } =20 Regards =20 Jon =20 ------=_NextPart_000_0214_01D3CFEF.D9AD6830 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

See inline = [Jon1]

 

Regards

 

Jon

 

From: Konda, Tirumaleswar Reddy [mailto: = TirumaleswarReddy_Konda@mcafee.com]
Sent: 07 April 2018 = 07:55
To: Jon Shallow; mohamed.boucadair@orange.com; = dots@ietf.org
Subject: RE: [Dots] Data Channel ACL = fragments

 

Hi Jon,

 

Please see inline = [TR]

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Thursday, April 5, 2018 3:15 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: RE: = [Dots] Data Channel ACL fragments

 

Hi = Tiru,

 

Actually no, as there is = a disconnect between the Cisco document and what we have currently got = set up.

 

The Cisco Document = refers to ACL, which is an ACE in netmod-acl-model/DOTS speak.  A = DOTS ACL can be a list of separate matching = ACEs.

 

With netmod-acl, we have = layer 3 definitions and then separately layer 4 definitions – = there is now no concept of L3+L4 within the same = ACE.

 

So, the Cisco statement = “Note: When there is both Layer 3 and Layer 4 information in the = ACL line and the fragments keyword is present” will never be true = for an ACE entry.

 

[TR] No, as per the ACE = definition in draft-ietf-netmod-acl-model-16, The choice statements = within the match container allow for selection of one header within each = of "l2", "l3", or "l4" headers. =

It is possible to specify both L3 and L4 = information in the ACE (each ACE has a group of match = criteria).

 

[Jon1] – My bad = – I was reading “Choice” as choosing L3 or L4, not = that the choice was referring to the sub-elements within the choice.=A0 = So, yes, L3 + L4 are supported.

 

----

 

I still do not = understand from the Cisco Document how you can build a set of ACLs that = say (but I may be missing something)

“All traffic to = port 53 is allowed unless it is fragmented, in which case all fragments = are to be dropped”

 

I can create a set of = ACLs that say

“All traffic to port 53 is allowed unless = it is fragmented, in which case all non-initial fragments are to be = dropped”

Which does set things up for a DoS of the target = with all the initial fragments waiting = re-assembly.

 

[TR] The don’t think a ACL should blindly drop all = fragmented packets, fragmentation may or may not happen because of a DoS = attack. Do vendors currently support what you are asking = ?

 

[Jon1] If = (IP_MF | IP_OFFMASK) is set in frag_off (linux) in an IPv4 packet, then = the packet is a part of a fragmented packet sequence.=A0 Dropping any = packets with (IP_MF | IP_OFFMASK) !=3D 0 will safely drop all the = fragmented packets.=A0 This then protects the target’s IP = reassembly logic’s RAM usage.=A0=A0 Similarly, for IPv6 there is = the detection of protocol 44.

 

[Jon1] = NCC’s mitigation appliances can disable fragmented packets either = manually or when there is an ongoing fragmentation attack where the = complete set of fragments for a packet are not = seen.

 

[Jon1] I = still question as to whether we should be using netmod-acl’s = version of fragmentation instead of using a DOTS = extension.

 

~jon1

 

-Tiru

 

----

 

Which then gets more = complicated to construct something when we can only do either L3 or L4 = matching on a per ACE.

 

Regards

 

Jon

 

From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org= ] On Behalf Of Konda, Tirumaleswar = Reddy
Sent: 05 April 2018 09:23
To: Jon Shallow; = mohamed.boucadair@orange.com; dots@ietf.org
Subject: Re: [Dots] Data Channel ACL = fragments

 

Hi = Jon,

 

The fragment definition to protect = the target from attacks that use non-initial fragments = only.

We followed the Security = considerations for IP filtering given in Section 2 of https://www.ietf.org/rfc/rfc1858.txt= to drop the initial fragment, so = the non-initial fragments will be discarded by the destination host (its = implemented and discussed in https://www.cisco.com/c/en/us/suppor= t/docs/ip/generic-routing-encapsulation-gre/8014-acl-wp.html).

 

-Tiru

 

 

Hi Med et all,

 

See inline = [Jon]

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com
Sent: 04 April 2018 15:27
To: Jon = Shallow; dots@ietf.org
Subject: Re: [Dots] Data Channel ACL = fragments

 

Re-,

 

I guess we do still need this because we wanted to = achieve this functionality (especially for the non-initial = fragments):

 

=3D=3D

   This document supports = fragment filtering which adds an additional

   layer of protection against a = DoS attack that uses non-initial

   fragments only.  When = there is only layer 3 information in the ACL

   entry and the fragments = keyword is present, for non-initial fragments

   matching the ACE entry, the = 'deny' or 'accept' action associated with

   the ACE entry will be = enforced.  For initial or non-fragment = matching

   the ACE entry, the next ACE = entry will be processed.  When there is

   both layer 3 and layer 4 = information in the ACE entry and the

   fragments keyword is present, = the ACE action is conservative for both

   'accept' and 'deny' = actions.  The actions are conservative to = not

   accidentally deny a = fragmented portion of a flow because the

   fragments do not contain = sufficient information to match all of the

   filter attributes.  In = the 'deny' action case, instead of denying a

   non-initial fragment, the = next ACE entry is processed.  In the

   'accept' case, it is assumed = that the layer 4 information in the non-

   initial fragment, if = available, matches the layer 4 information in

   the ACE = entry.

=3D=3D

 

[Jon] = Actually, as I read the text above, if the additional layer of = protection is required against fragmented attacks and v-[46]-fragment is = set with action “drop”, then any non-initial fragment is = dropped – fine.

 

However, = the initial fragment skips this ACE test and goes onto the next = ACE.  Assuming that there is a “accept” that matches = everything else (i.e. we like the packet apart from when it is = fragmented), then the initial fragment is let = through.

 

The target = IP then consumes lots of RAM whilst waiting for the missing fragment = segments……..D(D)oS Success.

 

There is no = way to drop the initial fragment with the above text other than to = “drop” genuine non fragmented traffic as well.  I think = that logic is flawed to drop just subsequent = fragments.

 

[Jon] I = also wonder how the above is going to get implemented – it would = be easier to say any fragmented packet sequence is not allowed = (including the initial packet) rather than only a part of the sequence = which then leads to a DoS in its own rights.

 

No?

 

[Jon] See = above.  I do agree that flags -> fragment -> 1 is a bit = ambiguous is its definition when used to match a packet as an acl/ace, = but I do think the match intent is that the packet is not = fragmented.

 

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow
Envoy=E9 : = mercredi 4 avril 2018 15:51
=C0 : dots@ietf.org
Objet : [Dots] Data Channel ACL = fragments

 

Hi = there,

 

Do we still need to have the fragment definition for = ACEs in the data channel?

 

draft-ietf-netmod-acl-model-18 now supports fragments = for ipv4 (flags + options) and implicitly in ipv6 through the next = header field protocol set to 44 (fragment extension = header).

 

IPV4

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

  = grouping acl-ipv4-header-fields {

    description

      "Fields in IPv4 = header.";

...

    leaf flags {

      type bits = {

        bit = reserved {

          = position 0;

          = description

         &= nbsp;  "Reserved. Must be zero.";

        = }

        bit = fragment {

          = position 1;

          = description

         &= nbsp;  "Setting value to 0 indicates may fragment, while = setting

         &= nbsp;   the value to 1 indicates do not = fragment.";

        = }

        bit more = {

          = position 2;

          = description

         &= nbsp;  "Setting the value to 0 indicates this is the last = fragment,

         &= nbsp;   and setting the value to 1 indicates more fragments = are

         &= nbsp;   coming.";

        = }

      = }

      = description

        "Bit = definitions for the flags field in IPv4 header.";

    }

 

    leaf offset {

      type uint16 = {

   =      range = "20..65535";

      }

      = description

        "The = fragment offset is measured in units of 8 octets (64 = bits).

         The = first fragment has offset zero. The length is 13 = bits";

    = }

 

Regards

 

Jon

 

------=_NextPart_000_0214_01D3CFEF.D9AD6830-- From nobody Mon Apr 9 03:08:56 2018 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 F2495126CC4 for ; Mon, 9 Apr 2018 03:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 R58qgOsDp1XK for ; Mon, 9 Apr 2018 03:08:51 -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 4E1DF124207 for ; Mon, 9 Apr 2018 03:08:51 -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=1523268530; 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: dlp-product:dlp-version:dlp-reaction: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-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-Network-Message-Id: 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 nMuAc1rhZzFYYOqiYrzZwwiiHB0GTQ9zJZzPwyBYp A=; b=OwuT1VTeb1FWAMnucs6bT1SEcq00cS82HTwUupugCs4x YmBwFjZgCT5CBHUUespY5vKxdSy93xT3PJ/O8Q4zv6kSTd6OrM B8jv6VoUSrAM2u6mwbcZzJLHT/nFw6E8FpgeiMYwi1dv896Xc3 XMA8DnROEgdIAgRmFrLPZ/InARs= Received: from DNVEXAPP1N04.corpzone.internalzone.com (unknown [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 16ca_42f5_aee84a2e_6ba1_4e80_8732_e33d939b000a; Mon, 09 Apr 2018 05:08:49 -0500 Received: from DNVEXUSR1N14.corpzone.internalzone.com (10.44.48.87) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 9 Apr 2018 04:08:23 -0600 Received: from DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) by DNVEXUSR1N14.corpzone.internalzone.com (10.44.48.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 9 Apr 2018 04:08:22 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Mon, 9 Apr 2018 04:08:21 -0600 Received: from NAM03-BY2-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.1347.2; Mon, 9 Apr 2018 04:08:20 -0600 Received: from BN6PR16MB1425.namprd16.prod.outlook.com (10.172.207.19) by BN6PR16MB1748.namprd16.prod.outlook.com (10.172.28.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.653.12; Mon, 9 Apr 2018 10:08:18 +0000 Received: from BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d]) by BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d%2]) with mapi id 15.20.0653.015; Mon, 9 Apr 2018 10:08:18 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Signal Channel - 300 Redirected Signaling Thread-Index: AdPMGSyCaQQbv+vLSW+0gkDbU7HOEwAAo7xAAAH7T4AAARdqYAAhoxEAAAGQiwAAAKyNYAAF3e1QACUKCFAAAZEMQAAIeXTgAARcGhAAAoG7gAABGXwAAAAjBIAAAa5ZgAAAiReAAABpmzAAL32aAABWbPEwAAIv/gAAAPiKMAAA7T0AAACbH4AAAR48IA== Date: Mon, 9 Apr 2018 10:08:18 +0000 Message-ID: References: <014f01d3cc19$2e3880e0$8aa982a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7E7B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <019901d3cc23$a93ff8e0$fbbfeaa0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8524@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <004e01d3ccb4$d505e7f0$7f11b7d0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8758@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEF912A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEF93EE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <008501d3cda6$c860d210$59227630$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF951 1@OPEXCLILMA3 . corporate.adroot.infra.ftgroup> <00b001d3cdab$ba8caec0$2fa60c40$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF975C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <00b801d3cdb4$982dc4a0$c8894de0$@jpshallow.com> <015101d3ce74$351393c0$9f3abb40$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEFA190@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <01f501d3cfde$4014ca30$c03e5e90$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEFA2DF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DEFA2DF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR16MB1748; 7:97sTRIf1UNSfvOmzMM7s9BIfm/ltEa9Q1SxA84/LdIXIKFrF7bPRiv17UNxi6TdfAEegaR0vAEC6F7byqo3a8rjGXnvR9/qm1ns6MYy9Ro9wD9pbhUXexikOSNpNshxd+1CExPqkvZw9CsliHbfUaBOD4DyCGzJiSPIZN+5EDdMMS3Tud6ZkHeZpyxwk42kKka8k8oBWcqQ6PZegkSlgpFwqWem9wv1Ho1c1TruM8H5flgQgROcSJ2nKnlTqn14y x-ms-exchange-antispam-srfa-diagnostics: SOS; X-MS-Office365-Filtering-Correlation-Id: 9ad684a3-a550-4130-2ae4-08d59e01d128 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BN6PR16MB1748; x-ms-traffictypediagnostic: BN6PR16MB1748: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(166708455590820)(788757137089)(18271650672692)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231221)(944501327)(52105095)(3002001)(6041310)(20161123564045)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011); SRVR:BN6PR16MB1748; BCL:0; PCL:0; RULEID:; SRVR:BN6PR16MB1748; x-forefront-prvs: 0637FCE711 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39860400002)(39380400002)(366004)(346002)(376002)(51444003)(55784002)(189003)(199004)(32952001)(57704003)(13464003)(53754006)(14454004)(81156014)(72206003)(25786009)(53546011)(966005)(105586002)(74316002)(305945005)(2501003)(80792005)(81166006)(6506007)(33656002)(93886005)(97736004)(8676002)(102836004)(446003)(66066001)(59450400001)(16200700003)(26005)(53946003)(6246003)(186003)(9686003)(5660300001)(6306002)(6436002)(229853002)(7736002)(53936002)(8936002)(3280700002)(2900100001)(99286004)(68736007)(11346002)(6116002)(106356001)(7696005)(2906002)(76176011)(316002)(86362001)(55016002)(110136005)(3846002)(5250100002)(3660700001)(476003)(478600001)(486006)(85282002)(559001)(579004)(569006); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR16MB1748; H:BN6PR16MB1425.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: MAr6qBOwpQT4cYj6lwbo2EyaGxeA6nAC+93oQvuuKqPOyF+HcDSesu+qsC3KOTu6mzter+qPCGfvplRQEnklGK6629Ke2z8gvH3gPZV1gvt6h39qRcDt4UCfgWdKyxn/7iwOYSr4dNBokUspl5PBDSjHsGobTc861VeCCeM0ed1iEq3JmaF4nkXJdlfe4PFcAf0IB95SL4nSGL4sqNNlj9qHKqI2lkP3Das/+jQ58LSbEni2Qspn+LkWXqIqumX7dQIKUt9qzFPHyjKWXedUxkddJvFy5CveouIZOoy4xPbCWzGv+gTWWXBnpqhIfJo4c6Ees2i57NqTiNu6RvgwN+llYqkam8gHupMnaWJ299AYPpNHKI7+ph598+AF1alcez8+uXB893JQFuFdTSVkwnKVggwLa7A1eTAdp6dsEV4= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 9ad684a3-a550-4130-2ae4-08d59e01d128 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2018 10:08:18.2038 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR16MB1748 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 <6259> : inlines <6554> : streams <1783535> : uri <2622443> Archived-At: Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling 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, 09 Apr 2018 10:08:55 -0000 > -----Original Message----- > From: mohamed.boucadair@orange.com > [mailto:mohamed.boucadair@orange.com] > Sent: Monday, April 9, 2018 2:27 PM > To: Jon Shallow ; Konda, Tirumaleswar Reddy > ; dots@ietf.org > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling >=20 > Re-, >=20 > Please see inline. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > Envoy=E9=A0: lundi 9 avril 2018 10:39 > > =C0=A0: 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; > > dots@ietf.org Objet=A0: RE: [Dots] Signal Channel - 300 Redirected > > Signaling > > > > Hi all, > > > > Should 'ttl' actually be 'lifetime' to remove any confusion over whethe= r > > this is DNS TTL usage or not ? >=20 > [Med] we do already have a lifetime in the cbor mapping table. So, I sugg= est to > maintain ttl but focus on its definition to avoid confusion. Agreed. >=20 > > > > Otherwise see inline [Jon] > > > > Regards > > > > Jon > > > > -----Original Message----- > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, > > Tirumaleswar Reddy > > Sent: 09 April 2018 09:23 > > To: mohamed.boucadair@orange.com; Jon Shallow; dots@ietf.org > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > -----Original Message----- > > > From: mohamed.boucadair@orange.com > > > [mailto:mohamed.boucadair@orange.com] > > > Sent: Monday, April 9, 2018 1:15 PM > > > To: Konda, Tirumaleswar Reddy ; > > > Jon Shallow ; dots@ietf.org > > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > Tiru, > > > > > > What about this update ones? > > > > > > =3D=3D=3D=3D=3D=3D=3D > > > ttl: Time to live (TTL) of the alternate DOTS server, represented= as > > > an integer number of seconds. That is, the time interval that = the > > > alternate DOTS server may be cached for use by a DOTS client. > > > > > > A lifetime of negative one (-1) indicates indefinite TTL. This > > > value means that the alternate DOTS server is to be used until = the > > > alternate DOTS server redirects the traffic with another 3.00 > > > response. > > > > > > If no 'ttl' is returned in a redirect response, this is equival= ent > > > to returning a 'ttl' parameter set to '-1'. > > > > Above text looks good. > > > > [Jon] Later in the text, there is reference to a minimum of 5 minutes > > before being able to switch back to the original DOTS server. Don't > > we need to say a 5 minute (300 secs) minimum here? >=20 > [Med] That reference is when explicit redirect signals are involved. Yup. >=20 > > > > > > > > If the alternate DOTS server TTL has expired, the DOTS client M= UST > > > use the DOTS server(s), that was provisioned using means discus= sed > > > in Section 4.1, for creating new requests. > > > > It looks too restrictive, typically the DNS TTL values are short-lived > > (e.g.. few seconds) but the sessions are long-lived. > > Why not replace "for creating new requests" with "for creating new > > DOTS session" ? > > > > [Jon] I think that once the alternate DOTS server's lifetime has > > expired, the DOTS client should try to establish a connection with the > > appropriate "normal" DOTS servers, >=20 > [Med] Bingo. No, DNS TTL lifetime does not mean existing session has to be disconnected= =20 after the TTL expires.=20 -Tiru >=20 > if that fails, continue to use the alternate DOTS > > server, but periodically retry the "normal" servers to try to maintain > > resilience of service. >=20 > [Med] The document does not specify the behavior for selecting among mult= iple > servers. So, this details are out of scope. >=20 > After all, the outage (e.g. maintenance window) of > > the original DOTS server may have to be extended, and being down, > > cannot respond with a 3.00 to instruct DOTS client to stay with the > > alternate DOTS server. > > >=20 > [Med] For such cases, it is safe to return an indefinite TTL + alternate = server to > coordinate the fallback behavior. >=20 > > --Tiru > > > > > > > > This is an optional attribute. > > > =3D=3D=3D > > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De=A0: Konda, Tirumaleswar Reddy > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > Envoy=E9=A0: lundi 9 avril 2018 08:51 > > > > =C0=A0: Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet= =A0: RE: > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > Hi Jon, > > > > > > > > I partially agree with the suggested update. A IP address is > > > > cached until the TTL value expires, the DOTS client need not > > > > disconnect existing sessions after the TTL expires, but after the > > > > TTL expires it must consider the IP address stale and not > > > > establish new (D)TLS sessions. > > > > > > > > Cheers, > > > > -Tiru > > > > > > > > > -----Original Message----- > > > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon > > > > > Shallow > > > > > Sent: Saturday, April 7, 2018 6:58 PM > > > > > To: Konda, Tirumaleswar Reddy > > > > > ; > > > > > mohamed.boucadair@orange.com; dots@ietf.org > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > Hi there, > > > > > > > > > > My suggestion would be to make ttl of -1 'infinite', otherwise > > > > > have a > > > > minimum > > > > > value of 300 seconds. The text could read (including referring > > > > > to the > > > > optional > > > > > etc. to be consistent with the rest of the document:- > > > > > > > > > > alt-server: FQDN of an alternate DOTS server. > > > > > > > > > > This is a required attribute. > > > > > > > > > > alt-server-record: A list of IP addresses of an alternate DOT= S > > > > > server. > > > > > > > > > > This is an optional attribute. > > > > > > > > > > ttl: Time to live (TTL) of the alternate DOTS server, > > > > > represented > > as > > > > > an integer number of seconds. That is, the time interval > > > > > that > > the > > > > > alternate DOTS server may be used by a DOTS client. > > > > > > > > > > The minimum value is '300' seconds, or '-1'. > > > > > > > > > > '-1' means that the alternate DOTS server is to be used > > > > > until the > > > > alternate > > > > > DOTS server redirects the traffic with another 3.00 response. > > > > > There is no TTL expiry. > > > > > > > > > > If no 'ttl' is returned in a redirect response, this is > > equivalent > > > > > to returning a 'ttl' parameter set to '-1'. > > > > > > > > > > If the alternate DOTS server TTL has expired, the DOTS > > > > > client > > MUST > > > > > use the DOTS server(s) that was provisioned using means > > discussed > > > > > in Section 4.1. > > > > > > > > > > This is an optional attribute. > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > Jon > > > > > > > > > > -----Original Message----- > > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, > > > > > Tirumaleswar Reddy > > > > > Sent: 06 April 2018 15:55 > > > > > To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > The below proposed change does not look good to me, its causing > > > > > the DOTS client to ping-pong between multiple DOTS servers > > > > > because of the TTL > > > value. > > > > > The alternate server should serve the DOTS client till there is > > > > > a planned maintenance, if it is getting over-subscribed it > > > > > should re-direct the new > > > > DOTS > > > > > clients to an alternate server and avoid bouncing the existing > > > > > DOTS clients > > > > which > > > > > have been sending mitigation requests to it. > > > > > > > > > > -Tiru > > > > > > > > > > > -----Original Message----- > > > > > > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > > > Sent: Friday, April 6, 2018 8:06 PM > > > > > > To: mohamed.boucadair@orange.com; Konda, Tirumaleswar Reddy > > > > > > ; dots@ietf.org > > > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > Hi Med, > > > > > > > > > > > > Thanks for this. I would like to see the ttl: definition > > > > > > tightened up (moved away from the DNS TTL version) > > > > > > > > > > > > Old > > > > > > > > > > > > ttl: Time to live (TTL) of alternate records, represented a= s an > > > > > > integer number of seconds. That is, the time interval th= at > > > > > > alternate IP addresses may be cached by a DOTS client. > > > > > > > > > > > > '0' means that an alternate IP address is only to be > > > > > > used for > > the > > > > > > request in progress, and consequently that IP address > > > > > > should > > not > > > > > > be cached. > > > > > > > > > > > > If no 'ttl' is returned in a redirect response, this is > > equivalent > > > > > > to returning a 'ttl' parameter set to '0'. > > > > > > > > > > > > If 'alt-server-record' has expired, the DOTS client MUST > > > > > > use > > the > > > > > > DOTS server(s) that was provisioned using means discussed= in > > > > > > Section 4.1. Furthermore, a DOTS client MUST NOT use the= alt- > > > > > > server FQDN if the 'alt-server-records' has expired. > > > > > > > > > > > > New > > > > > > > > > > > > ttl: Time to live (TTL) of the alternate DOTS server, > > > > > > represented as > > > > > an > > > > > > integer number of seconds. That is, the time interval th= at > > > > > > the alternate DOTS server may be cached for use by a > > > > > > DOTS > > client. > > > > > > > > > > > > '0' means that the alternate DOTS server is only to be > > > > > > used > > for the > > > > > > request in progress, and consequently the alternate DOTS > > > > > > server entry should not > > > > > > be cached. > > > > > > > > > > > > If no 'ttl' is returned in a redirect response, this is > > equivalent > > > > > > to returning a 'ttl' parameter set to '0'. > > > > > > > > > > > > If the alternate DOTS server TTL has expired, the DOTS > > > > > > client MUST > > > > > use the > > > > > > DOTS server(s) that was provisioned using means discussed= in > > > > > > Section 4.1. > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > Jon > > > > > > > > > > > > -----Original Message----- > > > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > > > > > mohamed.boucadair@orange.com > > > > > > Sent: 06 April 2018 15:21 > > > > > > To: Jon Shallow; Konda, Tirumaleswar Reddy; dots@ietf.org > > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > FWIW, I implemented the change at: > > > > > > https://github.com/boucadair/draft-ietf-dots-signal-channel/bl > > > > > > ob > > > > > > /m > > > > > > aste > > > > > > r/draf > > > > > > t-ietf-dots-signal-channel.txt > > > > > > > > > > > > Cheers, > > > > > > Med > > > > > > > > > > > > > -----Message d'origine----- > > > > > > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > > > > Envoy=E9=A0: vendredi 6 avril 2018 15:33 =C0=A0: BOUCADAIR Mo= hamed > > > > > > > IMT/OLN; Konda, Tirumaleswar Reddy; dots@ietf.org Objet=A0: R= E: > > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > Excellent. > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: mohamed.boucadair@orange.com [mailto: > > > > > > > mohamed.boucadair@orange.com] > > > > > > > Sent: 06 April 2018 14:29 > > > > > > > To: Jon Shallow; Konda, Tirumaleswar Reddy; rdd@cert.org > > > > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected > > > > > > > Signaling > > > > > > > > > > > > > > Hi Jon, all, > > > > > > > > > > > > > > I'm fine to put ttl at the level of alt-server. > > > > > > > > > > > > > > Cheers, > > > > > > > Med > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Jon Shallow > > > > > > > > [mailto:supjps-ietf@jpshallow.com] > > > > > > > > Envoy=E9=A0: vendredi 6 avril 2018 14:57 =C0=A0: BOUCADAIR = Mohamed > > > > > > > > IMT/OLN; Konda, Tirumaleswar Reddy; rdd@cert.org Objet=A0: = RE: > > > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > > Hi there, > > > > > > > > > > > > > > > > See inline [Jon3] > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Konda, Tirumaleswa= r > > > > > > > > > > > Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > > > > > > Envoy=E9=A0: vendredi 6 avril 2018 07:07 =C0=A0: BOUC= ADAIR > > > > > > > > > > > Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet=A0:= RE: > > > > > > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > Hi Med, > > > > > > > > > > > > > > > > > > > > > > The proposed update restricts the client no to do a > > > > > > > > > > > DNS lookup using the alternate FQDN, further > > > > > > > > > > > associating a TTL with the name complicates the > > > > > > > > > > > functionality on the DOTS client to re-establish > > > > > > > > > > > (D)TLS session with the primary DOTS server after > > > > > > > > > > > the > > > > > > > TTL expires. > > > > > > > > > > > My suggestion is to let the DOTS client continue to > > > > > > > > > > > use the alternate DOTS > > > > > > > > > server > > > > > > > > > > till it gets re-directed. > > > > > > > > > > > > > > > > > > > > [Med] This is possible with the current spec. > > > > > > > > > > > > > > > > > > > > Triggers for redirect and for falling back to the > > > > > > > > > > nominal configuration are deployment-specific. The > > > > > > > > > > current spec allows for almost all the cases > > > > > > > > > discussed > > > > > > > > > > so far: > > > > > > > > > > > > > > > > > > > > (1) Redirect for the request in progress: A server > > > > > > > > > > does so by returning > > > > > > > > > TTL=3D0. > > > > > > > > > > (2) The alternate server is not involved in fall back > > > > > > > > > > to the nominal > > > > > > > > > server: upon > > > > > > > > > > expiry of ttl of all alternate IP addresses, then fall > > > > > > > > > > back automatically > > > > > > > > > to the > > > > > > > > > > nominal server. > > > > > > > > > > (3) Redirect to an alternate server, which in turn > > > > > > > > > > will instruct the client > > > > > > > > > to > > > > > > > > > > redirect to the "base" configuration: a TTL is > > > > > > > > > > provided and the alternate > > > > > > > > > server > > > > > > > > > > can reply with a redirect code any time before the > > > > > > > > > > expiry of the TTL. A > > > > > > > > > long TTL > > > > > > > > > > can be returned if the alternate server will be > > > > > > > > > > responsible for > > > > > > > > > coordinating fall > > > > > > > > > > back to the base server. > > > > > > > > > > (4) Stop infinite redirects > > > > > > > > > > > > > > > > > > Yes, but (1) and (2) complicate the functionality of the > > > > > > > > > DOTS > > > > > client. > > > > > > > > > > > > > > > > [Med] (1) and (2) is exactly the same functionality > > > > > > > > required for caching DNS replies. > > > > > > > > > > > > > > > > The > > > > > > > > > only reason for adding alt-server-record in the response > > > > > > > > > is DNS server may not be reachable by the DOTS server > > > > > > > > > because of a DDoS > > > > > > attack. > > > > > > > > > > > > > > > > > > > > > > > > > [Med] Yes. Note that even if the name resolution was > > > > > > > > allowed, the client has to deal with the TTL indicated in > > > > > > > > the response...which is exactly the same as (1) and (2). > > > > > > > > > > > > > > > > > > > > > > > > [Jon3] I think where I am struggling here is the > > > > > > > > overloaded use of TTL > > > > > > > > - The TTL as per a DNS record and held as a part of > > > > > > > > alt-server-record and then the TTL after which that the > > > > > > > > alt-server should be handling the traffic before handling > > > > > > > > back to the original primary server. It either has to be > > > > > > > > one or the other, or they have to > > > > > > have different names. > > > > > > > > [Jon3] If we are only going to go for one variant for > > > > > > > > simplicity, then I would prefer that it should be at the > > > > > > > > level of "alt- > > > server". > > > > > > > > Handling the TTL for DNS refresh is normally handled by a > > > > > > > > resolver library, updated by the DNS packets coming in - > > > > > > > > unusual for an application > > > > > > > to have to do that. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I > > > > > > > > > > > don't think the DOTS mitigation provider will know > > > > > > > > > > > ahead-of-time the TTL value after which the DOTS > > > > > > > > > > > client should disconnect communicating with the > > > > > > > > > > > alternate DOTS server and re-establish (D)TLS > > > > > > > > > > > session with the primary DOTS > > > > > server. > > > > > > > > > > > > > > > > > > > > [Med] It depends on the nature of the redirect: > > > > > > > > > > overload, planned > > > > > > > > > maintenance, > > > > > > > > > > etc. For planned maintenance, the TTL is known in gener= al. > > > > > > > > > > > > > > > > > > It's the primary DOTS server responsibility to point the > > > > > > > > > DOTS client to an optimal alternate server, where the > > > > > > > > > client can continue to send migration requests without a > > > > > > > > > frequent ping-pong > > > > > > between servers. > > > > > > > > > > > > > > > > [Med] Agree. This is a service configuration problem. > > > > > > > > [Jon3] Agreed - and the 5 minute minimum ping-pong time is > > > > > > > > a good safety net. > > > > > > > > ~jon3 > > > > > > > > > > > > > > > > > I have seen TURN servers being deployed for several > > > > > > > > > years with > > > > > > > > re-direction > > > > > > > > > but without the need for TTL (see ALTERNATE-SERVER in > > > > > > > > > https://tools.ietf.org/html/draft-ietf-tram-turnbis-11) > > > > > > > > > > > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: Dots [mailto:dots-bounces@ietf.org] On > > > > > > > > > > > > Behalf Of mohamed.boucadair@orange.com > > > > > > > > > > > > Sent: Thursday, April 5, 2018 4:50 PM > > > > > > > > > > > > To: Konda, Tirumaleswar Reddy > > > > > > > > > > > > ; > > > > > > > > > > > > Jon Shallow ; > > > > > > > > > > > > dots@ietf.org > > > > > > > > > > > > Subject: Re: [Dots] Signal Channel - 300 > > > > > > > > > > > > Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > > > Tiru, > > > > > > > > > > > > > > > > > > > > > > > > I don't see the NEW text as a restriction but as a > > > > > > > > > > > > simplification of the > > > > > > > > > > > client's > > > > > > > > > > > > behavior. I don't want to over-specify the > > > > > > > > > > > > redirect > > behavior. > > > > > > > > > > > > > > > > > > > > > > > > Adding another yet layer of resolution will raise > > > > > > > > > > > > other issues such as the > > > > > > > > > > > need to > > > > > > > > > > > > associate a TTL with the name itself. > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > Med > > > > > > > > > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Konda, > > > > > > > > > > > > > Tirumaleswar Reddy > > > > > > > > > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > > > > > > > > Envoy=E9=A0: jeudi 5 avril 2018 12:06 =C0=A0: Jon > > > > > > > > > > > > > Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org > Objet=A0: > > > > > > > > RE: > > > > > > > > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > From: Jon Shallow > > > > > > > > > > > > > > [mailto:supjps-ietf@jpshallow.com] > > > > > > > > > > > > > > Sent: Thursday, April 5, 2018 1:35 PM > > > > > > > > > > > > > > To: mohamed.boucadair@orange.com; Konda, > > > > > > > > > > > > > > Tirumaleswar Reddy > > > > > > > > > > > > > > ; > > > > > > > > > > > > > > dots@ietf.org > > > > > > > > > > > > > > Subject: RE: [Dots] Signal Channel - 300 > > > > > > > > > > > > > > Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Med, > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks for this refresh to 4.6 Redirected > > > > > > > > > > > > > > Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > > > Some comments > > > > > > > > > > > > > > > > > > > > > > > > > > > > #1 > > > > > > > > > > > > > > > > > > > > > > > > > > > > The DOTS server can return the error > > > > > > > > > > > > > > response code > > > > > > > > > > > > > > 3.00 in > > > > > > > > > response > > > > > > > > > > > > > > to a PUT request from the DOTS client or > > > > > > > > > > > > > > convey the error > > > > > > > > > response > > > > > > > > > > > > > > code 3.00 in a unidirectional notification > > > > > > > > > > > > > > response from the > > > > > > > > > DOTS > > > > > > > > > > > > > > server. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Why is this limited to a PUT request and/or > > > > > > > > > > > > > > unidirectional notification > > > > > > > > > > > > > response? > > > > > > > > > > > > > > - Surely, any response, unsolicited or > > > > > > > > > > > > > > otherwise can contain a > > > > > > > > > > > > > > 3.00 > > > > > > > > > > > > > > - If Observe is not in use, then any > > > > > > > > > > > > > > unsolicited notification response will > > > > > > > > > > > > > > potentially get rejected by the coap library > > > > > > > > > > > > > > layer, so a DOTS Server cannot > > > > > > > > > > > > > signal > > > > > > > > > > > > > > maintenance outage other than by closing the > > session. > > > > > > > > > > > > > > - I missed this the last review - sorry > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > #2 > > > > > > > > > > > > > > > > > > > > > > > > > > > > If the DOTS client has been redirected to a > > > > > > > > > > > > > > DOTS server to > > > > > > > > which > > > > > > > > > it > > > > > > > > > > > > > > has already sent the mitigation request > > > > > > > > > > > > > > within the last five > > > > > > > > (5) > > > > > > > > > > > > > > minutes, it MUST ignore the redirection and > > > > > > > > > > > > > > try to contact other DOTS > > > > > > > > > > > > > > > > > > > > > > > > > > > > s/ has already sent the mitigation request/ > > > > > > > > > > > > > > has already communicated with/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > #3 > > > > > > > > > > > > > > > > > > > > > > > > > > > > A DOTS client MUST NOT use an alternate > > > > > > > > > > > > > > IP address to > > > > > > > > contact > > > > > > > > > its > > > > > > > > > > > > > > DOTS server upon expiry of the associated= TTL. > > > > > > > > > > > > > > > > > > > > > > > > > > > > To remove ambiguity over the use of FQDN, this > > > > > > > > > > > > > > could read > > > > > > > > > > > > > > > > > > > > > > > > > > > > A DOTS client MUST NOT use an alternate > > > > > > > > > > > > > > IP address to > > > > > > > > contact > > > > > > > > > its > > > > > > > > > > > > > > DOTS server upon expiry of the associated= TTL. > > > > > > > > > > > > > > Furthermore, a > > > > > > > > > > > DOTS > > > > > > > > > > > > > > Client MUST NOT use the alt-server FQDN > > > > > > > > > > > > > > if all of the > > > > > > > > > > > > > > alt-server- > > > > > > > > > > > > > records > > > > > > > > > > > > > > have expired. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Or alternatively > > > > > > > > > > > > > > > > > > > > > > > > > > > > alt-server: FQDN of an alternate DOTS serve= r. > > > > > > > > > > > > > > > > > > > > > > > > > > > > This could read > > > > > > > > > > > > > > > > > > > > > > > > > > > > alt-server: FQDN of an alternate DOTS serve= r. > > > > > > > > > > > > > > This FQDN is not to be > > > > > > > > > > > > > used for > > > > > > > > > > > > > > looking up IP addresses to use, but is there > > > > > > > > > > > > > > for the SNI extension > > > > > > > > > > > (7.1. > > > > > > > > > > > > > (D)TLS > > > > > > > > > > > > > > Protocol Profile) > > > > > > > > > > > > > > > > > > > > > > > > > > I don't think the above restriction is correct > > > > > > > > > > > > > for the following > > > > > > > > > reasons: > > > > > > > > > > > > > > > > > > > > > > > > > > 1) If the TTL value in the alt-server-record > > > > > > > > > > > > > expires, DNS lookup can be performed by the DOTS > > > > > > > > > > > > > client using the alternate DOTS > > > > > > > > server > > > > > > > > > FQDN. > > > > > > > > > > > > > 2) If the DNS server is reachable, the client > > > > > > > > > > > > > may want to a DANE lookup to get the IP > > > > > > > > > > > > > addresses and certificate to validate the > > > > > > > > > > > > > alternate DOTS server certificate > > > sent > > > > > > > > > > > > > in the DTLS handshake. > > > > > > > > > > > > > > > > > > > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > From: Dots [mailto: dots-bounces@ietf.org] On > > > > > > > > > > > > > > Behalf Of mohamed.boucadair@orange.com > > > > > > > > > > > > > > Sent: 05 April 2018 08:20 > > > > > > > > > > > > > > To: Konda, Tirumaleswar Reddy; Jon Shallow; > > > > > > > > > > > > > > dots@ietf.org > > > > > > > > > > > > > > Subject: Re: [Dots] Signal Channel - 300 > > > > > > > > > > > > > > Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Tiru, > > > > > > > > > > > > > > > > > > > > > > > > > > > > Works for me. > > > > > > > > > > > > > > > > > > > > > > > > > > > > I updated the draft with the text additions > > > > > > > > > > > > > > that were discussed in this thread. The > > > > > > > > > > > > > > changes can be > > found at: > > > > > > > > > > > > > > https://github.com/boucadair/draft-ietf-dots-s > > > > > > > > > > > > > > ig > > > > > > > > > > > > > > na > > > > > > > > > > > > > > l- > > > > > > > > > > > > > channel/blob/master/draf > > > > > > > > > > > > > > t-ietf-dots-signal-channel.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > Med > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Konda, > > > > > > > > > > > > > > > Tirumaleswar Reddy > > > > > > > > > > > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > > > > > > > > > > Envoy=E9=A0: mercredi 4 avril 2018 17:40 =C0= =A0: Jon > > > > > > > > > > > > > > > Shallow; BOUCADAIR Mohamed IMT/OLN; > > > > > > > > > > > > > > > dots@ietf.org > > > > > Objet=A0: RE: > > > > > > > > > > > > > > > [Dots] Signal Channel - 300 Redirected > > > > > > > > > > > > > > > Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The TTL value returned under > > > > > > > > > > > > > > > alt-server-record is equivalent to the DNS > > > > > > > > > > > > > > > TTL value. A DDoS mitigation provider with > > > > > > > > > > > > > > > multiple DOTS servers typically re-directs a > > > > > > > > > > > > > > > DOTS client to a different DOTS server only > > > > > > > > > > > > > > > if the alternate DOTS server has the > > > > > > > > > > > > > > > capacity to handle the requests from the > > > > > > > > > > > > > > DOTS client. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We can add the following lines to avoid loops= : > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If the DOTS client has been redirected to a > > > > > > > > > > > > > > > DOTS server to which it has already sent the > > > > > > > > > > > > > > > mitigation request within the last five > > > > > > > > > > > > > > > minutes, it MUST ignore the redirection and > > > > > > > > > > > > > > > try reaching others servers listed in the > > > > > > > > > > > > > > > local configuration or discovered using > > > > > > > > > > > > > > > dynamic means > > > > > > > such as DHCP or SRV procedures. > > > > > > > > > > > > > > > This prevents infinite ping-ponging between > > > > > > > > > > > > > > > servers in case of redirection loops. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > > > From: Dots [mailto:dots-bounces@ietf.org] > > > > > > > > > > > > > > > > On Behalf Of Jon Shallow > > > > > > > > > > > > > > > > Sent: Wednesday, April 4, 2018 8:16 PM > > > > > > > > > > > > > > > > To: mohamed.boucadair@orange.com; > > > > > > > > > > > > > > > > dots@ietf.org > > > > > > > > > > > > > > > > Subject: Re: [Dots] Signal Channel - 300 > > > > > > > > > > > > > > > > Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi there, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > See inline [Jon] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > > > From: Dots [mailto: dots-bounces@ietf.org] > > > > > > > > > > > > > > > > On Behalf Of mohamed.boucadair@orange.com > > > > > > > > > > > > > > > > Sent: 04 April 2018 15:07 > > > > > > > > > > > > > > > > To: Jon Shallow; dots@ietf.org > > > > > > > > > > > > > > > > Subject: Re: [Dots] Signal Channel - 300 > > > > > > > > > > > > > > > > Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Re-, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please see inline. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > > Med > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Dots > > > > > > > > > > > > > > > > > [mailto:dots-bounces@ietf.org] De la > > > > > > > > > > > > > > > > > part de Jon Shallow Envoy=E9=A0: mercredi= 4 > > > > > > > > > > > > > > > > > avril 2018 > > 15:31 =C0=A0: > > > > > > > > > > > > > > > > > dots@ietf.org > > > > > > > > > > > Objet=A0: > > > > > > > > > > > > > > > > > [Dots] Signal Channel - 300 Redirected > > > > > > > > > > > > > > > > > Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi there, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have implemented the 300 > > > > > > > > > > > > > > > > > Redirected-Signal in my DOTS > > > > > > > > code. > > > > > > > > > > > > > > > > > This then raises some questions about > > usability. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Usability #1 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Architecture 3.2.2 Redirected Signalling > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 4. Having redirected the DOTS > > > > > > > > > > > > > > > > > client, DOTS server A ceases > > > > > > > > > > > > > sending > > > > > > > > > > > > > > > > > server signals. The DOTS client > > > > > > > > > > > > > > > > > likewise stops sending > > > > > > > > > > > client > > > > > > > > > > > > > > > > > signals to DOTS server A. DOTS > > > > > > > > > > > > > > > > > session 1 is > > > > > > > > > terminated. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Clearly indicates that the original > > > > > > > > > > > > > > > > > session (Client to Server > > > > > > > > > > > > > > > > > A) is no more once redirected and only > > > > > > > > > > > > > > > > > Client to Server B is in > > > > > > > > > > > use. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > How is the traffic redirected back to > > > > > > > > > > > > > > > > > Server A once maintenance / overloading e= tc. > > has finished? > > > > > > > > > > > > > > > > > My assumption is that Server B sends a > > > > > > > > > > > > > > > > > redirect to go back to Server A as > > > > > > > > > > > > > > > > > Server A has no way to say over a now > > > > > > > > > > > > > > > > > non-existent session to say > > > > > > > > > > > > "come back". > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [Med] That's one possibility. This one > > > > > > > > > > > > > > > > does not require any update to the > > > > > > > > > > > > > > > signal- > > > > > > > > > > > > > > > > channel specification. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Another approach would be to not require > > > > > > > > > > > > > > > > any redirect signal from server > > > > > > > > > > > > > > B. > > > > > > > > > > > > > > > > The client will remove server B's records > > > > > > > > > > > > > > > > upon the expiry of the TTL and > > > > > > > > > > > > > > > will fall > > > > > > > > > > > > > > > > back to the "base" DOTS servers > > > > > > > > > > > > > > > > configuration that was provisioned to the > > > > > > > > > > > > > > > client > > > > > > > > > > > > > > > > using DHCP or whatever mechanism. > > > > > > > > > > > > > > > > [Jon] OK. The TTL is defined at, > > > > > > > > > > > > > > > > associated with the IP address level > > > > > > > > > > > > > > > under alt- > > > > > > > > > > > > > > > > server-record, not under > > > > > > > > > > > > > > > > ietf-dots-signal-channel:redirected-signal. > > The ttl > > > > > > > > > definition is > > > > > > > > > > > > > > > > ambiguous as to what it refers to and > > > > > > > > > > > > > > > > perhaps could be tightened up in the > > > > > > > > > > > > > > > > language (I read it as being associated > > > > > > > > > > > > > > > > with "addr" in the sense of a DNS > > > > > > > > > > > > > > > TTL). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Do we need to keep the existing Client > > > > > > > > > > > > > > > > > to Server A session warm (or perhaps to > > > > > > > > > > > > > > > > > probe > > > > > > > > > > > > > > > > > periodically) to see if Server A is > > > > > > > > > > > > > > > > > capable of handling the Client again by > > > > > > > > > > > > > > > > > a server response extension to the > > > > > > > > > > > > > > > > > protocol (e.g. a > > > > > > > > > > > > > > > > > 3.01) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [Med] Redirect was initially introduced to > > > > > > > > > > > > > > > > manage a server overload, so I > > > > > > > > > > > > > > > don't > > > > > > > > > > > > > > > > think it makes sense to probe or maintain > > > > > > > > > > > > > > > > a session with > > > > > > > > server > > > > > > > > > A. > > > > > > > > > > > > > > > > [Jon] Agreed, but I needed to raise the > > question. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Should there be a retry period parameter > > > > > > > > > > > > > > > > > added in to the > > > > > > > > > > > > > > > > > 3.00 protocol (as I read it, ttl only > > > > > > > > > > > > > > > > > refers to the IP > > > > > > > > > address)? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [Med] The client will automatically switch > > > > > > > > > > > > > > > > to Server A when all alternate > > > > > > > > > > > > > > > records > > > > > > > > > > > > > > > > expire. > > > > > > > > > > > > > > > > [Jon] OK - again the 4.6 text needs to get > > > > > > > > > > > > > > > > tightened up to reflect this as > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > intent. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Usability #2 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Server A says "Redirect to Server B" due > > > > > > > > > > > > > > > > > to > > > > > > overloading. > > > > > > > > > > > > > > > > > Server B accepts things for a while and > > > > > > > > > > > > > > > > > then is instructed/decides to redirect > > > > > > > > > > > > > > > > > traffic > > back to A. > > > > > > > > > > > > > > > > > Server A is left still overload > > > > > > > > > > > > > > > > > configured to redirect to B. How should > > > > > > > > > > > > > > > > > the client handle this as there is no > > > > > > > > > > > > > > > > > suitable > > > > > > > > > > > > > > > > Server? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [Med] This is a service configuration probl= em. > > > > > > > > > > > > > > > > We may > > > > > > ask: > > > > > > > > > > > > > > > > * the client to log the error and notify > > > > > > > > > > > > > > > > the > > > > > > > administrator. > > > > > > > > > > > > > > > > * and/or stop the redirection after n cycle= s. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Still, this does not solve the problem. > > > > > > > > > > > > > > > > [Jon] Agreed there is a problem here > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I agree that there needs to be > > > > > > > > > > > > > > > > > co-ordination between Server A and > > > > > > > > > > > > > > > > > Server B, but user error may > > > > > > creep in. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Usability #3 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Server A says "Redirect to Server B" as > > > > > > > > > > > > > > > > > it going to be shut down because of > > > > > > > > > > > > > > > > > maintenance. Server B accepts things > > > > > > > > > > > > > > > > > for a while and then is instructed (in > > > > > > > > > > > > > > > > > probable user > > > > > > > > > > > > > > > > > error) to redirect traffic back to A > > > > > > > > > > > > > > > > > (perhaps because it has hit an overload > > > > > > > > > > > > > > > > > condition). How should the client > > > > > > > > > > > > > > > > handle this? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [Med] Isn't this a sub-case or #2? > > > > > > > > > > > > > > > > [Jon] Yes, but I wanted to bring in Server > > > > > > > > > > > > > > > > A being alive and able to > > > > > > > > > > > > > > > respond > > > > > > > > > > > > > > > > versus Server A down and not responding > > > > > > > > > > > > > > > > due to > > > > > > > maintenance. > > > > > > > > > > > > > > > > [Jon] With my better understanding of TTL > > > > > > > > > > > > > > > > we still have an issue if the TTL expires > > > > > > > > > > > > > > > > and Server A is having an extended > > > > > > > > > outage. > > > > > > > > > > > > > > > > How do we recover from that? > > > > > > > > > > > > > > > > ~jon > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ________________________________________ > > > > > > > > > > > > > > > > > __ __ ___ Dots mailing list > > > > > > > > > > > > > > > > > Dots@ietf.org > > > > > > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/do > > > > > > > > > > > > > > > > > ts > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > __________________________________________ > > > > > > > > > > > > > > > > __ __ _ Dots mailing list Dots@ietf.org > > > > > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > __________________________________________ > > > > > > > > > > > > > > > > __ __ _ Dots mailing list Dots@ietf.org > > > > > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > > > > > > > > > > > > > ______________________________________________ > > > > > > > > > > > > > > _ Dots mailing list Dots@ietf.org > > > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > Dots mailing list > > > > > > > > > > > > Dots@ietf.org > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > Dots mailing list > > > > > > > > > Dots@ietf.org > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Dots mailing list > > > > > > > > Dots@ietf.org > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Dots mailing list > > > > > > Dots@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > _______________________________________________ > > > > > Dots mailing list > > > > > Dots@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > _______________________________________________ > > > > > Dots mailing list > > > > > Dots@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots From nobody Mon Apr 9 03:22:21 2018 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 2D8F4124207 for ; Mon, 9 Apr 2018 03:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LglClTmGaHNO for ; Mon, 9 Apr 2018 03:22: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 0C9D9126D73 for ; Mon, 9 Apr 2018 03:22:16 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.90_1) (envelope-from ) id 1f5TwE-0003T2-8p; Mon, 09 Apr 2018 11:22:14 +0100 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , , References: <014f01d3cc19$2e3880e0$8aa982a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7E7B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <019901d3cc23$a93ff8e0$fbbfeaa0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8524@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <004e01d3ccb4$d505e7f0$7f11b7d0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8758@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEF912A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEF93EE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <008501d3cda6$c860d210$59227630$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF951 1@OPEXCLILMA 3 . corporate.adroot.infra.ftgroup> <00b001d3cdab$ba8caec0$2fa60c40$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF975C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <00b801d3cdb4$982dc4a0$c8894de0$@jpshallow.com> <015101d3ce74$351393c0$9f3abb40$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEFA190@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <01f501d3cfde$4014ca30$c03e5e90$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEFA2DF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Date: Mon, 9 Apr 2018 11:22:15 +0100 Message-ID: <022901d3cfec$a1aa2430$e4fe6c90$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ5xX4UsK17va5Vv37fpNudI6+9awKIdnG+AkIt6UkCuIhgoQJj4oJpArGJQHwA3D0H4gGs0H5ZApHDVXYB/IC8TgE0bwOgAlFzC1QBmQ12ZgLRnqapAa02vLICgeu4wAFxD+3yAcnB1kgBbHrBnwH1+oe0Ao3oNgYBtwYJxAG3DN7VAfNoKlsChRVMLKElQH7Q Content-Language: en-gb Archived-At: Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling 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, 09 Apr 2018 10:22:20 -0000 Hi Tiru/Med, See inline [Jon2] Regards Jon > > -----Message d'origine----- > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > Envoy=E9=A0: lundi 9 avril 2018 10:39 > > =C0=A0: 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN;=20 > > dots@ietf.org Objet=A0: RE: [Dots] Signal Channel - 300 Redirected=20 > > Signaling > > > > Hi all, > > > > Should 'ttl' actually be 'lifetime' to remove any confusion over = whether > > this is DNS TTL usage or not ? >=20 > [Med] we do already have a lifetime in the cbor mapping table. So, I=20 > suggest to maintain ttl but focus on its definition to avoid = confusion. Agreed. >=20 > > > > Otherwise see inline [Jon] > > > > Regards > > > > Jon > > > > -----Original Message----- > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda,=20 > > Tirumaleswar Reddy > > Sent: 09 April 2018 09:23 > > To: mohamed.boucadair@orange.com; Jon Shallow; dots@ietf.org > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > -----Original Message----- > > > From: mohamed.boucadair@orange.com=20 > > > [mailto:mohamed.boucadair@orange.com] > > > Sent: Monday, April 9, 2018 1:15 PM > > > To: Konda, Tirumaleswar Reddy=20 > > > ; > > > Jon Shallow ; dots@ietf.org > > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > Tiru, > > > > > > What about this update ones? > > > > > > =3D=3D=3D=3D=3D=3D=3D > > > ttl: Time to live (TTL) of the alternate DOTS server, = represented as > > > an integer number of seconds. That is, the time interval = that the > > > alternate DOTS server may be cached for use by a DOTS = client. > > > > > > A lifetime of negative one (-1) indicates indefinite TTL. = This > > > value means that the alternate DOTS server is to be used = until the > > > alternate DOTS server redirects the traffic with another = 3.00 > > > response. > > > > > > If no 'ttl' is returned in a redirect response, this is equivalent > > > to returning a 'ttl' parameter set to '-1'. > > > > Above text looks good. > > > > [Jon] Later in the text, there is reference to a minimum of 5=20 > > minutes before being able to switch back to the original DOTS=20 > > server. Don't we need to say a 5 minute (300 secs) minimum here? >=20 > [Med] That reference is when explicit redirect signals are involved. Yup. >=20 > > > > > > > > If the alternate DOTS server TTL has expired, the DOTS = client MUST > > > use the DOTS server(s), that was provisioned using means discussed > > > in Section 4.1, for creating new requests. > > > > It looks too restrictive, typically the DNS TTL values are=20 > > short-lived (e.g.. few seconds) but the sessions are long-lived. > > Why not replace "for creating new requests" with "for creating new=20 > > DOTS session" ? > > > > [Jon] I think that once the alternate DOTS server's lifetime has=20 > > expired, the DOTS client should try to establish a connection with=20 > > the appropriate "normal" DOTS servers, >=20 > [Med] Bingo. No, DNS TTL lifetime does not mean existing session has to be = disconnected after the TTL expires.=20 [Jon2] I guess that I am missing something here. A DOTS client, when = using a resolver library, has no knowledge of when an IP's DNS TTL will expire = or has expired - a lookup request to the library may or may not refresh the remaining TTL. [Jon2] However, I thought that TTL referred to the alternate DOTS server lifetime and now had nothing to do with DNS TTL. [Jon2] My text immediately below implies that the current session should only get disconnected if the DOTS client is able to start using another (likely to be the original) DOTS server. -Tiru >=20 > if that fails, continue to use the alternate DOTS > > server, but periodically retry the "normal" servers to try to=20 > > maintain resilience of service. >=20 > [Med] The document does not specify the behavior for selecting among=20 > multiple servers. So, this details are out of scope. [Jon2] Agreed the details are out of scope, but would follow the lines = of " the DOTS client MUST use the DOTS server(s), that was provisioned using means discussed in Section 4.1, for creating new requests." ~jon2 >=20 > After all, the outage (e.g. maintenance window) of > > the original DOTS server may have to be extended, and being down,=20 > > cannot respond with a 3.00 to instruct DOTS client to stay with the=20 > > alternate DOTS server. > > >=20 > [Med] For such cases, it is safe to return an indefinite TTL +=20 > alternate server to coordinate the fallback behavior. >=20 > > --Tiru > > > > > > > > This is an optional attribute. > > > =3D=3D=3D > > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De=A0: Konda, Tirumaleswar Reddy > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > Envoy=E9=A0: lundi 9 avril 2018 08:51 =C0=A0: Jon Shallow; = BOUCADAIR=20 > > > > Mohamed IMT/OLN; dots@ietf.org Objet=A0: RE: > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > Hi Jon, > > > > > > > > I partially agree with the suggested update. A IP address is=20 > > > > cached until the TTL value expires, the DOTS client need not=20 > > > > disconnect existing sessions after the TTL expires, but after=20 > > > > the TTL expires it must consider the IP address stale and not=20 > > > > establish new (D)TLS sessions. > > > > > > > > Cheers, > > > > -Tiru > > > > > > > > > -----Original Message----- > > > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon=20 > > > > > Shallow > > > > > Sent: Saturday, April 7, 2018 6:58 PM > > > > > To: Konda, Tirumaleswar Reddy > > > > > ; > > > > > mohamed.boucadair@orange.com; dots@ietf.org > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > Hi there, > > > > > > > > > > My suggestion would be to make ttl of -1 'infinite', otherwise = > > > > > have a > > > > minimum > > > > > value of 300 seconds. The text could read (including=20 > > > > > referring to the > > > > optional > > > > > etc. to be consistent with the rest of the document:- > > > > > > > > > > alt-server: FQDN of an alternate DOTS server. > > > > > > > > > > This is a required attribute. > > > > > > > > > > alt-server-record: A list of IP addresses of an alternate = DOTS > > > > > server. > > > > > > > > > > This is an optional attribute. > > > > > > > > > > ttl: Time to live (TTL) of the alternate DOTS server,=20 > > > > > represented > > as > > > > > an integer number of seconds. That is, the time=20 > > > > > interval that > > the > > > > > alternate DOTS server may be used by a DOTS client. > > > > > > > > > > The minimum value is '300' seconds, or '-1'. > > > > > > > > > > '-1' means that the alternate DOTS server is to be used=20 > > > > > until the > > > > alternate > > > > > DOTS server redirects the traffic with another 3.00 response. > > > > > There is no TTL expiry. > > > > > > > > > > If no 'ttl' is returned in a redirect response, this is > > equivalent > > > > > to returning a 'ttl' parameter set to '-1'. > > > > > > > > > > If the alternate DOTS server TTL has expired, the DOTS=20 > > > > > client > > MUST > > > > > use the DOTS server(s) that was provisioned using means > > discussed > > > > > in Section 4.1. > > > > > > > > > > This is an optional attribute. > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > Jon > > > > > > > > > > -----Original Message----- > > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = > > > > > Tirumaleswar Reddy > > > > > Sent: 06 April 2018 15:55 > > > > > To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > The below proposed change does not look good to me, its=20 > > > > > causing the DOTS client to ping-pong between multiple DOTS=20 > > > > > servers because of the TTL > > > value. > > > > > The alternate server should serve the DOTS client till there=20 > > > > > is a planned maintenance, if it is getting over-subscribed it=20 > > > > > should re-direct the new > > > > DOTS > > > > > clients to an alternate server and avoid bouncing the existing = > > > > > DOTS clients > > > > which > > > > > have been sending mitigation requests to it. > > > > > > > > > > -Tiru > > > > > > > > > > > -----Original Message----- > > > > > > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > > > Sent: Friday, April 6, 2018 8:06 PM > > > > > > To: mohamed.boucadair@orange.com; Konda, Tirumaleswar Reddy=20 > > > > > > ; dots@ietf.org > > > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected=20 > > > > > > Signaling > > > > > > > > > > > > Hi Med, > > > > > > > > > > > > Thanks for this. I would like to see the ttl: definition=20 > > > > > > tightened up (moved away from the DNS TTL version) > > > > > > > > > > > > Old > > > > > > > > > > > > ttl: Time to live (TTL) of alternate records, = represented as an > > > > > > integer number of seconds. That is, the time interval that > > > > > > alternate IP addresses may be cached by a DOTS client. > > > > > > > > > > > > '0' means that an alternate IP address is only to be=20 > > > > > > used for > > the > > > > > > request in progress, and consequently that IP address=20 > > > > > > should > > not > > > > > > be cached. > > > > > > > > > > > > If no 'ttl' is returned in a redirect response, this=20 > > > > > > is > > equivalent > > > > > > to returning a 'ttl' parameter set to '0'. > > > > > > > > > > > > If 'alt-server-record' has expired, the DOTS client=20 > > > > > > MUST use > > the > > > > > > DOTS server(s) that was provisioned using means = discussed in > > > > > > Section 4.1. Furthermore, a DOTS client MUST NOT use = the alt- > > > > > > server FQDN if the 'alt-server-records' has expired. > > > > > > > > > > > > New > > > > > > > > > > > > ttl: Time to live (TTL) of the alternate DOTS server,=20 > > > > > > represented as > > > > > an > > > > > > integer number of seconds. That is, the time interval that > > > > > > the alternate DOTS server may be cached for use by a=20 > > > > > > DOTS > > client. > > > > > > > > > > > > '0' means that the alternate DOTS server is only to be = > > > > > > used > > for the > > > > > > request in progress, and consequently the alternate=20 > > > > > > DOTS server entry should not > > > > > > be cached. > > > > > > > > > > > > If no 'ttl' is returned in a redirect response, this=20 > > > > > > is > > equivalent > > > > > > to returning a 'ttl' parameter set to '0'. > > > > > > > > > > > > If the alternate DOTS server TTL has expired, the DOTS = > > > > > > client MUST > > > > > use the > > > > > > DOTS server(s) that was provisioned using means = discussed in > > > > > > Section 4.1. > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > Jon > > > > > > > > > > > > -----Original Message----- > > > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of=20 > > > > > > mohamed.boucadair@orange.com > > > > > > Sent: 06 April 2018 15:21 > > > > > > To: Jon Shallow; Konda, Tirumaleswar Reddy; dots@ietf.org > > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected=20 > > > > > > Signaling > > > > > > > > > > > > FWIW, I implemented the change at: > > > > > > https://github.com/boucadair/draft-ietf-dots-signal-channel/ > > > > > > bl > > > > > > ob > > > > > > /m > > > > > > aste > > > > > > r/draf > > > > > > t-ietf-dots-signal-channel.txt > > > > > > > > > > > > Cheers, > > > > > > Med > > > > > > > > > > > > > -----Message d'origine----- De=A0: Jon Shallow=20 > > > > > > > [mailto:supjps-ietf@jpshallow.com] > > > > > > > Envoy=E9=A0: vendredi 6 avril 2018 15:33 =C0=A0: BOUCADAIR = Mohamed=20 > > > > > > > IMT/OLN; Konda, Tirumaleswar Reddy; dots@ietf.org = Objet=A0: RE: > > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > Excellent. > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: mohamed.boucadair@orange.com [mailto: > > > > > > > mohamed.boucadair@orange.com] > > > > > > > Sent: 06 April 2018 14:29 > > > > > > > To: Jon Shallow; Konda, Tirumaleswar Reddy; rdd@cert.org > > > > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected=20 > > > > > > > Signaling > > > > > > > > > > > > > > Hi Jon, all, > > > > > > > > > > > > > > I'm fine to put ttl at the level of alt-server. > > > > > > > > > > > > > > Cheers, > > > > > > > Med > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Jon Shallow=20 > > > > > > > > [mailto:supjps-ietf@jpshallow.com] > > > > > > > > Envoy=E9=A0: vendredi 6 avril 2018 14:57 =C0=A0: = BOUCADAIR=20 > > > > > > > > Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; rdd@cert.org Objet=A0: RE: > > > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > > Hi there, > > > > > > > > > > > > > > > > See inline [Jon3] > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Konda,=20 > > > > > > > > > > > Tirumaleswar Reddy=20 > > > > > > > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > > > > > > Envoy=E9=A0: vendredi 6 avril 2018 07:07 =C0=A0: = BOUCADAIR=20 > > > > > > > > > > > Mohamed IMT/OLN; Jon Shallow; dots@ietf.org = Objet=A0: RE: > > > > > > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > Hi Med, > > > > > > > > > > > > > > > > > > > > > > The proposed update restricts the client no to do=20 > > > > > > > > > > > a DNS lookup using the alternate FQDN, further=20 > > > > > > > > > > > associating a TTL with the name complicates the=20 > > > > > > > > > > > functionality on the DOTS client to re-establish=20 > > > > > > > > > > > (D)TLS session with the primary DOTS server after=20 > > > > > > > > > > > the > > > > > > > TTL expires. > > > > > > > > > > > My suggestion is to let the DOTS client continue=20 > > > > > > > > > > > to use the alternate DOTS > > > > > > > > > server > > > > > > > > > > till it gets re-directed. > > > > > > > > > > > > > > > > > > > > [Med] This is possible with the current spec. > > > > > > > > > > > > > > > > > > > > Triggers for redirect and for falling back to the=20 > > > > > > > > > > nominal configuration are deployment-specific. The=20 > > > > > > > > > > current spec allows for almost all the cases > > > > > > > > > discussed > > > > > > > > > > so far: > > > > > > > > > > > > > > > > > > > > (1) Redirect for the request in progress: A server=20 > > > > > > > > > > does so by returning > > > > > > > > > TTL=3D0. > > > > > > > > > > (2) The alternate server is not involved in fall=20 > > > > > > > > > > back to the nominal > > > > > > > > > server: upon > > > > > > > > > > expiry of ttl of all alternate IP addresses, then=20 > > > > > > > > > > fall back automatically > > > > > > > > > to the > > > > > > > > > > nominal server. > > > > > > > > > > (3) Redirect to an alternate server, which in turn=20 > > > > > > > > > > will instruct the client > > > > > > > > > to > > > > > > > > > > redirect to the "base" configuration: a TTL is=20 > > > > > > > > > > provided and the alternate > > > > > > > > > server > > > > > > > > > > can reply with a redirect code any time before the=20 > > > > > > > > > > expiry of the TTL. A > > > > > > > > > long TTL > > > > > > > > > > can be returned if the alternate server will be=20 > > > > > > > > > > responsible for > > > > > > > > > coordinating fall > > > > > > > > > > back to the base server. > > > > > > > > > > (4) Stop infinite redirects > > > > > > > > > > > > > > > > > > Yes, but (1) and (2) complicate the functionality of=20 > > > > > > > > > the DOTS > > > > > client. > > > > > > > > > > > > > > > > [Med] (1) and (2) is exactly the same functionality=20 > > > > > > > > required for caching DNS replies. > > > > > > > > > > > > > > > > The > > > > > > > > > only reason for adding alt-server-record in the=20 > > > > > > > > > response is DNS server may not be reachable by the=20 > > > > > > > > > DOTS server because of a DDoS > > > > > > attack. > > > > > > > > > > > > > > > > > > > > > > > > > [Med] Yes. Note that even if the name resolution was=20 > > > > > > > > allowed, the client has to deal with the TTL indicated=20 > > > > > > > > in the response...which is exactly the same as (1) and = (2). > > > > > > > > > > > > > > > > > > > > > > > > [Jon3] I think where I am struggling here is the=20 > > > > > > > > overloaded use of TTL > > > > > > > > - The TTL as per a DNS record and held as a part of=20 > > > > > > > > alt-server-record and then the TTL after which that the=20 > > > > > > > > alt-server should be handling the traffic before=20 > > > > > > > > handling back to the original primary server. It either = > > > > > > > > has to be one or the other, or they have to > > > > > > have different names. > > > > > > > > [Jon3] If we are only going to go for one variant for=20 > > > > > > > > simplicity, then I would prefer that it should be at the = > > > > > > > > level of "alt- > > > server". > > > > > > > > Handling the TTL for DNS refresh is normally handled by=20 > > > > > > > > a resolver library, updated by the DNS packets coming in = > > > > > > > > - unusual for an application > > > > > > > to have to do that. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I > > > > > > > > > > > don't think the DOTS mitigation provider will know = > > > > > > > > > > > ahead-of-time the TTL value after which the DOTS=20 > > > > > > > > > > > client should disconnect communicating with the=20 > > > > > > > > > > > alternate DOTS server and re-establish (D)TLS=20 > > > > > > > > > > > session with the primary DOTS > > > > > server. > > > > > > > > > > > > > > > > > > > > [Med] It depends on the nature of the redirect: > > > > > > > > > > overload, planned > > > > > > > > > maintenance, > > > > > > > > > > etc. For planned maintenance, the TTL is known in general. > > > > > > > > > > > > > > > > > > It's the primary DOTS server responsibility to point=20 > > > > > > > > > the DOTS client to an optimal alternate server, where=20 > > > > > > > > > the client can continue to send migration requests=20 > > > > > > > > > without a frequent ping-pong > > > > > > between servers. > > > > > > > > > > > > > > > > [Med] Agree. This is a service configuration problem. > > > > > > > > [Jon3] Agreed - and the 5 minute minimum ping-pong time=20 > > > > > > > > is a good safety net. > > > > > > > > ~jon3 > > > > > > > > > > > > > > > > > I have seen TURN servers being deployed for several=20 > > > > > > > > > years with > > > > > > > > re-direction > > > > > > > > > but without the need for TTL (see ALTERNATE-SERVER in > > > > > > > > > https://tools.ietf.org/html/draft-ietf-tram-turnbis-11 > > > > > > > > > ) > > > > > > > > > > > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: Dots [mailto:dots-bounces@ietf.org] On=20 > > > > > > > > > > > > Behalf Of mohamed.boucadair@orange.com > > > > > > > > > > > > Sent: Thursday, April 5, 2018 4:50 PM > > > > > > > > > > > > To: Konda, Tirumaleswar Reddy=20 > > > > > > > > > > > > ; > > > > > > > > > > > > Jon Shallow ;=20 > > > > > > > > > > > > dots@ietf.org > > > > > > > > > > > > Subject: Re: [Dots] Signal Channel - 300=20 > > > > > > > > > > > > Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > > > Tiru, > > > > > > > > > > > > > > > > > > > > > > > > I don't see the NEW text as a restriction but as = > > > > > > > > > > > > a simplification of the > > > > > > > > > > > client's > > > > > > > > > > > > behavior. I don't want to over-specify the=20 > > > > > > > > > > > > redirect > > behavior. > > > > > > > > > > > > > > > > > > > > > > > > Adding another yet layer of resolution will=20 > > > > > > > > > > > > raise other issues such as the > > > > > > > > > > > need to > > > > > > > > > > > > associate a TTL with the name itself. > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > Med > > > > > > > > > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Konda,=20 > > > > > > > > > > > > > Tirumaleswar Reddy=20 > > > > > > > > > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > > > > > > > > Envoy=E9=A0: jeudi 5 avril 2018 12:06 =C0=A0: = Jon=20 > > > > > > > > > > > > > Shallow; BOUCADAIR Mohamed IMT/OLN;=20 > > > > > > > > > > > > > dots@ietf.org > Objet=A0: > > > > > > > > RE: > > > > > > > > > > > > > [Dots] Signal Channel - 300 Redirected=20 > > > > > > > > > > > > > Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > From: Jon Shallow=20 > > > > > > > > > > > > > > [mailto:supjps-ietf@jpshallow.com] > > > > > > > > > > > > > > Sent: Thursday, April 5, 2018 1:35 PM > > > > > > > > > > > > > > To: mohamed.boucadair@orange.com; Konda,=20 > > > > > > > > > > > > > > Tirumaleswar Reddy=20 > > > > > > > > > > > > > > ; > > > > > > > > > > > > > > dots@ietf.org > > > > > > > > > > > > > > Subject: RE: [Dots] Signal Channel - 300=20 > > > > > > > > > > > > > > Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Med, > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks for this refresh to 4.6 Redirected=20 > > > > > > > > > > > > > > Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > > > Some comments > > > > > > > > > > > > > > > > > > > > > > > > > > > > #1 > > > > > > > > > > > > > > > > > > > > > > > > > > > > The DOTS server can return the error=20 > > > > > > > > > > > > > > response code > > > > > > > > > > > > > > 3.00 in > > > > > > > > > response > > > > > > > > > > > > > > to a PUT request from the DOTS client or=20 > > > > > > > > > > > > > > convey the error > > > > > > > > > response > > > > > > > > > > > > > > code 3.00 in a unidirectional=20 > > > > > > > > > > > > > > notification response from the > > > > > > > > > DOTS > > > > > > > > > > > > > > server. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Why is this limited to a PUT request and/or=20 > > > > > > > > > > > > > > unidirectional notification > > > > > > > > > > > > > response? > > > > > > > > > > > > > > - Surely, any response, unsolicited or=20 > > > > > > > > > > > > > > otherwise can contain a > > > > > > > > > > > > > > 3.00 > > > > > > > > > > > > > > - If Observe is not in use, then any=20 > > > > > > > > > > > > > > unsolicited notification response will=20 > > > > > > > > > > > > > > potentially get rejected by the coap library = > > > > > > > > > > > > > > layer, so a DOTS Server cannot > > > > > > > > > > > > > signal > > > > > > > > > > > > > > maintenance outage other than by closing the > > session. > > > > > > > > > > > > > > - I missed this the last review - sorry > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > #2 > > > > > > > > > > > > > > > > > > > > > > > > > > > > If the DOTS client has been redirected to = > > > > > > > > > > > > > > a DOTS server to > > > > > > > > which > > > > > > > > > it > > > > > > > > > > > > > > has already sent the mitigation request=20 > > > > > > > > > > > > > > within the last five > > > > > > > > (5) > > > > > > > > > > > > > > minutes, it MUST ignore the redirection=20 > > > > > > > > > > > > > > and try to contact other DOTS > > > > > > > > > > > > > > > > > > > > > > > > > > > > s/ has already sent the mitigation request/=20 > > > > > > > > > > > > > > has already communicated with/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > #3 > > > > > > > > > > > > > > > > > > > > > > > > > > > > A DOTS client MUST NOT use an=20 > > > > > > > > > > > > > > alternate IP address to > > > > > > > > contact > > > > > > > > > its > > > > > > > > > > > > > > DOTS server upon expiry of the = associated TTL. > > > > > > > > > > > > > > > > > > > > > > > > > > > > To remove ambiguity over the use of FQDN,=20 > > > > > > > > > > > > > > this could read > > > > > > > > > > > > > > > > > > > > > > > > > > > > A DOTS client MUST NOT use an=20 > > > > > > > > > > > > > > alternate IP address to > > > > > > > > contact > > > > > > > > > its > > > > > > > > > > > > > > DOTS server upon expiry of the = associated TTL. > > > > > > > > > > > > > > Furthermore, a > > > > > > > > > > > DOTS > > > > > > > > > > > > > > Client MUST NOT use the alt-server=20 > > > > > > > > > > > > > > FQDN if all of the > > > > > > > > > > > > > > alt-server- > > > > > > > > > > > > > records > > > > > > > > > > > > > > have expired. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Or alternatively > > > > > > > > > > > > > > > > > > > > > > > > > > > > alt-server: FQDN of an alternate DOTS server. > > > > > > > > > > > > > > > > > > > > > > > > > > > > This could read > > > > > > > > > > > > > > > > > > > > > > > > > > > > alt-server: FQDN of an alternate DOTS server. > > > > > > > > > > > > > > This FQDN is not to be > > > > > > > > > > > > > used for > > > > > > > > > > > > > > looking up IP addresses to use, but is there = > > > > > > > > > > > > > > for the SNI extension > > > > > > > > > > > (7.1. > > > > > > > > > > > > > (D)TLS > > > > > > > > > > > > > > Protocol Profile) > > > > > > > > > > > > > > > > > > > > > > > > > > I don't think the above restriction is correct = > > > > > > > > > > > > > for the following > > > > > > > > > reasons: > > > > > > > > > > > > > > > > > > > > > > > > > > 1) If the TTL value in the alt-server-record=20 > > > > > > > > > > > > > expires, DNS lookup can be performed by the=20 > > > > > > > > > > > > > DOTS client using the alternate DOTS > > > > > > > > server > > > > > > > > > FQDN. > > > > > > > > > > > > > 2) If the DNS server is reachable, the client=20 > > > > > > > > > > > > > may want to a DANE lookup to get the IP=20 > > > > > > > > > > > > > addresses and certificate to validate the=20 > > > > > > > > > > > > > alternate DOTS server certificate > > > sent > > > > > > > > > > > > > in the DTLS handshake. > > > > > > > > > > > > > > > > > > > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > From: Dots [mailto: dots-bounces@ietf.org]=20 > > > > > > > > > > > > > > On Behalf Of mohamed.boucadair@orange.com > > > > > > > > > > > > > > Sent: 05 April 2018 08:20 > > > > > > > > > > > > > > To: Konda, Tirumaleswar Reddy; Jon Shallow;=20 > > > > > > > > > > > > > > dots@ietf.org > > > > > > > > > > > > > > Subject: Re: [Dots] Signal Channel - 300=20 > > > > > > > > > > > > > > Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Tiru, > > > > > > > > > > > > > > > > > > > > > > > > > > > > Works for me. > > > > > > > > > > > > > > > > > > > > > > > > > > > > I updated the draft with the text additions=20 > > > > > > > > > > > > > > that were discussed in this thread. The=20 > > > > > > > > > > > > > > changes can be > > found at: > > > > > > > > > > > > > > https://github.com/boucadair/draft-ietf-dots > > > > > > > > > > > > > > -s > > > > > > > > > > > > > > ig > > > > > > > > > > > > > > na > > > > > > > > > > > > > > l- > > > > > > > > > > > > > channel/blob/master/draf > > > > > > > > > > > > > > t-ietf-dots-signal-channel.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > Med > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Konda,=20 > > > > > > > > > > > > > > > Tirumaleswar Reddy=20 > > > > > > > > > > > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com > > > > > > > > > > > > > > > ] Envoy=E9=A0: mercredi 4 avril 2018 17:40 = =C0=A0:=20 > > > > > > > > > > > > > > > Jon Shallow; BOUCADAIR Mohamed IMT/OLN;=20 > > > > > > > > > > > > > > > dots@ietf.org > > > > > Objet=A0: RE: > > > > > > > > > > > > > > > [Dots] Signal Channel - 300 Redirected=20 > > > > > > > > > > > > > > > Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The TTL value returned under=20 > > > > > > > > > > > > > > > alt-server-record is equivalent to the DNS = > > > > > > > > > > > > > > > TTL value. A DDoS mitigation provider with = > > > > > > > > > > > > > > > multiple DOTS servers typically re-directs = > > > > > > > > > > > > > > > a DOTS client to a different DOTS server=20 > > > > > > > > > > > > > > > only if the alternate DOTS server has the=20 > > > > > > > > > > > > > > > capacity to handle the requests from the > > > > > > > > > > > > > > DOTS client. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We can add the following lines to avoid = loops : > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If the DOTS client has been redirected to=20 > > > > > > > > > > > > > > > a DOTS server to which it has already sent = > > > > > > > > > > > > > > > the mitigation request within the last=20 > > > > > > > > > > > > > > > five minutes, it MUST ignore the=20 > > > > > > > > > > > > > > > redirection and try reaching others=20 > > > > > > > > > > > > > > > servers listed in the local configuration=20 > > > > > > > > > > > > > > > or discovered using dynamic means > > > > > > > such as DHCP or SRV procedures. > > > > > > > > > > > > > > > This prevents infinite ping-ponging=20 > > > > > > > > > > > > > > > between servers in case of redirection = loops. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > > > From: Dots=20 > > > > > > > > > > > > > > > > [mailto:dots-bounces@ietf.org] On Behalf = > > > > > > > > > > > > > > > > Of Jon Shallow > > > > > > > > > > > > > > > > Sent: Wednesday, April 4, 2018 8:16 PM > > > > > > > > > > > > > > > > To: mohamed.boucadair@orange.com;=20 > > > > > > > > > > > > > > > > dots@ietf.org > > > > > > > > > > > > > > > > Subject: Re: [Dots] Signal Channel - 300 = > > > > > > > > > > > > > > > > Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi there, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > See inline [Jon] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > > > From: Dots [mailto:=20 > > > > > > > > > > > > > > > > dots-bounces@ietf.org] On Behalf Of=20 > > > > > > > > > > > > > > > > mohamed.boucadair@orange.com > > > > > > > > > > > > > > > > Sent: 04 April 2018 15:07 > > > > > > > > > > > > > > > > To: Jon Shallow; dots@ietf.org > > > > > > > > > > > > > > > > Subject: Re: [Dots] Signal Channel - 300 = > > > > > > > > > > > > > > > > Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Re-, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please see inline. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > > Med > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: = Dots=20 > > > > > > > > > > > > > > > > > [mailto:dots-bounces@ietf.org] De la=20 > > > > > > > > > > > > > > > > > part de Jon Shallow Envoy=E9=A0: = mercredi=20 > > > > > > > > > > > > > > > > > 4 avril 2018 > > 15:31 =C0=A0: > > > > > > > > > > > > > > > > > dots@ietf.org > > > > > > > > > > > Objet=A0: > > > > > > > > > > > > > > > > > [Dots] Signal Channel - 300 Redirected = > > > > > > > > > > > > > > > > > Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi there, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have implemented the 300=20 > > > > > > > > > > > > > > > > > Redirected-Signal in my DOTS > > > > > > > > code. > > > > > > > > > > > > > > > > > This then raises some questions about > > usability. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Usability #1 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Architecture 3.2.2 Redirected=20 > > > > > > > > > > > > > > > > > Signalling > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 4. Having redirected the DOTS=20 > > > > > > > > > > > > > > > > > client, DOTS server A ceases > > > > > > > > > > > > > sending > > > > > > > > > > > > > > > > > server signals. The DOTS=20 > > > > > > > > > > > > > > > > > client likewise stops sending > > > > > > > > > > > client > > > > > > > > > > > > > > > > > signals to DOTS server A. DOTS = > > > > > > > > > > > > > > > > > session 1 is > > > > > > > > > terminated. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Clearly indicates that the original=20 > > > > > > > > > > > > > > > > > session (Client to Server > > > > > > > > > > > > > > > > > A) is no more once redirected and only = > > > > > > > > > > > > > > > > > Client to Server B is in > > > > > > > > > > > use. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > How is the traffic redirected back to=20 > > > > > > > > > > > > > > > > > Server A once maintenance / = overloading etc. > > has finished? > > > > > > > > > > > > > > > > > My assumption is that Server B sends a = > > > > > > > > > > > > > > > > > redirect to go back to Server A as=20 > > > > > > > > > > > > > > > > > Server A has no way to say over a now=20 > > > > > > > > > > > > > > > > > non-existent session to say > > > > > > > > > > > > "come back". > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [Med] That's one possibility. This one=20 > > > > > > > > > > > > > > > > does not require any update to the > > > > > > > > > > > > > > > signal- > > > > > > > > > > > > > > > > channel specification. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Another approach would be to not require = > > > > > > > > > > > > > > > > any redirect signal from server > > > > > > > > > > > > > > B. > > > > > > > > > > > > > > > > The client will remove server B's=20 > > > > > > > > > > > > > > > > records upon the expiry of the TTL and > > > > > > > > > > > > > > > will fall > > > > > > > > > > > > > > > > back to the "base" DOTS servers=20 > > > > > > > > > > > > > > > > configuration that was provisioned to=20 > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > client > > > > > > > > > > > > > > > > using DHCP or whatever mechanism. > > > > > > > > > > > > > > > > [Jon] OK. The TTL is defined at,=20 > > > > > > > > > > > > > > > > associated with the IP address level > > > > > > > > > > > > > > > under alt- > > > > > > > > > > > > > > > > server-record, not under=20 > > > > > > > > > > > > > > > > = ietf-dots-signal-channel:redirected-signal. > > The ttl > > > > > > > > > definition is > > > > > > > > > > > > > > > > ambiguous as to what it refers to and=20 > > > > > > > > > > > > > > > > perhaps could be tightened up in the=20 > > > > > > > > > > > > > > > > language (I read it as being associated=20 > > > > > > > > > > > > > > > > with "addr" in the sense of a DNS > > > > > > > > > > > > > > > TTL). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Do we need to keep the existing Client = > > > > > > > > > > > > > > > > > to Server A session warm (or perhaps=20 > > > > > > > > > > > > > > > > > to probe > > > > > > > > > > > > > > > > > periodically) to see if Server A is=20 > > > > > > > > > > > > > > > > > capable of handling the Client again=20 > > > > > > > > > > > > > > > > > by a server response extension to the=20 > > > > > > > > > > > > > > > > > protocol (e.g. a > > > > > > > > > > > > > > > > > 3.01) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [Med] Redirect was initially introduced=20 > > > > > > > > > > > > > > > > to manage a server overload, so I > > > > > > > > > > > > > > > don't > > > > > > > > > > > > > > > > think it makes sense to probe or=20 > > > > > > > > > > > > > > > > maintain a session with > > > > > > > > server > > > > > > > > > A. > > > > > > > > > > > > > > > > [Jon] Agreed, but I needed to raise the > > question. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Should there be a retry period=20 > > > > > > > > > > > > > > > > > parameter added in to the > > > > > > > > > > > > > > > > > 3.00 protocol (as I read it, ttl only=20 > > > > > > > > > > > > > > > > > refers to the IP > > > > > > > > > address)? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [Med] The client will automatically=20 > > > > > > > > > > > > > > > > switch to Server A when all alternate > > > > > > > > > > > > > > > records > > > > > > > > > > > > > > > > expire. > > > > > > > > > > > > > > > > [Jon] OK - again the 4.6 text needs to=20 > > > > > > > > > > > > > > > > get tightened up to reflect this as > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > intent. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Usability #2 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Server A says "Redirect to Server B"=20 > > > > > > > > > > > > > > > > > due to > > > > > > overloading. > > > > > > > > > > > > > > > > > Server B accepts things for a while=20 > > > > > > > > > > > > > > > > > and then is instructed/decides to=20 > > > > > > > > > > > > > > > > > redirect traffic > > back to A. > > > > > > > > > > > > > > > > > Server A is left still overload=20 > > > > > > > > > > > > > > > > > configured to redirect to B. How=20 > > > > > > > > > > > > > > > > > should the client handle this as there = > > > > > > > > > > > > > > > > > is no suitable > > > > > > > > > > > > > > > > Server? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [Med] This is a service configuration problem. > > > > > > > > > > > > > > > > We may > > > > > > ask: > > > > > > > > > > > > > > > > * the client to log the error and notify = > > > > > > > > > > > > > > > > the > > > > > > > administrator. > > > > > > > > > > > > > > > > * and/or stop the redirection after n cycles. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Still, this does not solve the problem. > > > > > > > > > > > > > > > > [Jon] Agreed there is a problem here > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I agree that there needs to be=20 > > > > > > > > > > > > > > > > > co-ordination between Server A and=20 > > > > > > > > > > > > > > > > > Server B, but user error may > > > > > > creep in. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Usability #3 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Server A says "Redirect to Server B"=20 > > > > > > > > > > > > > > > > > as it going to be shut down because of = > > > > > > > > > > > > > > > > > maintenance. Server B accepts things=20 > > > > > > > > > > > > > > > > > for a while and then is instructed (in = > > > > > > > > > > > > > > > > > probable user > > > > > > > > > > > > > > > > > error) to redirect traffic back to A=20 > > > > > > > > > > > > > > > > > (perhaps because it has hit an=20 > > > > > > > > > > > > > > > > > overload condition). How should the=20 > > > > > > > > > > > > > > > > > client > > > > > > > > > > > > > > > > handle this? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [Med] Isn't this a sub-case or #2? > > > > > > > > > > > > > > > > [Jon] Yes, but I wanted to bring in=20 > > > > > > > > > > > > > > > > Server A being alive and able to > > > > > > > > > > > > > > > respond > > > > > > > > > > > > > > > > versus Server A down and not responding=20 > > > > > > > > > > > > > > > > due to > > > > > > > maintenance. > > > > > > > > > > > > > > > > [Jon] With my better understanding of=20 > > > > > > > > > > > > > > > > TTL we still have an issue if the TTL=20 > > > > > > > > > > > > > > > > expires and Server A is having an=20 > > > > > > > > > > > > > > > > extended > > > > > > > > > outage. > > > > > > > > > > > > > > > > How do we recover from that? > > > > > > > > > > > > > > > > ~jon > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ______________________________________ > > > > > > > > > > > > > > > > > __ __ __ ___ Dots mailing list=20 > > > > > > > > > > > > > > > > > Dots@ietf.org=20 > > > > > > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/ > > > > > > > > > > > > > > > > > do > > > > > > > > > > > > > > > > > ts > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ________________________________________ > > > > > > > > > > > > > > > > __ __ __ _ Dots mailing list=20 > > > > > > > > > > > > > > > > Dots@ietf.org=20 > > > > > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/do > > > > > > > > > > > > > > > > ts > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ________________________________________ > > > > > > > > > > > > > > > > __ __ __ _ Dots mailing list=20 > > > > > > > > > > > > > > > > Dots@ietf.org=20 > > > > > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/do > > > > > > > > > > > > > > > > ts > > > > > > > > > > > > > > > > > > > > > > > > > > > > ____________________________________________ > > > > > > > > > > > > > > __ _ Dots mailing list Dots@ietf.org=20 > > > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > Dots mailing list Dots@ietf.org=20 > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > Dots mailing list > > > > > > > > > Dots@ietf.org > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Dots mailing list > > > > > > > > Dots@ietf.org > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Dots mailing list > > > > > > Dots@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > _______________________________________________ > > > > > Dots mailing list > > > > > Dots@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > _______________________________________________ > > > > > Dots mailing list > > > > > Dots@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Mon Apr 9 03:32:52 2018 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 A6776126DCA for ; Mon, 9 Apr 2018 03:32:50 -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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 T_tNB9FBgLBV for ; Mon, 9 Apr 2018 03:32:46 -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 3CF2512DA1D for ; Mon, 9 Apr 2018 03:32:46 -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=1523269945; 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: dlp-product:dlp-version:dlp-reaction: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-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: 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=4 hDk06Jx7tyE3fKMspYQfxZJej0waVCwmUegzl0f7h A=; b=DGosDzEAGW3XfTcczQZ7Q/+lzbP3S6jqBW4pystm0m1o 3GEBwS2/+uAP/D9grKp2EJs8XgrJfHTFEbHUXL7gK+6UXB/xvZ QsVwOUGweJYu3r6Z20aPvHqZBnHgpTamAZ27NPM5xQi5Qc7SA/ 1wxa+VjEqNrOEy4yDRNk6H4sS8A= Received: from DNVEXAPP1N04.corpzone.internalzone.com (unknown [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 16d2_8512_f79549ad_06ef_4120_a2b7_3391fe976c08; Mon, 09 Apr 2018 05:32:25 -0500 Received: from DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 9 Apr 2018 04:32:14 -0600 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Mon, 9 Apr 2018 04:32:14 -0600 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (10.44.176.240) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 9 Apr 2018 04:32:14 -0600 Received: from BN6PR16MB1425.namprd16.prod.outlook.com (10.172.207.19) by BN6PR16MB1809.namprd16.prod.outlook.com (10.172.28.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.653.12; Mon, 9 Apr 2018 10:32:13 +0000 Received: from BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d]) by BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d%2]) with mapi id 15.20.0653.015; Mon, 9 Apr 2018 10:32:12 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: [Dots] IETF 101 Presentation Data Channel Issue #4 Thread-Index: AdPE/QAkDtOD9YeqSAaov9+szxQnSQAoMdfAAAKPC+AAA+QiAAAEVj7wAfiJ0YAAA7+48AABBD0AAByNZ3AAbRM0AAABj4SQ Date: Mon, 9 Apr 2018 10:32:12 +0000 Message-ID: References: <008401d3c4fd$216d0840$644718c0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF1067@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <014801d3c5b7$94c67f00$be537d00$@jpshallow.com> <009a01d3cdab$150b4c40$3f21e4c0$@jpshallow.com> <00cf01d3cdbe$24876650$6d9632f0$@jpshallow.com> <01fd01d3cfe4$a71b6580$f5523080$@jpshallow.com> In-Reply-To: <01fd01d3cfe4$a71b6580$f5523080$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR16MB1809; 7:c01cm9JzZXq08tHUtzH+mtWZNmwJvH3sIEsd/+RPInzcOnH0hzeVIaILpwhpw0X2bgDXGpmQg0RsUrzdsghJlSO+T+RyZHz2LJUjsIMujXdK7seKO6J3zv6lTgwTu61fvQ6GtzbltIXOLUmJZBxz69wf5I7lKt0dqpt0uplNtYMZfDxa2aNdkbtWlUz3XhykZ7XLv5vGIaT5N8JzcUhUkaMn8FJgW96JQJUsQszh+vwJkxLflLrudXgy/MAe9pv+ x-ms-exchange-antispam-srfa-diagnostics: SOS; X-MS-Office365-Filtering-Correlation-Id: 472a6b14-c425-482e-f7f4-08d59e05283c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BN6PR16MB1809; x-ms-traffictypediagnostic: BN6PR16MB1809: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(192374486261705)(18271650672692)(21748063052155)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231221)(944501327)(52105095)(3002001)(10201501046)(93006095)(93001095)(6041310)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(6072148)(201708071742011); SRVR:BN6PR16MB1809; BCL:0; PCL:0; RULEID:; SRVR:BN6PR16MB1809; x-forefront-prvs: 0637FCE711 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(346002)(39380400002)(396003)(39860400002)(376002)(5383002)(32952001)(199004)(189003)(59450400001)(53546011)(81156014)(345774005)(80792005)(6306002)(8676002)(68736007)(86362001)(6436002)(3280700002)(236005)(76176011)(55016002)(9686003)(54896002)(6246003)(53936002)(53946003)(102836004)(5660300001)(229853002)(11346002)(446003)(26005)(186003)(93886005)(486006)(99286004)(81166006)(5250100002)(74316002)(97736004)(2201001)(7736002)(476003)(9326002)(106356001)(110136005)(2906002)(2900100001)(6116002)(790700001)(25786009)(8936002)(14454004)(33656002)(3660700001)(6506007)(478600001)(2501003)(316002)(105586002)(72206003)(19609705001)(66066001)(7696005)(3846002)(91024005)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR16MB1809; H:BN6PR16MB1425.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: lMH6XRwk+kyltwpmE7zQ9Y5GM6ywF9U2Y+2veDP4w/MAhC50ivjejqvI67nINXcXF/N3eP6A03HehD26tHmRacTe4eG139EJEXyyRzRCJT6DD9OlfVmKJDIj3LtZbwdwulgvQq0y3RdnWbhAGfZDpMDmqfMCPUo+KM0JEgR2P2ZOZEGJKX551k5Jcil6s8RC4x6V94s5Efi6m8IKGybOkpePaEIrAVoIuClL9R7fUCjNtbsDjh9y/dP5T68yqrR/nd8RFq2Q9BTGSF15UlK6GbwqqLlkxYgdMK3HEtFvoO903djyvK1fYD3VtIhe0W31YZ5XjoI7jqObBEUNw464uVylTHpD9/cMvv6EUCFykNOOE7j676EIUWIdeXCuCQsBzuJr49Y1B6Sb2vQ63LGtiBk7nuOmhnLlKA+ug65YV+I= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR16MB14259E953295E1CC91B895DDEABF0BN6PR16MB1425namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 472a6b14-c425-482e-f7f4-08d59e05283c X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2018 10:32:12.7250 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR16MB1809 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 <6259> : inlines <6554> : streams <1783535> : uri <2622453> Archived-At: Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 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, 09 Apr 2018 10:32:51 -0000 --_000_BN6PR16MB14259E953295E1CC91B895DDEABF0BN6PR16MB1425namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jon, Please see inline From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Monday, April 9, 2018 2:55 PM To: Konda, Tirumaleswar Reddy ; mohamed= .boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 Hi Tiru, If a DOTS client knows the full scope of the Networks that it is allowed to= use in a ACL or mitigate request, and the DOTS server limits any update fr= om that client to the scope of Networks (with any unexpected side effects t= hat may have), then there is no difference in my mind as to whether the DOT= S clients fills in the destination-network, or the DOTS server does so on t= he DOTS client's behalf before ACL instantiation if destination-network is = not defined. [TR] The above model only works when the DOTS server and DOTS client are di= rectly communicating with each other (In the above, the DOTS server knows t= he DOTS client identity to enforce the scope but will not the DOTS client i= dentity in the presence of a client-domain DOTS gateway). For a client behind a client domain DOTS gateway, there may be non public I= P addresses that the (DMS) client is responsible for, but these should neve= r be sent out through the DOTS gateway (and should be rejected by the DOTS = server as out of scope). There does have to be a common agreement between = DOTS client & DOTS server as to what Networks are in scope, but the DOTS cl= ient currently cannot request this from the DOTS server and has to be agree= d out of band. [TR] I don't see a new problem, even when a DOTS client sends a mitigation = request it needs to know if the targets conveyed in the mitigation request = are in its scope or not. There is no reason as to why the DOTS server cannot maintain a valid scope = of Networks that the client domain DOTS gateway is allowed to request for v= alidity checking - unless I am missing something? [TR] You are partially right, the DOTS server does not know the valid scope= of prefixes that a DOTS client behind client-domain DOTS gateway is allowe= d to request. Troubleshooting has kept me in a job for more years than I care to remember= , anything to aid troubleshooting is what I am interested in and so totally= agree that rogue DOTS client's capabilities need to be kept under control = with suitable logging to aid diagnosis is a major plus. However in this ca= se, the implicit rule is no different to the DOTS client requesting the ful= l Networks scope in an ACL request. [TR] If the client is not authorized to request the full network scope, it = can detected by the client-domain DOTS gateway and rejects the filtering ru= le by comparing the destination-networks specified in the ACE. -Tiru Regards Jon From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Konda@mcafee.com= ] Sent: 07 April 2018 06:48 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 Hi Jon, DOTS clients (intelligent DDoS mitigation system, application server) will = know the destination networks, what kind of DOTS clients will not know the = destination networks they are allowed to use ? DOTS clients could be behind client-domain DOTS gateway, DOTS server will h= ave no way to validate the DOTS client identity sending the ACE request to = determine the destination IP addresses in its scope, it will only know the = destination IP addresses in the DOTS client domain scope. Further, the implicit rule can be misused by compromised DOTS clients (e.g.= black-list good traffic to the entire DOTS client domain) and it's a trou= bleshooting nightmare to find the culprit device adversely impacting the en= tire network. Cheers, -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Friday, April 6, 2018 9:14 PM To: Konda, Tirumaleswar Reddy >; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 Hi Tiru, The DOTS server is likely to have a scope of IP addresses that are valid fo= r the client to ask for protection for based on the cuid or cdid. The DOTS client may have some knowledge of the scope IPs by some out of ban= d method, but programmatically cannot ask the server what they are. If a client specifies a destination network that is out of the valid scope = of IP addresses, then the ACE request will get rejected. The client may th= en have a challenge to work out what destination networks it is allowed to = use. How does a client set up a blacklist for all the IPS within his allowed sco= pe if it does not know what the scope is? If the client has not provided a destination network, then the DOTS server = can auto-fill in the missing information at the time of the ACE instantiati= on - and this then handles if the scope of IP addresses change. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 06 April 2018 16:19 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 I don't understand how the DOTS server/mitigation will fill it in at time o= f ACE instantiation, and why can't the DOTS client fill the destination net= work details ? -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Friday, April 6, 2018 6:58 PM To: Konda, Tirumaleswar Reddy >; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 Hi there, There is no current way to request of a DOTS Server as to what is the set o= f IP networks that a DOTS client can use either within a mitigation request= or to set up an ACL other than by "testing for ok or not ok" with lots of = different IP addresses. There is a reasonable likelihood of the scope of valid IPs from the Server'= s perspective will change over time. So, unless a DOTS client wants to con= trol a specific destination network, then my suggestion would be to leave t= he ACE destination network empty and for the DOTS Server / DOTS mitigator (= how is out of scope) to fill it in at time of ACE instantiation. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 27 March 2018 13:49 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 Please see inline [TR] From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Tuesday, March 27, 2018 4:07 PM To: Konda, Tirumaleswar Reddy >; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 Hi Tiru / Med See inline [Jon] Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 27 March 2018 09:47 To: mohamed.boucadair@orange.com; Jon = Shallow; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 I also support to mandate destination-network for immediately enforced filt= ering rules. [Jon] This can be enforced / inserted by the DOTS Server for all the destin= ation networks of the domain that the DOTS client 'belongs' to. That said,= it would be good to always have the destination network in an ACL as it ca= n be validated and cross-checked whenever the legitimate set of domain prot= ected IPs are updated. [Jon] However, what happens to the Destination network in the case of a cal= l home DOTS client that becomes a quasi DOTS server and the Destination net= works are somewhere out on the Internet? [TR] DDOS is a targeted attack, so the DOTS client can specify the destinat= ion network targeted by devices in the DOTS server domain and the DOTS serv= er can validate if the destination network is indeed targeted by its device= s. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed...boucadair@= orange.com Sent: Tuesday, March 27, 2018 1:09 PM To: Jon Shallow >; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 Hi Jon, Thank you for the comments. Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : lundi 26 mars 2018 14:23 =C0 : dots@ietf.org Objet : [Dots] IETF 101 Presentation Data Channel Issue #4 Hi there, As per Med's presentation to the IETF 101 Issue #4: Per-Domain or Per-client Filters? * Conclusion - Filters that are activated only during mitigation time are on a per-clien= t basis * Filters are per-domain when are immediately applied "Filters are per-domain when are immediately applied" is what I have an cha= llenge with. If we have a compromised or rogue DOTS client, the simple use of something = like curl, along with the client certificates etc. can be used to generate = any ACL with activation-type :=3D 'immediate' which is then immediately app= lied for all traffic within the domain as per the above. [Med] Yes. FWIW, this attack is called out in the security considerations s= ection: "Nevertheless, an attacker who can access a DOTS client is technically capable of launching various attacks, such as: ..; o Set invalid ACL entries, which may prevent legitimate traffic from being forwarded. Likewise, invalid ACL entries may lead to forward DDoS traffic. " [Jon] Agreed that the attack is covered off in the Security section, but we= should be limiting the possibility / scope of the attack vector by enforci= ng some rules as to what is / is not allowed. Allowing a DOTS client to be= able to affect all the traffic within the domain is a huge risk to me and = should not be allowed. So, a ACL that blacklists the DNS server, or drops all port 443 traffic etc= . can easily cause all of the other clients / devices within the domain to = be taken off air. Putting the intelligence into the DOTS server to not all= ow this to happen could be a challenge. [The signal channel is much harder to compromise and affect traffic flows t= o other areas within the domain] I believe that an ACL instantiated by a DOTS client (immediate or when-miti= gating) should only apply to the DOTS client's traffic which means that the= destination-network has to be a part of the ACL, whether implicitly added = by the DOTS server, or by the DOTS client and suitably validated. [Med] Putting aside that I don't parse "DOTS client's traffic", [Jon] I was referring to all the traffic flows that a DOTS client can legit= imately request control of to the DOTS server that are within the scope of = what the DOTS client is protecting (which may or may not be the DOTS client= 's IP address). I interpret your answer as a support to this question raised for issue #4: * "Should we mandate destination-network to be present for immediate= ly enforced filters?" [Jon] See response to Tiru's Agreement above. ~Jon There is nothing to stop the DOTS server or DOTS mitigator merging common A= CLs to reduce the number of ACLs within the mitigation device. As a side note "mitigation-time" is perhaps a bad name as it implies a time= period - something like "when-mitigating" to me is clearer. [Med] Fixed in my local copy. Thank you. Regards Jon --_000_BN6PR16MB14259E953295E1CC91B895DDEABF0BN6PR16MB1425namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jon,

&nbs= p;

Please se= e inline

 

From:<= /span> Jon Shallow [mailto:s= upjps-ietf@jpshallow.com]
Sent: Monday, April 9, 2018 2:55 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; mohamed.boucadair@orange.com; dots@ietf.org
Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Hi Tiru= ,

&n= bsp;

If a DO= TS client knows the full scope of the Networks that it is allowed to use in= a ACL or mitigate request, and the DOTS server limits any update from that= client to the scope of Networks (with any unexpected side effects that may have), then there is no difference in= my mind as to whether the DOTS clients fills in the destination-network, o= r the DOTS server does so on the DOTS client’s behalf before ACL inst= antiation if destination-network is not defined.

 

[TR] The above model only works= when the DOTS server and DOTS client are directly communicating with each = other (In the above, the DOTS server knows the DOTS client identity to enfo= rce the scope but will not the DOTS client identity in the presence of a client-domain DOTS gateway).

&n= bsp;

For a c= lient behind a client domain DOTS gateway, there may be non public IP addre= sses that the (DMS) client is responsible for, but these should never be se= nt out through the DOTS gateway (and should be rejected by the DOTS server as out of scope).  There does have to = be a common agreement between DOTS client & DOTS server as to what Netw= orks are in scope, but the DOTS client currently cannot request this from t= he DOTS server and has to be agreed out of band.

 

[TR] I don’t see a new pr= oblem, even when a DOTS client sends a mitigation request it needs to know = if the targets conveyed in the mitigation request are in its scope or not.<= o:p>

 

There i= s no reason as to why the DOTS server cannot maintain a valid scope of Netw= orks that the client domain DOTS gateway is allowed to request for validity= checking – unless I am missing something?

 

[TR] You are partially right, t= he DOTS server does not know the valid scope of prefixes that a DOTS client= behind client-domain DOTS gateway is allowed to request.=

&n= bsp;

Trouble= shooting has kept me in a job for more years than I care to remember, anyth= ing to aid troubleshooting is what I am interested in and so totally agree = that rogue DOTS client’s capabilities need to be kept under control with suitable logging to aid diagnosis is a = major plus.  However in this case, the implicit rule is no different t= o the DOTS client requesting the full Networks scope in an ACL request.

 

[TR] If the client is not autho= rized to request the full network scope, it can detected by the client-doma= in DOTS gateway and rejects the filtering rule by comparing the destination= -networks

     &= nbsp;  specified in the ACE.

 

-Tiru

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Kon= da@mcafee.com]
Sent: 07 April 2018 06:48
To: Jon Shallow; moh= amed.boucadair@orange.com; dots@ietf.org
Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Hi Jon,

&nbs= p;

DOTS clie= nts (intelligent DDoS mitigation system, application server) will know the = destination networks, what kind of DOTS clients will not know the destinati= on networks they are allowed to use ?

DOTS clie= nts could be behind client-domain DOTS gateway, DOTS server will have no wa= y to validate the DOTS client identity sending the ACE request to determine= the destination IP addresses in its scope, it will only know the destination IP addresses in the DOTS client d= omain scope.

Further, = the implicit rule can be misused by compromised DOTS clients (e.g. black-li= st good traffic to the entire DOTS client domain) and it’s a  tr= oubleshooting nightmare to find the culprit device adversely impacting the entire network.

&nbs= p;

Cheers,

-Tiru

&nbs= p;

From:<= /span> Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Friday, April 6, 2018 9:14 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; mohamed.boucadair@orange.co= m; dots@ietf.org
Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Hi Tiru= ,

&n= bsp;

The DOT= S server is likely to have a scope of IP addresses that are valid for the c= lient to ask for protection for based on the cuid or cdid.

&n= bsp;

The DOT= S client may have some knowledge of the scope IPs by some out of band metho= d, but programmatically cannot ask the server what they are.

&n= bsp;

If a cl= ient specifies a destination network that is out of the valid scope of IP a= ddresses, then the ACE request will get rejected.  The client may then= have a challenge to work out what destination networks it is allowed to use.

&n= bsp;

How doe= s a client set up a blacklist for all the IPS within his allowed scope if i= t does not know what the scope is?

&n= bsp;

If the = client has not provided a destination network, then the DOTS server can aut= o-fill in the missing information at the time of the ACE instantiation R= 11; and this then handles if the scope of IP addresses change.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 06 April 2018 16:19
To: Jon Shallow; moh= amed.boucadair@orange.com; dots@ietf.org
Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

I donR= 17;t understand how the DOTS server/mitigation will fill it in at time of A= CE instantiation, and why can’t the DOTS client fill the destination = network details ?

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Friday, April 6, 2018 6:58 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; mohamed.boucadair@orange.co= m; dots@ietf.org
Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Hi ther= e,

&n= bsp;

There i= s no current way to request of a DOTS Server as to what is the set of IP ne= tworks that a DOTS client can use either within a mitigation request or to = set up an ACL other than by “testing for ok or not ok” with lots of different IP addresses.=

&n= bsp;

There i= s a reasonable likelihood of the scope of valid IPs from the Server’s= perspective will change over time.  So, unless a DOTS client wants to= control a specific destination network, then my suggestion would be to leave the ACE destination network empty and for the= DOTS Server / DOTS mitigator (how is out of scope) to fill it in at time o= f ACE instantiation.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 27 March 2018 13:49
To: Jon Shallow; moh= amed.boucadair@orange.com; dots@ietf.org
Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Please se= e inline [TR]

&nbs= p;

From:<= /span> Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Tuesday, March 27, 2018 4:07 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; mohamed.boucadair@orange.co= m; dots@ietf.org
Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Hi Tiru= / Med

&n= bsp;

See inl= ine [Jon]

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 27 March 2018 09:47
To: mohamed.boucadai= r@orange.com; Jon Shallow; dots@ietf.org
Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

I also su= pport to mandate destination-network for immediately enforced filtering rul= es.

[Jon] This can be enforced / inserted by the DOTS Server for all the d= estination networks of the domain that the DOTS client ‘belongs’= ; to.  That said, it would be good to always have the destination network in an ACL as it can be validated and cross-checked= whenever the legitimate set of domain protected IPs are updated.

[Jon] However, what happens to the Destination network in the case of = a call home DOTS client that becomes a quasi DOTS server and the Destinatio= n networks are somewhere out on the Internet?

&nbs= p;

[TR] DDOS= is a targeted attack, so the DOTS client can specify the destination netwo= rk targeted by devices in the DOTS server domain and the DOTS server can va= lidate if the destination network is indeed targeted by its devices.

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed= ...boucadair@orange.com
Sent: Tuesday, March 27, 2018 1:09 PM
To: Jon Shallow <sup= jps-ietf@jpshallow.com>; dots@ietf.org
Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Hi Jon,

 

Thank you for the comments.<= /p>

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow
Envoy=E9 : lundi 26 mars 2018 14:23
=C0 : dots@ietf.org
Objet : [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Hi there,

 

As per Med’s presentation= to the IETF 101

 

Issue #4: Per-Domain or Per-cli= ent Filters?

 

• Conclusion

– Filters that are activa= ted only during mitigation time are on a per-client basis=

   • Filters ar= e per-domain when are immediately applied

 

“Filters are per-domain w= hen are immediately applied” is what I have an challenge with.

 

If we have a compromised or rog= ue DOTS client, the simple use of something like curl, along with the clien= t certificates etc. can be used to generate any ACL with activation-type := =3D ‘immediate’ which is then immediately applied for all traffic within the domain as per the above.

 

[Med] Yes. FWIW, this attack is= called out in the security considerations section:

 

“Nevertheless,=
 an

   attacker who can acce= ss a DOTS client is technically capable of

   launching various att= acks, such as:

 

..;

 

   o  Set invalid ACL entries, which may prevent legiti=
mate traffic from
      being forwarded.  Likewise, invali=
d ACL entries may lead to
      forward DDoS traffic.=

“

[Jon] A= greed that the attack is covered off in the Security section, but we should= be limiting the possibility / scope of the attack vector by enforcing some= rules as to what is / is not allowed.  Allowing a DOTS client to be able to affect all the traffic within the dom= ain is a huge risk to me and should not be allowed.

 

So, a ACL that blacklists the D= NS server, or drops all port 443 traffic etc. can easily cause all of the o= ther clients / devices within the domain to be taken off air.  Putting= the intelligence into the DOTS server to not allow this to happen could be a challenge.

[The signal channel is much har= der to compromise and affect traffic flows to other areas within the domain= ]

 

I believe that an ACL instantia= ted by a DOTS client (immediate or when-mitigating) should only apply to th= e DOTS client’s traffic which means that the destination-network has = to be a part of the ACL, whether implicitly added by the DOTS server, or by the DOTS client and suitably validated.

 

[Med] Putting aside that I don&= #8217;t parse “DOTS client’s traffic”,

[Jon] I= was referring to all the traffic flows that a DOTS client can legitimately= request control of to the DOTS server that are within the scope of what th= e DOTS client is protecting (which may or may not be the DOTS client’s IP address).

I interpret your answer as a su= pport to this question raised for issue #4:

    • “Should we mandate destination-network to be present for immediately enforced filters?”

[Jon] S= ee response to Tiru’s Agreement above.

~Jon

There is nothing to stop the DO= TS server or DOTS mitigator merging common ACLs to reduce the number of ACL= s within the mitigation device.

 

As a side note “mitigatio= n-time” is perhaps a bad name as it implies a time period – som= ething like “when-mitigating” to me is clearer.

[Med] Fixed in my local copy. T= hank you.

 

Regards

 

Jon

--_000_BN6PR16MB14259E953295E1CC91B895DDEABF0BN6PR16MB1425namp_-- From nobody Mon Apr 9 03:48:32 2018 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 484EC12778D for ; Mon, 9 Apr 2018 03:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 IOaHHv2UwE40 for ; Mon, 9 Apr 2018 03:48:25 -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 20959126BF6 for ; Mon, 9 Apr 2018 03:48:24 -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=1523270904; 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: dlp-product:dlp-version:dlp-reaction: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-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-Network-Message-Id: 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=l KaKjSGNvb0+sK/+M8GsZFzbsR2nJoB81lvov0FyUK A=; b=fkKZQBBU5vd96/fFnQZsnTe7QZWuzLXgYhF/k7bmKIg9 FuwGepFaj7mllOwguhvrBUF2DoahH67lOsDES2U3EeaHLpr2pS Azkf0Lia/AubdxksZco/1PE/H8zU2NuM5/G0R5qRcyOFt/ADJZ xF/Tn/CNbekP2M5OqviqfPM/Ra0= Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 16d2_8e29_cf5bde4b_0fbc_480e_ad41_3a96e8babbf4; Mon, 09 Apr 2018 05:48:23 -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; Mon, 9 Apr 2018 04:47:58 -0600 Received: from DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) by DNVEXUSR1N11.corpzone.internalzone.com (10.44.48.84) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 9 Apr 2018 04:47:57 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Mon, 9 Apr 2018 04:47:57 -0600 Received: from NAM03-BY2-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.1347.2; Mon, 9 Apr 2018 04:47:55 -0600 Received: from BN6PR16MB1425.namprd16.prod.outlook.com (10.172.207.19) by BN6PR16MB1363.namprd16.prod.outlook.com (10.172.206.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.653.12; Mon, 9 Apr 2018 10:47:55 +0000 Received: from BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d]) by BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d%2]) with mapi id 15.20.0653.015; Mon, 9 Apr 2018 10:47:55 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: [Dots] Signal Channel - 300 Redirected Signaling Thread-Index: AdPMGSyCaQQbv+vLSW+0gkDbU7HOEwAAo7xAAAH7T4AAARdqYAAhoxEAAAGQiwAAAKyNYAAF3e1QACUKCFAAAZEMQAAIeXTgAARcGhAAAoG7gAABGXwAAAAjBIAAAa5ZgAAAiReAAABpmzAAL32aAABWbPEwAAIv/gAAAPiKMAAA7T0AAACbH4AAAR48IAAB3xeAAABzdxA= Date: Mon, 9 Apr 2018 10:47:54 +0000 Message-ID: References: <014f01d3cc19$2e3880e0$8aa982a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7E7B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <019901d3cc23$a93ff8e0$fbbfeaa0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8524@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <004e01d3ccb4$d505e7f0$7f11b7d0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8758@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEF912A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEF93EE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <008501d3cda6$c860d210$59227630$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF951 1@OPEXCLILMA 3 . corporate.adroot.infra.ftgroup> <00b001d3cdab$ba8caec0$2fa60c40$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF975C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <00b801d3cdb4$982dc4a0$c8894de0$@jpshallow.com> <015101d3ce74$351393c0$9f3abb40$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEFA190@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <01f501d3cfde$4014ca30$c03e5e90$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEFA2DF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <022901d3cfec$a1aa2430$e4fe6c90$@jpshallow.com> In-Reply-To: <022901d3cfec$a1aa2430$e4fe6c90$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR16MB1363; 7:OrxDzlimM7ritt97aB5GoYf35/Vf344SxYuMxxnV7PQWnWOIvrMHtZ56ZsVUicMv3bIhaAWc9cM9l9C2ZUNPDtOFYsxQ1td3HkqGkzCq6EIgorzt34BemuDaeKV++Evam9y1NX/P8qteSW8KD0QDAYKqQ48UBxrgSFz9qWusUMFod8sGkTUi8rEJPsKjIFNPrwFbm79nL6pQISVon9QyXGg94deI6g8FTBla2Y8tyZ0hx1dJ4vbqSBHe6dKVVAYK x-ms-exchange-antispam-srfa-diagnostics: SOS; X-MS-Office365-Filtering-Correlation-Id: 5c3676bd-860a-4c94-b053-08d59e0759d8 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BN6PR16MB1363; x-ms-traffictypediagnostic: BN6PR16MB1363: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(166708455590820)(788757137089)(18271650672692)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231221)(944501327)(52105095)(3002001)(10201501046)(93006095)(93001095)(6041310)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(6072148)(201708071742011); SRVR:BN6PR16MB1363; BCL:0; PCL:0; RULEID:; SRVR:BN6PR16MB1363; x-forefront-prvs: 0637FCE711 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39380400002)(396003)(376002)(39860400002)(366004)(55784002)(57704003)(189003)(199004)(32952001)(13464003)(53754006)(51444003)(2501003)(53936002)(106356001)(486006)(2201001)(966005)(446003)(11346002)(80792005)(476003)(86362001)(5660300001)(110136005)(74316002)(102836004)(33656002)(8676002)(97736004)(2900100001)(6506007)(316002)(53546011)(99286004)(229853002)(7736002)(6436002)(305945005)(59450400001)(9686003)(72206003)(76176011)(105586002)(186003)(53946003)(68736007)(6246003)(25786009)(3280700002)(16200700003)(5250100002)(81156014)(7696005)(478600001)(14454004)(6116002)(8936002)(3660700001)(55016002)(3846002)(93886005)(6306002)(2906002)(81166006)(26005)(66066001)(85282002)(579004)(559001)(569006); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR16MB1363; H:BN6PR16MB1425.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 4dmiwRBx+hNQ5Dpl1SCyuI/L6Q7YxUsV1vQ75CYjcGR2a6aZs42RzmtBZMvwt9KJ+AL/cAvRcDACqLe+RgAZRUrdbwa9uvZRiPca2uqZHJ05p+q3TBaRfwKABk1DU1OVmb+7zLMWrlhOziWy6kiGueMzivutPnDTRDR4ocNpm+NpumUzi/fLVGPmBXF9H2R9P5vMUca6W7qDY+dmoPXgFrZ5cqo4ic0UJu8Pj7F89sMQL9DJmgtTDdLmzDc0cKMHG7Csszwx3HNeb9cISjOPqb38uHMJvwkXJLSxPCD0QdvfJ+TP7spcIwcnGhDUvynEIRhm4PyAz3w5wnOzmJClEWnPbKaAFfWkNOdxMvWGeVt7Xj+dwd1fOtTK287GgaTRm1ix2BtIPHv/JteNECwjtlItKOLQqCv+Wty1YSQiJB0= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 5c3676bd-860a-4c94-b053-08d59e0759d8 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2018 10:47:54.9283 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR16MB1363 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 <6259> : inlines <6554> : streams <1783535> : uri <2622461> Archived-At: Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling 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, 09 Apr 2018 10:48:30 -0000 > -----Original Message----- > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > Sent: Monday, April 9, 2018 3:52 PM > To: Konda, Tirumaleswar Reddy ; > mohamed.boucadair@orange.com; dots@ietf.org > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling >=20 > Hi Tiru/Med, >=20 > See inline [Jon2] >=20 > Regards >=20 > Jon >=20 > > > -----Message d'origine----- > > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > Envoy=E9=A0: lundi 9 avril 2018 10:39 > > > =C0=A0: 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; > > > dots@ietf.org Objet=A0: RE: [Dots] Signal Channel - 300 Redirected > > > Signaling > > > > > > Hi all, > > > > > > Should 'ttl' actually be 'lifetime' to remove any confusion over whet= her > > > this is DNS TTL usage or not ? > > > > [Med] we do already have a lifetime in the cbor mapping table. So, I > > suggest to maintain ttl but focus on its definition to avoid confusion. >=20 > Agreed. >=20 > > > > > > > > Otherwise see inline [Jon] > > > > > > Regards > > > > > > Jon > > > > > > -----Original Message----- > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, > > > Tirumaleswar Reddy > > > Sent: 09 April 2018 09:23 > > > To: mohamed.boucadair@orange.com; Jon Shallow; dots@ietf.org > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > -----Original Message----- > > > > From: mohamed.boucadair@orange.com > > > > [mailto:mohamed.boucadair@orange.com] > > > > Sent: Monday, April 9, 2018 1:15 PM > > > > To: Konda, Tirumaleswar Reddy > > > > ; > > > > Jon Shallow ; dots@ietf.org > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > Tiru, > > > > > > > > What about this update ones? > > > > > > > > =3D=3D=3D=3D=3D=3D=3D > > > > ttl: Time to live (TTL) of the alternate DOTS server, > > > > represented > as > > > > an integer number of seconds. That is, the time interval > > > > that > the > > > > alternate DOTS server may be cached for use by a DOTS client. > > > > > > > > A lifetime of negative one (-1) indicates indefinite TTL. Th= is > > > > value means that the alternate DOTS server is to be used > > > > until > the > > > > alternate DOTS server redirects the traffic with another 3.00 > > > > response. > > > > > > > > If no 'ttl' is returned in a redirect response, this is > equivalent > > > > to returning a 'ttl' parameter set to '-1'. > > > > > > Above text looks good. > > > > > > [Jon] Later in the text, there is reference to a minimum of 5 > > > minutes before being able to switch back to the original DOTS > > > server. Don't we need to say a 5 minute (300 secs) minimum here? > > > > [Med] That reference is when explicit redirect signals are involved. >=20 > Yup. >=20 > > > > > > > > > > > > > If the alternate DOTS server TTL has expired, the DOTS > > > > client > MUST > > > > use the DOTS server(s), that was provisioned using means > discussed > > > > in Section 4.1, for creating new requests. > > > > > > It looks too restrictive, typically the DNS TTL values are > > > short-lived (e.g.. few seconds) but the sessions are long-lived. > > > Why not replace "for creating new requests" with "for creating new > > > DOTS session" ? > > > > > > [Jon] I think that once the alternate DOTS server's lifetime has > > > expired, the DOTS client should try to establish a connection with > > > the appropriate "normal" DOTS servers, > > > > [Med] Bingo. >=20 > No, DNS TTL lifetime does not mean existing session has to be disconnect= ed > after the TTL expires. >=20 > [Jon2] I guess that I am missing something here. A DOTS client, when usi= ng a > resolver library, has no knowledge of when an IP's DNS TTL will expire or= has > expired - a lookup request to the library may or may not refresh the rema= ining > TTL. Yes, the resolver library is only called for new DOTS session.=20 >=20 > [Jon2] However, I thought that TTL referred to the alternate DOTS server > lifetime and now had nothing to do with DNS TTL. No, It is DNS TTL to handle the scenario when DNS server is not available. >=20 > [Jon2] My text immediately below implies that the current session should = only > get disconnected if the DOTS client is able to start using another (likel= y to be the > original) DOTS server. I don't see the need to disconnect existing session just because DNS TTL ex= pires.=20 -Tiru >=20 > -Tiru >=20 > > > > if that fails, continue to use the alternate DOTS > > > server, but periodically retry the "normal" servers to try to > > > maintain resilience of service. > > > > [Med] The document does not specify the behavior for selecting among > > multiple servers. So, this details are out of scope. >=20 > [Jon2] Agreed the details are out of scope, but would follow the lines of= " > the DOTS client MUST > use the DOTS server(s), that was provisioned using means discussed > in Section 4.1, for creating new requests." > ~jon2 > > > > After all, the outage (e.g. maintenance window) of > > > the original DOTS server may have to be extended, and being down, > > > cannot respond with a 3.00 to instruct DOTS client to stay with the > > > alternate DOTS server. > > > > > > > [Med] For such cases, it is safe to return an indefinite TTL + > > alternate server to coordinate the fallback behavior. > > > > > --Tiru > > > > > > > > > > > This is an optional attribute. > > > > =3D=3D=3D > > > > > > > > Cheers, > > > > Med > > > > > > > > > -----Message d'origine----- > > > > > De=A0: Konda, Tirumaleswar Reddy > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > Envoy=E9=A0: lundi 9 avril 2018 08:51 =C0=A0: Jon Shallow; BOUCAD= AIR > > > > > Mohamed IMT/OLN; dots@ietf.org Objet=A0: RE: > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > Hi Jon, > > > > > > > > > > I partially agree with the suggested update. A IP address is > > > > > cached until the TTL value expires, the DOTS client need not > > > > > disconnect existing sessions after the TTL expires, but after > > > > > the TTL expires it must consider the IP address stale and not > > > > > establish new (D)TLS sessions. > > > > > > > > > > Cheers, > > > > > -Tiru > > > > > > > > > > > -----Original Message----- > > > > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon > > > > > > Shallow > > > > > > Sent: Saturday, April 7, 2018 6:58 PM > > > > > > To: Konda, Tirumaleswar Reddy > > > > > > ; > > > > > > mohamed.boucadair@orange.com; dots@ietf.org > > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > Hi there, > > > > > > > > > > > > My suggestion would be to make ttl of -1 'infinite', otherwise > > > > > > have a > > > > > minimum > > > > > > value of 300 seconds. The text could read (including > > > > > > referring to the > > > > > optional > > > > > > etc. to be consistent with the rest of the document:- > > > > > > > > > > > > alt-server: FQDN of an alternate DOTS server. > > > > > > > > > > > > This is a required attribute. > > > > > > > > > > > > alt-server-record: A list of IP addresses of an alternate D= OTS > > > > > > server. > > > > > > > > > > > > This is an optional attribute. > > > > > > > > > > > > ttl: Time to live (TTL) of the alternate DOTS server, > > > > > > represented > > > as > > > > > > an integer number of seconds. That is, the time > > > > > > interval that > > > the > > > > > > alternate DOTS server may be used by a DOTS client. > > > > > > > > > > > > The minimum value is '300' seconds, or '-1'. > > > > > > > > > > > > '-1' means that the alternate DOTS server is to be used > > > > > > until the > > > > > alternate > > > > > > DOTS server redirects the traffic with another 3.00 response. > > > > > > There is no TTL expiry. > > > > > > > > > > > > If no 'ttl' is returned in a redirect response, this is > > > equivalent > > > > > > to returning a 'ttl' parameter set to '-1'. > > > > > > > > > > > > If the alternate DOTS server TTL has expired, the DOTS > > > > > > client > > > MUST > > > > > > use the DOTS server(s) that was provisioned using means > > > discussed > > > > > > in Section 4.1. > > > > > > > > > > > > This is an optional attribute. > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > Jon > > > > > > > > > > > > -----Original Message----- > > > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, > > > > > > Tirumaleswar Reddy > > > > > > Sent: 06 April 2018 15:55 > > > > > > To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org > > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > The below proposed change does not look good to me, its > > > > > > causing the DOTS client to ping-pong between multiple DOTS > > > > > > servers because of the TTL > > > > value. > > > > > > The alternate server should serve the DOTS client till there > > > > > > is a planned maintenance, if it is getting over-subscribed it > > > > > > should re-direct the new > > > > > DOTS > > > > > > clients to an alternate server and avoid bouncing the existing > > > > > > DOTS clients > > > > > which > > > > > > have been sending mitigation requests to it. > > > > > > > > > > > > -Tiru > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > > > > Sent: Friday, April 6, 2018 8:06 PM > > > > > > > To: mohamed.boucadair@orange.com; Konda, Tirumaleswar Reddy > > > > > > > ; dots@ietf.org > > > > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected > > > > > > > Signaling > > > > > > > > > > > > > > Hi Med, > > > > > > > > > > > > > > Thanks for this. I would like to see the ttl: definition > > > > > > > tightened up (moved away from the DNS TTL version) > > > > > > > > > > > > > > Old > > > > > > > > > > > > > > ttl: Time to live (TTL) of alternate records, > > > > > > > represented as > an > > > > > > > integer number of seconds. That is, the time interval > that > > > > > > > alternate IP addresses may be cached by a DOTS client. > > > > > > > > > > > > > > '0' means that an alternate IP address is only to be > > > > > > > used for > > > the > > > > > > > request in progress, and consequently that IP address > > > > > > > should > > > not > > > > > > > be cached. > > > > > > > > > > > > > > If no 'ttl' is returned in a redirect response, this > > > > > > > is > > > equivalent > > > > > > > to returning a 'ttl' parameter set to '0'. > > > > > > > > > > > > > > If 'alt-server-record' has expired, the DOTS client > > > > > > > MUST use > > > the > > > > > > > DOTS server(s) that was provisioned using means > > > > > > > discussed > in > > > > > > > Section 4.1. Furthermore, a DOTS client MUST NOT use > > > > > > > the > alt- > > > > > > > server FQDN if the 'alt-server-records' has expired. > > > > > > > > > > > > > > New > > > > > > > > > > > > > > ttl: Time to live (TTL) of the alternate DOTS server, > > > > > > > represented as > > > > > > an > > > > > > > integer number of seconds. That is, the time interval > that > > > > > > > the alternate DOTS server may be cached for use by a > > > > > > > DOTS > > > client. > > > > > > > > > > > > > > '0' means that the alternate DOTS server is only to be > > > > > > > used > > > for the > > > > > > > request in progress, and consequently the alternate > > > > > > > DOTS server entry should not > > > > > > > be cached. > > > > > > > > > > > > > > If no 'ttl' is returned in a redirect response, this > > > > > > > is > > > equivalent > > > > > > > to returning a 'ttl' parameter set to '0'. > > > > > > > > > > > > > > If the alternate DOTS server TTL has expired, the DOTS > > > > > > > client MUST > > > > > > use the > > > > > > > DOTS server(s) that was provisioned using means > > > > > > > discussed > in > > > > > > > Section 4.1. > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > > > > > > mohamed.boucadair@orange.com > > > > > > > Sent: 06 April 2018 15:21 > > > > > > > To: Jon Shallow; Konda, Tirumaleswar Reddy; dots@ietf.org > > > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected > > > > > > > Signaling > > > > > > > > > > > > > > FWIW, I implemented the change at: > > > > > > > https://github.com/boucadair/draft-ietf-dots-signal-channel/ > > > > > > > bl > > > > > > > ob > > > > > > > /m > > > > > > > aste > > > > > > > r/draf > > > > > > > t-ietf-dots-signal-channel.txt > > > > > > > > > > > > > > Cheers, > > > > > > > Med > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Jon Shallow > > > > > > > > [mailto:supjps-ietf@jpshallow.com] > > > > > > > > Envoy=E9=A0: vendredi 6 avril 2018 15:33 =C0=A0: BOUCADAIR = Mohamed > > > > > > > > IMT/OLN; Konda, Tirumaleswar Reddy; dots@ietf.org Objet=A0:= RE: > > > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > > Excellent. > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: mohamed.boucadair@orange.com [mailto: > > > > > > > > mohamed.boucadair@orange.com] > > > > > > > > Sent: 06 April 2018 14:29 > > > > > > > > To: Jon Shallow; Konda, Tirumaleswar Reddy; rdd@cert.org > > > > > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected > > > > > > > > Signaling > > > > > > > > > > > > > > > > Hi Jon, all, > > > > > > > > > > > > > > > > I'm fine to put ttl at the level of alt-server. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Med > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Jon Shallow > > > > > > > > > [mailto:supjps-ietf@jpshallow.com] > > > > > > > > > Envoy=E9=A0: vendredi 6 avril 2018 14:57 =C0=A0: BOUCADAI= R > > > > > > > > > Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; rdd@cert.org > Objet=A0: RE: > > > > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > > > > Hi there, > > > > > > > > > > > > > > > > > > See inline [Jon3] > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Konda, > > > > > > > > > > > > Tirumaleswar Reddy > > > > > > > > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > > > > > > > Envoy=E9=A0: vendredi 6 avril 2018 07:07 =C0=A0: BO= UCADAIR > > > > > > > > > > > > Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet= =A0: > RE: > > > > > > > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > > > Hi Med, > > > > > > > > > > > > > > > > > > > > > > > > The proposed update restricts the client no to do > > > > > > > > > > > > a DNS lookup using the alternate FQDN, further > > > > > > > > > > > > associating a TTL with the name complicates the > > > > > > > > > > > > functionality on the DOTS client to re-establish > > > > > > > > > > > > (D)TLS session with the primary DOTS server after > > > > > > > > > > > > the > > > > > > > > TTL expires. > > > > > > > > > > > > My suggestion is to let the DOTS client continue > > > > > > > > > > > > to use the alternate DOTS > > > > > > > > > > server > > > > > > > > > > > till it gets re-directed. > > > > > > > > > > > > > > > > > > > > > > [Med] This is possible with the current spec. > > > > > > > > > > > > > > > > > > > > > > Triggers for redirect and for falling back to the > > > > > > > > > > > nominal configuration are deployment-specific. The > > > > > > > > > > > current spec allows for almost all the cases > > > > > > > > > > discussed > > > > > > > > > > > so far: > > > > > > > > > > > > > > > > > > > > > > (1) Redirect for the request in progress: A server > > > > > > > > > > > does so by returning > > > > > > > > > > TTL=3D0. > > > > > > > > > > > (2) The alternate server is not involved in fall > > > > > > > > > > > back to the nominal > > > > > > > > > > server: upon > > > > > > > > > > > expiry of ttl of all alternate IP addresses, then > > > > > > > > > > > fall back automatically > > > > > > > > > > to the > > > > > > > > > > > nominal server. > > > > > > > > > > > (3) Redirect to an alternate server, which in turn > > > > > > > > > > > will instruct the client > > > > > > > > > > to > > > > > > > > > > > redirect to the "base" configuration: a TTL is > > > > > > > > > > > provided and the alternate > > > > > > > > > > server > > > > > > > > > > > can reply with a redirect code any time before the > > > > > > > > > > > expiry of the TTL. A > > > > > > > > > > long TTL > > > > > > > > > > > can be returned if the alternate server will be > > > > > > > > > > > responsible for > > > > > > > > > > coordinating fall > > > > > > > > > > > back to the base server. > > > > > > > > > > > (4) Stop infinite redirects > > > > > > > > > > > > > > > > > > > > Yes, but (1) and (2) complicate the functionality of > > > > > > > > > > the DOTS > > > > > > client. > > > > > > > > > > > > > > > > > > [Med] (1) and (2) is exactly the same functionality > > > > > > > > > required for caching DNS replies. > > > > > > > > > > > > > > > > > > The > > > > > > > > > > only reason for adding alt-server-record in the > > > > > > > > > > response is DNS server may not be reachable by the > > > > > > > > > > DOTS server because of a DDoS > > > > > > > attack. > > > > > > > > > > > > > > > > > > > > > > > > > > > > [Med] Yes. Note that even if the name resolution was > > > > > > > > > allowed, the client has to deal with the TTL indicated > > > > > > > > > in the response...which is exactly the same as (1) and (2= ). > > > > > > > > > > > > > > > > > > > > > > > > > > > [Jon3] I think where I am struggling here is the > > > > > > > > > overloaded use of TTL > > > > > > > > > - The TTL as per a DNS record and held as a part of > > > > > > > > > alt-server-record and then the TTL after which that the > > > > > > > > > alt-server should be handling the traffic before > > > > > > > > > handling back to the original primary server. It either > > > > > > > > > has to be one or the other, or they have to > > > > > > > have different names. > > > > > > > > > [Jon3] If we are only going to go for one variant for > > > > > > > > > simplicity, then I would prefer that it should be at the > > > > > > > > > level of "alt- > > > > server". > > > > > > > > > Handling the TTL for DNS refresh is normally handled by > > > > > > > > > a resolver library, updated by the DNS packets coming in > > > > > > > > > - unusual for an application > > > > > > > > to have to do that. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I > > > > > > > > > > > > don't think the DOTS mitigation provider will know > > > > > > > > > > > > ahead-of-time the TTL value after which the DOTS > > > > > > > > > > > > client should disconnect communicating with the > > > > > > > > > > > > alternate DOTS server and re-establish (D)TLS > > > > > > > > > > > > session with the primary DOTS > > > > > > server. > > > > > > > > > > > > > > > > > > > > > > [Med] It depends on the nature of the redirect: > > > > > > > > > > > overload, planned > > > > > > > > > > maintenance, > > > > > > > > > > > etc. For planned maintenance, the TTL is known in > general. > > > > > > > > > > > > > > > > > > > > It's the primary DOTS server responsibility to point > > > > > > > > > > the DOTS client to an optimal alternate server, where > > > > > > > > > > the client can continue to send migration requests > > > > > > > > > > without a frequent ping-pong > > > > > > > between servers. > > > > > > > > > > > > > > > > > > [Med] Agree. This is a service configuration problem. > > > > > > > > > [Jon3] Agreed - and the 5 minute minimum ping-pong time > > > > > > > > > is a good safety net. > > > > > > > > > ~jon3 > > > > > > > > > > > > > > > > > > > I have seen TURN servers being deployed for several > > > > > > > > > > years with > > > > > > > > > re-direction > > > > > > > > > > but without the need for TTL (see ALTERNATE-SERVER in > > > > > > > > > > https://tools.ietf.org/html/draft-ietf-tram-turnbis-11 > > > > > > > > > > ) > > > > > > > > > > > > > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > From: Dots [mailto:dots-bounces@ietf.org] On > > > > > > > > > > > > > Behalf Of mohamed.boucadair@orange.com > > > > > > > > > > > > > Sent: Thursday, April 5, 2018 4:50 PM > > > > > > > > > > > > > To: Konda, Tirumaleswar Reddy > > > > > > > > > > > > > ; > > > > > > > > > > > > > Jon Shallow ; > > > > > > > > > > > > > dots@ietf.org > > > > > > > > > > > > > Subject: Re: [Dots] Signal Channel - 300 > > > > > > > > > > > > > Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > Tiru, > > > > > > > > > > > > > > > > > > > > > > > > > > I don't see the NEW text as a restriction but as > > > > > > > > > > > > > a simplification of the > > > > > > > > > > > > client's > > > > > > > > > > > > > behavior. I don't want to over-specify the > > > > > > > > > > > > > redirect > > > behavior. > > > > > > > > > > > > > > > > > > > > > > > > > > Adding another yet layer of resolution will > > > > > > > > > > > > > raise other issues such as the > > > > > > > > > > > > need to > > > > > > > > > > > > > associate a TTL with the name itself. > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > Med > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Konda, > > > > > > > > > > > > > > Tirumaleswar Reddy > > > > > > > > > > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > > > > > > > > > Envoy=E9=A0: jeudi 5 avril 2018 12:06 =C0=A0: J= on > > > > > > > > > > > > > > Shallow; BOUCADAIR Mohamed IMT/OLN; > > > > > > > > > > > > > > dots@ietf.org > > Objet=A0: > > > > > > > > > RE: > > > > > > > > > > > > > > [Dots] Signal Channel - 300 Redirected > > > > > > > > > > > > > > Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > > From: Jon Shallow > > > > > > > > > > > > > > > [mailto:supjps-ietf@jpshallow.com] > > > > > > > > > > > > > > > Sent: Thursday, April 5, 2018 1:35 PM > > > > > > > > > > > > > > > To: mohamed.boucadair@orange.com; Konda, > > > > > > > > > > > > > > > Tirumaleswar Reddy > > > > > > > > > > > > > > > ; > > > > > > > > > > > > > > > dots@ietf.org > > > > > > > > > > > > > > > Subject: RE: [Dots] Signal Channel - 300 > > > > > > > > > > > > > > > Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Med, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks for this refresh to 4.6 Redirected > > > > > > > > > > > > > > > Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Some comments > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > #1 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The DOTS server can return the error > > > > > > > > > > > > > > > response code > > > > > > > > > > > > > > > 3.00 in > > > > > > > > > > response > > > > > > > > > > > > > > > to a PUT request from the DOTS client or > > > > > > > > > > > > > > > convey the error > > > > > > > > > > response > > > > > > > > > > > > > > > code 3.00 in a unidirectional > > > > > > > > > > > > > > > notification response from the > > > > > > > > > > DOTS > > > > > > > > > > > > > > > server. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Why is this limited to a PUT request and/or > > > > > > > > > > > > > > > unidirectional notification > > > > > > > > > > > > > > response? > > > > > > > > > > > > > > > - Surely, any response, unsolicited or > > > > > > > > > > > > > > > otherwise can contain a > > > > > > > > > > > > > > > 3.00 > > > > > > > > > > > > > > > - If Observe is not in use, then any > > > > > > > > > > > > > > > unsolicited notification response will > > > > > > > > > > > > > > > potentially get rejected by the coap library > > > > > > > > > > > > > > > layer, so a DOTS Server cannot > > > > > > > > > > > > > > signal > > > > > > > > > > > > > > > maintenance outage other than by closing the > > > session. > > > > > > > > > > > > > > > - I missed this the last review - sorry > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > #2 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If the DOTS client has been redirected to > > > > > > > > > > > > > > > a DOTS server to > > > > > > > > > which > > > > > > > > > > it > > > > > > > > > > > > > > > has already sent the mitigation request > > > > > > > > > > > > > > > within the last five > > > > > > > > > (5) > > > > > > > > > > > > > > > minutes, it MUST ignore the redirection > > > > > > > > > > > > > > > and try to contact other DOTS > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > s/ has already sent the mitigation request/ > > > > > > > > > > > > > > > has already communicated with/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > #3 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > A DOTS client MUST NOT use an > > > > > > > > > > > > > > > alternate IP address to > > > > > > > > > contact > > > > > > > > > > its > > > > > > > > > > > > > > > DOTS server upon expiry of the > > > > > > > > > > > > > > > associated > TTL. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To remove ambiguity over the use of FQDN, > > > > > > > > > > > > > > > this could read > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > A DOTS client MUST NOT use an > > > > > > > > > > > > > > > alternate IP address to > > > > > > > > > contact > > > > > > > > > > its > > > > > > > > > > > > > > > DOTS server upon expiry of the > > > > > > > > > > > > > > > associated > TTL. > > > > > > > > > > > > > > > Furthermore, a > > > > > > > > > > > > DOTS > > > > > > > > > > > > > > > Client MUST NOT use the alt-server > > > > > > > > > > > > > > > FQDN if all of the > > > > > > > > > > > > > > > alt-server- > > > > > > > > > > > > > > records > > > > > > > > > > > > > > > have expired. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Or alternatively > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > alt-server: FQDN of an alternate DOTS > server. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This could read > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > alt-server: FQDN of an alternate DOTS > server. > > > > > > > > > > > > > > > This FQDN is not to be > > > > > > > > > > > > > > used for > > > > > > > > > > > > > > > looking up IP addresses to use, but is there > > > > > > > > > > > > > > > for the SNI extension > > > > > > > > > > > > (7.1. > > > > > > > > > > > > > > (D)TLS > > > > > > > > > > > > > > > Protocol Profile) > > > > > > > > > > > > > > > > > > > > > > > > > > > > I don't think the above restriction is correct > > > > > > > > > > > > > > for the following > > > > > > > > > > reasons: > > > > > > > > > > > > > > > > > > > > > > > > > > > > 1) If the TTL value in the alt-server-record > > > > > > > > > > > > > > expires, DNS lookup can be performed by the > > > > > > > > > > > > > > DOTS client using the alternate DOTS > > > > > > > > > server > > > > > > > > > > FQDN. > > > > > > > > > > > > > > 2) If the DNS server is reachable, the client > > > > > > > > > > > > > > may want to a DANE lookup to get the IP > > > > > > > > > > > > > > addresses and certificate to validate the > > > > > > > > > > > > > > alternate DOTS server certificate > > > > sent > > > > > > > > > > > > > > in the DTLS handshake. > > > > > > > > > > > > > > > > > > > > > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > > From: Dots [mailto: dots-bounces@ietf.org] > > > > > > > > > > > > > > > On Behalf Of mohamed.boucadair@orange.com > > > > > > > > > > > > > > > Sent: 05 April 2018 08:20 > > > > > > > > > > > > > > > To: Konda, Tirumaleswar Reddy; Jon Shallow; > > > > > > > > > > > > > > > dots@ietf.org > > > > > > > > > > > > > > > Subject: Re: [Dots] Signal Channel - 300 > > > > > > > > > > > > > > > Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Tiru, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Works for me. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I updated the draft with the text additions > > > > > > > > > > > > > > > that were discussed in this thread. The > > > > > > > > > > > > > > > changes can be > > > found at: > > > > > > > > > > > > > > > https://github.com/boucadair/draft-ietf-dots > > > > > > > > > > > > > > > -s > > > > > > > > > > > > > > > ig > > > > > > > > > > > > > > > na > > > > > > > > > > > > > > > l- > > > > > > > > > > > > > > channel/blob/master/draf > > > > > > > > > > > > > > > t-ietf-dots-signal-channel.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > Med > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Konda, > > > > > > > > > > > > > > > > Tirumaleswar Reddy > > > > > > > > > > > > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com > > > > > > > > > > > > > > > > ] Envoy=E9=A0: mercredi 4 avril 2018 17:40 = =C0=A0: > > > > > > > > > > > > > > > > Jon Shallow; BOUCADAIR Mohamed IMT/OLN; > > > > > > > > > > > > > > > > dots@ietf.org > > > > > > Objet=A0: RE: > > > > > > > > > > > > > > > > [Dots] Signal Channel - 300 Redirected > > > > > > > > > > > > > > > > Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The TTL value returned under > > > > > > > > > > > > > > > > alt-server-record is equivalent to the DNS > > > > > > > > > > > > > > > > TTL value. A DDoS mitigation provider with > > > > > > > > > > > > > > > > multiple DOTS servers typically re-directs > > > > > > > > > > > > > > > > a DOTS client to a different DOTS server > > > > > > > > > > > > > > > > only if the alternate DOTS server has the > > > > > > > > > > > > > > > > capacity to handle the requests from the > > > > > > > > > > > > > > > DOTS client. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We can add the following lines to avoid > > > > > > > > > > > > > > > > loops > : > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If the DOTS client has been redirected to > > > > > > > > > > > > > > > > a DOTS server to which it has already sent > > > > > > > > > > > > > > > > the mitigation request within the last > > > > > > > > > > > > > > > > five minutes, it MUST ignore the > > > > > > > > > > > > > > > > redirection and try reaching others > > > > > > > > > > > > > > > > servers listed in the local configuration > > > > > > > > > > > > > > > > or discovered using dynamic means > > > > > > > > such as DHCP or SRV procedures. > > > > > > > > > > > > > > > > This prevents infinite ping-ponging > > > > > > > > > > > > > > > > between servers in case of redirection loop= s. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > > > > From: Dots > > > > > > > > > > > > > > > > > [mailto:dots-bounces@ietf.org] On Behalf > > > > > > > > > > > > > > > > > Of Jon Shallow > > > > > > > > > > > > > > > > > Sent: Wednesday, April 4, 2018 8:16 PM > > > > > > > > > > > > > > > > > To: mohamed.boucadair@orange.com; > > > > > > > > > > > > > > > > > dots@ietf.org > > > > > > > > > > > > > > > > > Subject: Re: [Dots] Signal Channel - 300 > > > > > > > > > > > > > > > > > Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi there, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > See inline [Jon] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > > > > From: Dots [mailto: > > > > > > > > > > > > > > > > > dots-bounces@ietf.org] On Behalf Of > > > > > > > > > > > > > > > > > mohamed.boucadair@orange.com > > > > > > > > > > > > > > > > > Sent: 04 April 2018 15:07 > > > > > > > > > > > > > > > > > To: Jon Shallow; dots@ietf.org > > > > > > > > > > > > > > > > > Subject: Re: [Dots] Signal Channel - 300 > > > > > > > > > > > > > > > > > Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Re-, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please see inline. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > > > Med > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Dots > > > > > > > > > > > > > > > > > > [mailto:dots-bounces@ietf.org] De la > > > > > > > > > > > > > > > > > > part de Jon Shallow Envoy=E9=A0: mercre= di > > > > > > > > > > > > > > > > > > 4 avril 2018 > > > 15:31 =C0=A0: > > > > > > > > > > > > > > > > > > dots@ietf.org > > > > > > > > > > > > Objet=A0: > > > > > > > > > > > > > > > > > > [Dots] Signal Channel - 300 Redirected > > > > > > > > > > > > > > > > > > Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi there, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have implemented the 300 > > > > > > > > > > > > > > > > > > Redirected-Signal in my DOTS > > > > > > > > > code. > > > > > > > > > > > > > > > > > > This then raises some questions about > > > usability. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Usability #1 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Architecture 3.2.2 Redirected > > > > > > > > > > > > > > > > > > Signalling > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 4. Having redirected the DOTS > > > > > > > > > > > > > > > > > > client, DOTS server A ceases > > > > > > > > > > > > > > sending > > > > > > > > > > > > > > > > > > server signals. The DOTS > > > > > > > > > > > > > > > > > > client likewise stops sending > > > > > > > > > > > > client > > > > > > > > > > > > > > > > > > signals to DOTS server A. DOTS > > > > > > > > > > > > > > > > > > session 1 is > > > > > > > > > > terminated. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Clearly indicates that the original > > > > > > > > > > > > > > > > > > session (Client to Server > > > > > > > > > > > > > > > > > > A) is no more once redirected and only > > > > > > > > > > > > > > > > > > Client to Server B is in > > > > > > > > > > > > use. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > How is the traffic redirected back to > > > > > > > > > > > > > > > > > > Server A once maintenance / > > > > > > > > > > > > > > > > > > overloading > etc. > > > has finished? > > > > > > > > > > > > > > > > > > My assumption is that Server B sends a > > > > > > > > > > > > > > > > > > redirect to go back to Server A as > > > > > > > > > > > > > > > > > > Server A has no way to say over a now > > > > > > > > > > > > > > > > > > non-existent session to say > > > > > > > > > > > > > "come back". > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [Med] That's one possibility. This one > > > > > > > > > > > > > > > > > does not require any update to the > > > > > > > > > > > > > > > > signal- > > > > > > > > > > > > > > > > > channel specification. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Another approach would be to not require > > > > > > > > > > > > > > > > > any redirect signal from server > > > > > > > > > > > > > > > B. > > > > > > > > > > > > > > > > > The client will remove server B's > > > > > > > > > > > > > > > > > records upon the expiry of the TTL and > > > > > > > > > > > > > > > > will fall > > > > > > > > > > > > > > > > > back to the "base" DOTS servers > > > > > > > > > > > > > > > > > configuration that was provisioned to > > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > client > > > > > > > > > > > > > > > > > using DHCP or whatever mechanism. > > > > > > > > > > > > > > > > > [Jon] OK. The TTL is defined at, > > > > > > > > > > > > > > > > > associated with the IP address level > > > > > > > > > > > > > > > > under alt- > > > > > > > > > > > > > > > > > server-record, not under > > > > > > > > > > > > > > > > > ietf-dots-signal-channel:redirected-signa= l. > > > The ttl > > > > > > > > > > definition is > > > > > > > > > > > > > > > > > ambiguous as to what it refers to and > > > > > > > > > > > > > > > > > perhaps could be tightened up in the > > > > > > > > > > > > > > > > > language (I read it as being associated > > > > > > > > > > > > > > > > > with "addr" in the sense of a DNS > > > > > > > > > > > > > > > > TTL). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Do we need to keep the existing Client > > > > > > > > > > > > > > > > > > to Server A session warm (or perhaps > > > > > > > > > > > > > > > > > > to probe > > > > > > > > > > > > > > > > > > periodically) to see if Server A is > > > > > > > > > > > > > > > > > > capable of handling the Client again > > > > > > > > > > > > > > > > > > by a server response extension to the > > > > > > > > > > > > > > > > > > protocol (e.g. a > > > > > > > > > > > > > > > > > > 3.01) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [Med] Redirect was initially introduced > > > > > > > > > > > > > > > > > to manage a server overload, so I > > > > > > > > > > > > > > > > don't > > > > > > > > > > > > > > > > > think it makes sense to probe or > > > > > > > > > > > > > > > > > maintain a session with > > > > > > > > > server > > > > > > > > > > A. > > > > > > > > > > > > > > > > > [Jon] Agreed, but I needed to raise the > > > question. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Should there be a retry period > > > > > > > > > > > > > > > > > > parameter added in to the > > > > > > > > > > > > > > > > > > 3.00 protocol (as I read it, ttl only > > > > > > > > > > > > > > > > > > refers to the IP > > > > > > > > > > address)? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [Med] The client will automatically > > > > > > > > > > > > > > > > > switch to Server A when all alternate > > > > > > > > > > > > > > > > records > > > > > > > > > > > > > > > > > expire. > > > > > > > > > > > > > > > > > [Jon] OK - again the 4.6 text needs to > > > > > > > > > > > > > > > > > get tightened up to reflect this as > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > intent. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Usability #2 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Server A says "Redirect to Server B" > > > > > > > > > > > > > > > > > > due to > > > > > > > overloading. > > > > > > > > > > > > > > > > > > Server B accepts things for a while > > > > > > > > > > > > > > > > > > and then is instructed/decides to > > > > > > > > > > > > > > > > > > redirect traffic > > > back to A. > > > > > > > > > > > > > > > > > > Server A is left still overload > > > > > > > > > > > > > > > > > > configured to redirect to B. How > > > > > > > > > > > > > > > > > > should the client handle this as there > > > > > > > > > > > > > > > > > > is no suitable > > > > > > > > > > > > > > > > > Server? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [Med] This is a service configuration > problem. > > > > > > > > > > > > > > > > > We may > > > > > > > ask: > > > > > > > > > > > > > > > > > * the client to log the error and notify > > > > > > > > > > > > > > > > > the > > > > > > > > administrator. > > > > > > > > > > > > > > > > > * and/or stop the redirection after n > cycles. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Still, this does not solve the problem. > > > > > > > > > > > > > > > > > [Jon] Agreed there is a problem here > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I agree that there needs to be > > > > > > > > > > > > > > > > > > co-ordination between Server A and > > > > > > > > > > > > > > > > > > Server B, but user error may > > > > > > > creep in. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Usability #3 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Server A says "Redirect to Server B" > > > > > > > > > > > > > > > > > > as it going to be shut down because of > > > > > > > > > > > > > > > > > > maintenance. Server B accepts things > > > > > > > > > > > > > > > > > > for a while and then is instructed (in > > > > > > > > > > > > > > > > > > probable user > > > > > > > > > > > > > > > > > > error) to redirect traffic back to A > > > > > > > > > > > > > > > > > > (perhaps because it has hit an > > > > > > > > > > > > > > > > > > overload condition). How should the > > > > > > > > > > > > > > > > > > client > > > > > > > > > > > > > > > > > handle this? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [Med] Isn't this a sub-case or #2? > > > > > > > > > > > > > > > > > [Jon] Yes, but I wanted to bring in > > > > > > > > > > > > > > > > > Server A being alive and able to > > > > > > > > > > > > > > > > respond > > > > > > > > > > > > > > > > > versus Server A down and not responding > > > > > > > > > > > > > > > > > due to > > > > > > > > maintenance. > > > > > > > > > > > > > > > > > [Jon] With my better understanding of > > > > > > > > > > > > > > > > > TTL we still have an issue if the TTL > > > > > > > > > > > > > > > > > expires and Server A is having an > > > > > > > > > > > > > > > > > extended > > > > > > > > > > outage. > > > > > > > > > > > > > > > > > How do we recover from that? > > > > > > > > > > > > > > > > > ~jon > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ______________________________________ > > > > > > > > > > > > > > > > > > __ __ __ ___ Dots mailing list > > > > > > > > > > > > > > > > > > Dots@ietf.org > > > > > > > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/ > > > > > > > > > > > > > > > > > > do > > > > > > > > > > > > > > > > > > ts > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ________________________________________ > > > > > > > > > > > > > > > > > __ __ __ _ Dots mailing list > > > > > > > > > > > > > > > > > Dots@ietf.org > > > > > > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/do > > > > > > > > > > > > > > > > > ts > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ________________________________________ > > > > > > > > > > > > > > > > > __ __ __ _ Dots mailing list > > > > > > > > > > > > > > > > > Dots@ietf.org > > > > > > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/do > > > > > > > > > > > > > > > > > ts > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ____________________________________________ > > > > > > > > > > > > > > > __ _ Dots mailing list Dots@ietf.org > > > > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > Dots mailing list Dots@ietf.org > > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > Dots mailing list > > > > > > > > > > Dots@ietf.org > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > Dots mailing list > > > > > > > > > Dots@ietf.org > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Dots mailing list > > > > > > > Dots@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > _______________________________________________ > > > > > > Dots mailing list > > > > > > Dots@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > _______________________________________________ > > > > > > Dots mailing list > > > > > > Dots@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Mon Apr 9 04:05:58 2018 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 80460126D74 for ; Mon, 9 Apr 2018 04:05:55 -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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 N9f3rT_aSkUM for ; Mon, 9 Apr 2018 04:05:52 -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 53E23126BF6 for ; Mon, 9 Apr 2018 04:05:52 -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=1523271951; 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: dlp-product:dlp-version:dlp-reaction: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-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: 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=5PdL+j59ETHnoyHc32hphyVnzKO8bGGtgCk37t lKKZQ=; b=O/+P7WWHOJ6zqGO63XOuKAg58YXKwB1R0h/cVyl0 zqRlKuD7bdhOy7WlOrH8OdkdSOYnDhLI/6Jb6kac3ai9Vpaghi XaiBEK/EVpwyKuvJDIku3oOBwrq/ksj3NYqP6dWlmO5lsr5Ikb 6ggUKhWZPz3VkP1g2p1FG2CuS7O5LXE= Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 16ce_4cf7_7b62ae5a_c00d_4776_bcb2_259be968f3eb; Mon, 09 Apr 2018 06:05:50 -0500 Received: from DNVEXUSR1N13.corpzone.internalzone.com (10.44.48.86) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 9 Apr 2018 05:04:47 -0600 Received: from DNVEXUSR1N10.corpzone.internalzone.com (10.44.48.83) by DNVEXUSR1N13.corpzone.internalzone.com (10.44.48.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 9 Apr 2018 05:04:45 -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; Mon, 9 Apr 2018 05:04:45 -0600 Received: from NAM02-SN1-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.1347.2; Mon, 9 Apr 2018 05:04:43 -0600 Received: from BN6PR16MB1425.namprd16.prod.outlook.com (10.172.207.19) by BN6PR16MB1684.namprd16.prod.outlook.com (10.172.28.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.653.12; Mon, 9 Apr 2018 11:04:43 +0000 Received: from BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d]) by BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d%2]) with mapi id 15.20.0653.015; Mon, 9 Apr 2018 11:04:43 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: [Dots] Data Channel ACL fragments Thread-Index: AdPMHAMfDWFlXvb3TSeAr5MVkYUzIgAA3pEAAAKPJoAAIuTfcAADWaQAAADopUAAyEgtgAACNjeg Date: Mon, 9 Apr 2018 11:04:43 +0000 Message-ID: References: <016401d3cc1c$03321200$09963600$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7F97@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <01a701d3cc29$ba915b10$2fb41130$@jpshallow.com> <007501d3ccc2$b49f0b00$1ddd2100$@jpshallow.com> <021301d3cfe7$77e5cbe0$67b163a0$@jpshallow.com> In-Reply-To: <021301d3cfe7$77e5cbe0$67b163a0$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR16MB1684; 7:OlaP19RCerzNCt06u6NESUOVHtWz4FMglKTcn7l6bksbWri41Z8fQpS4q9UHptaFMRMrsojKPPGrJgJLDYk4xP2wA2tlgWxvqCrleKpza/d9qn3amwnDZGuIvHbAXZ7/JIYHSdvJbgPmh9s0ZgncthhkLhyc4zjlueHTc9pYlcp6BFcYqpPLmcjP8q4jrVoIAlhOGdYDVWbpv20lWWfD1w0FvKlHvElBcRsPonlHnxEc4j1+B0vMBgW/tfor/Miu x-ms-exchange-antispam-srfa-diagnostics: SOS; X-MS-Office365-Filtering-Correlation-Id: c64d7dcd-c12f-4ecd-dffc-08d59e09b2f3 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BN6PR16MB1684; x-ms-traffictypediagnostic: BN6PR16MB1684: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(192374486261705)(114627819485645)(95692535739014)(18271650672692)(21748063052155)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231221)(944501327)(52105095)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(6072148)(201708071742011); SRVR:BN6PR16MB1684; BCL:0; PCL:0; RULEID:; SRVR:BN6PR16MB1684; x-forefront-prvs: 0637FCE711 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39860400002)(39380400002)(346002)(366004)(376002)(32952001)(199004)(189003)(51444003)(72206003)(6436002)(3280700002)(2906002)(54896002)(6306002)(9686003)(236005)(105586002)(55016002)(3660700001)(53936002)(8936002)(6246003)(68736007)(606006)(81156014)(81166006)(316002)(9326002)(53946003)(8676002)(66066001)(33656002)(478600001)(966005)(106356001)(97736004)(14454004)(2900100001)(53546011)(80792005)(476003)(2501003)(59450400001)(6506007)(6116002)(11346002)(446003)(19609705001)(25786009)(229853002)(5250100002)(486006)(26005)(86362001)(5660300001)(2201001)(3846002)(102836004)(110136005)(99286004)(7696005)(93886005)(74316002)(76176011)(7736002)(790700001)(186003)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR16MB1684; H:BN6PR16MB1425.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: kmP8vcmW41+eBbX/Fs394bzy9epZrq6za0GX+VMfQy9GOKNC+GzdnuaNLfloKy/CBaTVvXEDi7LP2ERsBYVjwp7jNImphWD4eOl5PvFwhnV+hvodFVUkMW/4HVtv+ajyVTIw759/8XJRRSft/tsCAbhsz9xlm3w8FjHXHaFVyT4B27z+I5ROCxN35z56YCx2oT+F5vh/NGQMYOy9xr7f0Uv6z/SwsZIqq5acVF3NjE2PfN9vDBkNskuhF4VIv/oJ5Y6uB1ztsVUicyKASg7reJkB2BgNwb+ltmYLVMvfPjAzi7m5VHJ/ogm85/NsTFBizVHniP45V7AXz2Z3L8AGtcHkDoxqnd5EgY1i+8ib8Q4EL41FTXoSMstsddghUSMT0TaOSBvcemqjzIn1ejeD0gAyldleP4G0cjlsjcsmAD0= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR16MB142560DE045B75F16CB4E981EABF0BN6PR16MB1425namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: c64d7dcd-c12f-4ecd-dffc-08d59e09b2f3 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2018 11:04:43.4282 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR16MB1684 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6259> : inlines <6554> : streams <1783535> : uri <2622468> Archived-At: Subject: Re: [Dots] Data Channel ACL fragments 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, 09 Apr 2018 11:05:56 -0000 --_000_BN6PR16MB142560DE045B75F16CB4E981EABF0BN6PR16MB1425namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jon, Please see inline [TR2] From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Monday, April 9, 2018 3:15 PM To: Konda, Tirumaleswar Reddy ; mohamed= .boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] Data Channel ACL fragments Hi Tiru, See inline [Jon1] Regards Jon From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Konda@mcafee.com= ] Sent: 07 April 2018 07:55 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] Data Channel ACL fragments Hi Jon, Please see inline [TR] From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Thursday, April 5, 2018 3:15 PM To: Konda, Tirumaleswar Reddy >; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] Data Channel ACL fragments Hi Tiru, Actually no, as there is a disconnect between the Cisco document and what w= e have currently got set up. The Cisco Document refers to ACL, which is an ACE in netmod-acl-model/DOTS = speak. A DOTS ACL can be a list of separate matching ACEs. With netmod-acl, we have layer 3 definitions and then separately layer 4 de= finitions - there is now no concept of L3+L4 within the same ACE. So, the Cisco statement "Note: When there is both Layer 3 and Layer 4 infor= mation in the ACL line and the fragments keyword is present" will never be = true for an ACE entry. [TR] No, as per the ACE definition in draft-ietf-netmod-acl-model-16, The c= hoice statements within the match container allow for selection of one head= er within each of "l2", "l3", or "l4" headers. It is possible to specify both L3 and L4 information in the ACE (each ACE h= as a group of match criteria). [Jon1] - My bad - I was reading "Choice" as choosing L3 or L4, not that the= choice was referring to the sub-elements within the choice. So, yes, L3 += L4 are supported. ---- I still do not understand from the Cisco Document how you can build a set o= f ACLs that say (but I may be missing something) "All traffic to port 53 is allowed unless it is fragmented, in which case a= ll fragments are to be dropped" I can create a set of ACLs that say "All traffic to port 53 is allowed unless it is fragmented, in which case a= ll non-initial fragments are to be dropped" Which does set things up for a DoS of the target with all the initial fragm= ents waiting re-assembly. [TR] The don't think a ACL should blindly drop all fragmented packets, frag= mentation may or may not happen because of a DoS attack. Do vendors current= ly support what you are asking ? [Jon1] If (IP_MF | IP_OFFMASK) is set in frag_off (linux) in an IPv4 packet= , then the packet is a part of a fragmented packet sequence. Dropping any = packets with (IP_MF | IP_OFFMASK) !=3D 0 will safely drop all the fragmente= d packets. This then protects the target's IP reassembly logic's RAM usage= . Similarly, for IPv6 there is the detection of protocol 44. [Jon1] NCC's mitigation appliances can disable fragmented packets either ma= nually or when there is an ongoing fragmentation attack where the complete = set of fragments for a packet are not seen. [TR2] My question is whether vendors support any ACL that drops all fragme= nts (e.g. a separate feature called virtual fragmentation and reassembly is= used by Cisco devices to protect the target's reassembly logic, see https:= //www.cisco.com/c/en/us/td/docs/ios/sec_data_plane/configuration/guide/12_4= /sec_data_plane_12_4_book/sec_virt_frag_reassm.html but I did not find any = proprietary ACL to drop all fragments) ? [Jon1] I still question as to whether we should be using netmod-acl's versi= on of fragmentation instead of using a DOTS extension. [TR2] How will using netmod-acl version helps drop DoS attack using non-ini= tial fragments only ? -Tiru ~jon1 -Tiru ---- Which then gets more complicated to construct something when we can only do= either L3 or L4 matching on a per ACE. Regards Jon From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of Konda, T= irumaleswar Reddy Sent: 05 April 2018 09:23 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] Data Channel ACL fragments Hi Jon, The fragment definition to protect the target from attacks that use non-ini= tial fragments only. We followed the Security considerations for IP filtering given in Section 2= of https://www.ietf.org/rfc/rfc1858.txt to drop the initial fragment, so t= he non-initial fragments will be discarded by the destination host (its imp= lemented and discussed in https://www.cisco.com/c/en/us/support/docs/ip/gen= eric-routing-encapsulation-gre/8014-acl-wp.html). -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Wednesday, April 4, 2018 9:00 PM To: mohamed.boucadair@orange.com; dots= @ietf.org Subject: Re: [Dots] Data Channel ACL fragments Hi Med et all, See inline [Jon] Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 04 April 2018 15:27 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Data Channel ACL fragments Re-, I guess we do still need this because we wanted to achieve this functionali= ty (especially for the non-initial fragments): =3D=3D This document supports fragment filtering which adds an additional layer of protection against a DoS attack that uses non-initial fragments only. When there is only layer 3 information in the ACL entry and the fragments keyword is present, for non-initial fragments matching the ACE entry, the 'deny' or 'accept' action associated with the ACE entry will be enforced. For initial or non-fragment matching the ACE entry, the next ACE entry will be processed. When there is both layer 3 and layer 4 information in the ACE entry and the fragments keyword is present, the ACE action is conservative for both 'accept' and 'deny' actions. The actions are conservative to not accidentally deny a fragmented portion of a flow because the fragments do not contain sufficient information to match all of the filter attributes. In the 'deny' action case, instead of denying a non-initial fragment, the next ACE entry is processed. In the 'accept' case, it is assumed that the layer 4 information in the non- initial fragment, if available, matches the layer 4 information in the ACE entry. =3D=3D [Jon] Actually, as I read the text above, if the additional layer of protec= tion is required against fragmented attacks and v-[46]-fragment is set with= action "drop", then any non-initial fragment is dropped - fine. However, the initial fragment skips this ACE test and goes onto the next AC= E. Assuming that there is a "accept" that matches everything else (i.e. we= like the packet apart from when it is fragmented), then the initial fragme= nt is let through. The target IP then consumes lots of RAM whilst waiting for the missing frag= ment segments........D(D)oS Success. There is no way to drop the initial fragment with the above text other than= to "drop" genuine non fragmented traffic as well. I think that logic is f= lawed to drop just subsequent fragments. [Jon] I also wonder how the above is going to get implemented - it would be= easier to say any fragmented packet sequence is not allowed (including the= initial packet) rather than only a part of the sequence which then leads t= o a DoS in its own rights. No? [Jon] See above. I do agree that flags -> fragment -> 1 is a bit ambiguous= is its definition when used to match a packet as an acl/ace, but I do thin= k the match intent is that the packet is not fragmented. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : mercredi 4 avril 2018 15:51 =C0 : dots@ietf.org Objet : [Dots] Data Channel ACL fragments Hi there, Do we still need to have the fragment definition for ACEs in the data chann= el? draft-ietf-netmod-acl-model-18 now supports fragments for ipv4 (flags + opt= ions) and implicitly in ipv6 through the next header field protocol set to = 44 (fragment extension header). IPV4 =3D=3D=3D=3D grouping acl-ipv4-header-fields { description "Fields in IPv4 header."; ... leaf flags { type bits { bit reserved { position 0; description "Reserved. Must be zero."; } bit fragment { position 1; description "Setting value to 0 indicates may fragment, while setting the value to 1 indicates do not fragment."; } bit more { position 2; description "Setting the value to 0 indicates this is the last fragment, and setting the value to 1 indicates more fragments are coming."; } } description "Bit definitions for the flags field in IPv4 header."; } leaf offset { type uint16 { range "20..65535"; } description "The fragment offset is measured in units of 8 octets (64 bits). The first fragment has offset zero. The length is 13 bits"; } Regards Jon --_000_BN6PR16MB142560DE045B75F16CB4E981EABF0BN6PR16MB1425namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jon,

&nbs= p;

Please se= e inline [TR2]

 

From:<= /span> Jon Shallow [mailto:s= upjps-ietf@jpshallow.com]
Sent: Monday, April 9, 2018 3:15 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; mohamed.boucadair@orange.com; dots@ietf.org
Subject: RE: [Dots] Data Channel ACL fragments

 

Hi Tiru= ,

&n= bsp;

See inl= ine [Jon1]

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Kon= da@mcafee.com]
Sent: 07 April 2018 07:55
To: Jon Shallow; moh= amed.boucadair@orange.com; dots@ietf.org
Subject: RE: [Dots] Data Channel ACL fragments

 

Hi Jon,

&nbs= p;

Please se= e inline [TR]

&nbs= p;

From:<= /span> Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Thursday, April 5, 2018 3:15 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; mohamed.boucadair@orange.co= m; dots@ietf.org
Subject: RE: [Dots] Data Channel ACL fragments

 

Hi Tiru= ,

&n= bsp;

Actuall= y no, as there is a disconnect between the Cisco document and what we have = currently got set up.

&n= bsp;

The Cis= co Document refers to ACL, which is an ACE in netmod-acl-model/DOTS speak.&= nbsp; A DOTS ACL can be a list of separate matching ACEs.=

&n= bsp;

With ne= tmod-acl, we have layer 3 definitions and then separately layer 4 definitio= ns – there is now no concept of L3+L4 within the same ACE.

&n= bsp;

So, the= Cisco statement “Note: When there is both Layer 3 and Layer 4 inform= ation in the ACL line and the fragments keyword is present” will neve= r be true for an ACE entry.

&nbs= p;

[TR] No, = as per the ACE definition in draft-ietf-netmod-acl-model-16, The choice sta= tements within the match container allow for selection of one header within= each of "l2", "l3", or "l4" headers.

It is pos= sible to specify both L3 and L4 information in the ACE (each ACE has a grou= p of match criteria).

&n= bsp;

[Jon1] = – My bad – I was reading “Choice” as choosing L3 or= L4, not that the choice was referring to the sub-elements within the choic= e.  So, yes, L3 + L4 are supported.

&n= bsp;

----

&n= bsp;

I still= do not understand from the Cisco Document how you can build a set of ACLs = that say (but I may be missing something)

“= All traffic to port 53 is allowed unless it is fragmented, in which case al= l fragments are to be dropped”

&n= bsp;

I can c= reate a set of ACLs that say

“= All traffic to port 53 is allowed unless it is fragmented, in which case al= l non-initial fragments are to be dropped”

Which d= oes set things up for a DoS of the target with all the initial fragments wa= iting re-assembly.

 

[TR] The don’t think a ACL should blindly drop= all fragmented packets, fragmentation may or may not happen because of a D= oS attack. Do vendors currently support what you are asking ?

 

[Jon1] If (IP_MF | IP_= OFFMASK) is set in frag_off (linux) in an IPv4 packet, then the packet is a= part of a fragmented packet sequence.  Dropping any packets with (IP_= MF | IP_OFFMASK) !=3D 0 will safely drop all the fragmented packets.  This then protects the target’s IP rea= ssembly logic’s RAM usage.   Similarly, for IPv6 there is t= he detection of protocol 44.

 

[Jon1] NCC’s mit= igation appliances can disable fragmented packets either manually or when t= here is an ongoing fragmentation attack where the complete set of fragments= for a packet are not seen.

 

[TR2]  My question is whether vendors support a= ny ACL that drops all fragments (e.g. a separate feature called virtual fra= gmentation and reassembly is used by Cisco devices to protect the target= 217;s reassembly logic, see https://www.cisco.com/c/en/us/td/docs/ios/sec_data_plane/configuration/guid= e/12_4/sec_data_plane_12_4_book/sec_virt_frag_reassm.html but I did not= find any proprietary ACL to drop all fragments) ?

 

[Jon1] I still questio= n as to whether we should be using netmod-acl’s version of fragmentat= ion instead of using a DOTS extension.

 

[TR2] How will using netmod-acl version helps drop D= oS attack using non-initial fragments only ?

 

-Tiru

 

~jon1

 

-Tiru

 

----

&n= bsp;

Which t= hen gets more complicated to construct something when we can only do either= L3 or L4 matching on a per ACE.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto:ietf-supjps-dots-bounces@iet= f.org] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 05 April 2018 09:23
To: Jon Shallow; mohamed.boucadair@orange.com; dots@iet= f.org
Subject: Re: [Dots] Data Channel ACL fragments

 

Hi Jon,

&nbs= p;

The fragm= ent definition to protect the target from attacks that use non-initial frag= ments only.

We follow= ed the Security considerations for IP filtering given in Section 2 of https://www.ietf.org/rfc/rfc1858.txt to drop the initial fragment, so th= e non-initial fragments will be discarded by the destination host (its implemented and discussed in https= ://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulation-gre/= 8014-acl-wp.html).

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: Wednesday, April 4, 2018 9:00 PM
To: mohamed.boucadair@orange.com; dots@ietf.org=
Subject: Re: [Dots] Data Channel ACL fragments

 

Hi Med = et all,

&n= bsp;

See inl= ine [Jon]

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: = dots-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com
Sent: 04 April 2018 15:27
To: Jon Shallow; dots@ietf.org
Subject: Re: [Dots] Data Channel ACL fragments

 

Re-,

 

I guess we do still need this because we wante= d to achieve this functionality (especially for the non-initial fragments):=

 

=3D=3D

   This document support= s fragment filtering which adds an additional

   layer of protection a= gainst a DoS attack that uses non-initial

   fragments only. = When there is only layer 3 information in the ACL

   entry and the fragmen= ts keyword is present, for non-initial fragments

   matching the ACE entr= y, the 'deny' or 'accept' action associated with

   the ACE entry will be= enforced.  For initial or non-fragment matching

   the ACE entry, the ne= xt ACE entry will be processed.  When there is

   both layer 3 and laye= r 4 information in the ACE entry and the

   fragments keyword is = present, the ACE action is conservative for both

   'accept' and 'deny' a= ctions.  The actions are conservative to not

   accidentally deny a f= ragmented portion of a flow because the

   fragments do not cont= ain sufficient information to match all of the

   filter attributes.&nb= sp; In the 'deny' action case, instead of denying a

   non-initial fragment,= the next ACE entry is processed.  In the

   'accept' case, it is = assumed that the layer 4 information in the non-

   initial fragment, if = available, matches the layer 4 information in

   the ACE entry.

=3D=3D

 

[Jon] Actually, as I r= ead the text above, if the additional layer of protection is required again= st fragmented attacks and v-[46]-fragment is set with action “drop= 221;, then any non-initial fragment is dropped – fine.

 

However, the initial f= ragment skips this ACE test and goes onto the next ACE.  Assuming that= there is a “accept” that matches everything else (i.e. we like= the packet apart from when it is fragmented), then the initial fragment is let through.

 

The target IP then con= sumes lots of RAM whilst waiting for the missing fragment segments…&#= 8230;..D(D)oS Success.

 

There is no way to dro= p the initial fragment with the above text other than to “drop”= genuine non fragmented traffic as well.  I think that logic is flawed= to drop just subsequent fragments.

 

[Jon] I also wonder ho= w the above is going to get implemented – it would be easier to say a= ny fragmented packet sequence is not allowed (including the initial packet)= rather than only a part of the sequence which then leads to a DoS in its own rights.

 

No?

 

[Jon] See above. = I do agree that flags -> fragment -> 1 is a bit ambiguous is its def= inition when used to match a packet as an acl/ace, but I do think the match= intent is that the packet is not fragmented.

 

 

Cheers,

Med

 

De : Dots [mailto:dots-boun= ces@ietf.org] De la part de Jon Shallow
Envoy=E9 : mercredi 4 avril 2018 15:51
=C0 : dots@ietf.org
Objet : [Dots] Data Channel ACL fragments

 

Hi there,

 

Do we still need to have the fr= agment definition for ACEs in the data channel?

 

draft-ietf-netmod-acl-model-18 = now supports fragments for ipv4 (flags + options) and implicitly in ipv= 6 through the next header field protocol set to 44 (fragment extension head= er).

 

IPV4

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

  grouping acl-ipv4-header= -fields {

    description<= o:p>

      = "Fields in IPv4 header.";

...

    leaf flags {=

      = type bits {

     &= nbsp;  bit reserved {

     &= nbsp;    position 0;

     &= nbsp;    description

     &= nbsp;      "Reserved. Must be zero.";

     &= nbsp;  }

     &= nbsp;  bit fragment {

     &= nbsp;    position 1;

     &= nbsp;    description

     &= nbsp;      "Setting value to 0 indicates may = fragment, while setting

     &= nbsp;       the value to 1 indicates do not f= ragment.";

     &= nbsp;  }

     &= nbsp;  bit more {

     &= nbsp;    position 2;

     &= nbsp;    description

     &= nbsp;      "Setting the value to 0 indicates = this is the last fragment,

     &= nbsp;       and setting the value to 1 indica= tes more fragments are

     &= nbsp;       coming.";<= /p>

     &= nbsp;  }

      = }

      = description

     &= nbsp;  "Bit definitions for the flags field in IPv4 header."= ;

    }=

 

    leaf offset = {

      = type uint16 {

      =   range "20..65535";

      = }

      = description

     &= nbsp;  "The fragment offset is measured in units of 8 octets (64 = bits).

     &= nbsp;   The first fragment has offset zero. The length is 13 bits= ";

    }=

 

Regards

 

Jon

 

--_000_BN6PR16MB142560DE045B75F16CB4E981EABF0BN6PR16MB1425namp_-- From nobody Mon Apr 9 04:19:17 2018 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 2C6DD127867 for ; Mon, 9 Apr 2018 04:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptOqbS8QzyIn for ; Mon, 9 Apr 2018 04:19:12 -0700 (PDT) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A418126BF6 for ; Mon, 9 Apr 2018 04:19:12 -0700 (PDT) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id ABACB120810; Mon, 9 Apr 2018 13:19:10 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.69]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 80771160088; Mon, 9 Apr 2018 13:19:10 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d%18]) with mapi id 14.03.0382.000; Mon, 9 Apr 2018 13:19:10 +0200 From: To: "Konda, Tirumaleswar Reddy" , "Jon Shallow" , "dots@ietf.org" Thread-Topic: [Dots] Signal Channel - 300 Redirected Signaling Thread-Index: AQJ5xX4UsK17va5Vv37fpNudI6+9awAAo7xAAAH7T4AAARdqYAAhoxEAAAGQiwAAAKyNYAAF3e1QACUKCFAAAZEMQAAIeXTgAARcGhAAAoG7gAABGXwAAAAjBIAAAa5ZgAAAiReAAABpmzAAL32aAABWbPEwAAIv/gAAAPiKMAAA7T0AAACbH4AAAR48IKKkw5Cg Date: Mon, 9 Apr 2018 11:19:09 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DEFA44B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <014f01d3cc19$2e3880e0$8aa982a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7E7B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <019901d3cc23$a93ff8e0$fbbfeaa0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8524@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <004e01d3ccb4$d505e7f0$7f11b7d0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8758@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEF912A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEF93EE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <008501d3cda6$c860d210$59227630$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF951 1@OPEXCLILMA3 . corporate.adroot.infra.ftgroup> <00b001d3cdab$ba8caec0$2fa60c40$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF975C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <00b801d3cdb4$982dc4a0$c8894de0$@jpshallow.com> <015101d3ce74$351393c0$9f3abb40$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEFA190@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <01f501d3cfde$4014ca30$c03e5e90$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEFA2DF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling 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, 09 Apr 2018 11:19:16 -0000 Re-, Focusing on this part of your answer: "No, DNS TTL lifetime does not mean existing session has to be disconnecte= d=20 after the TTL expires." This is exactly the disconnect. We are not discussing **DNS TTL** but the v= alidity time of a an alternate server as provided in a DOTS redirect signal= .=20 If a finite validity time is provided, the client will use that alternate s= erver till that validly time expires. Passed that timer, the client will co= ntact its "normal" servers to place requests. That behavior is straightforw= ard.=20 If you insist to interpret TTL as DNS TTL, then RFC1035 says the following:= =20 " TTL a 32 bit signed integer that specifies the time interval that the resource record may be cached before the source of the information should again be consulted. " ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ In our case, the source of the information is the normal server :) Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumales= war > Reddy > Envoy=E9=A0: lundi 9 avril 2018 12:08 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org > Objet=A0: Re: [Dots] Signal Channel - 300 Redirected Signaling >=20 > > -----Original Message----- > > From: mohamed.boucadair@orange.com > > [mailto:mohamed.boucadair@orange.com] > > Sent: Monday, April 9, 2018 2:27 PM > > To: Jon Shallow ; Konda, Tirumaleswar Reddy > > ; dots@ietf.org > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > Re-, > > > > Please see inline. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > Envoy=E9=A0: lundi 9 avril 2018 10:39 > > > =C0=A0: 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; > > > dots@ietf.org Objet=A0: RE: [Dots] Signal Channel - 300 Redirected > > > Signaling > > > > > > Hi all, > > > > > > Should 'ttl' actually be 'lifetime' to remove any confusion over whet= her > > > this is DNS TTL usage or not ? > > > > [Med] we do already have a lifetime in the cbor mapping table. So, I > suggest to > > maintain ttl but focus on its definition to avoid confusion. >=20 > Agreed. >=20 > > > > > > > > Otherwise see inline [Jon] > > > > > > Regards > > > > > > Jon > > > > > > -----Original Message----- > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, > > > Tirumaleswar Reddy > > > Sent: 09 April 2018 09:23 > > > To: mohamed.boucadair@orange.com; Jon Shallow; dots@ietf.org > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > -----Original Message----- > > > > From: mohamed.boucadair@orange.com > > > > [mailto:mohamed.boucadair@orange.com] > > > > Sent: Monday, April 9, 2018 1:15 PM > > > > To: Konda, Tirumaleswar Reddy ; > > > > Jon Shallow ; dots@ietf.org > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > Tiru, > > > > > > > > What about this update ones? > > > > > > > > =3D=3D=3D=3D=3D=3D=3D > > > > ttl: Time to live (TTL) of the alternate DOTS server, represent= ed > as > > > > an integer number of seconds. That is, the time interval tha= t > the > > > > alternate DOTS server may be cached for use by a DOTS client. > > > > > > > > A lifetime of negative one (-1) indicates indefinite TTL. Th= is > > > > value means that the alternate DOTS server is to be used unti= l > the > > > > alternate DOTS server redirects the traffic with another 3.00 > > > > response. > > > > > > > > If no 'ttl' is returned in a redirect response, this is > equivalent > > > > to returning a 'ttl' parameter set to '-1'. > > > > > > Above text looks good. > > > > > > [Jon] Later in the text, there is reference to a minimum of 5 minute= s > > > before being able to switch back to the original DOTS server. Don't > > > we need to say a 5 minute (300 secs) minimum here? > > > > [Med] That reference is when explicit redirect signals are involved. >=20 > Yup. >=20 > > > > > > > > > > > > > If the alternate DOTS server TTL has expired, the DOTS client > MUST > > > > use the DOTS server(s), that was provisioned using means > discussed > > > > in Section 4.1, for creating new requests. > > > > > > It looks too restrictive, typically the DNS TTL values are short-live= d > > > (e.g.. few seconds) but the sessions are long-lived. > > > Why not replace "for creating new requests" with "for creating new > > > DOTS session" ? > > > > > > [Jon] I think that once the alternate DOTS server's lifetime has > > > expired, the DOTS client should try to establish a connection with th= e > > > appropriate "normal" DOTS servers, > > > > [Med] Bingo. >=20 > No, DNS TTL lifetime does not mean existing session has to be disconnect= ed > after the TTL expires. >=20 > -Tiru >=20 > > > > if that fails, continue to use the alternate DOTS > > > server, but periodically retry the "normal" servers to try to maintai= n > > > resilience of service. > > > > [Med] The document does not specify the behavior for selecting among > multiple > > servers. So, this details are out of scope. > > > > After all, the outage (e.g. maintenance window) of > > > the original DOTS server may have to be extended, and being down, > > > cannot respond with a 3.00 to instruct DOTS client to stay with the > > > alternate DOTS server. > > > > > > > [Med] For such cases, it is safe to return an indefinite TTL + alternat= e > server to > > coordinate the fallback behavior. > > > > > --Tiru > > > > > > > > > > > This is an optional attribute. > > > > =3D=3D=3D > > > > > > > > Cheers, > > > > Med > > > > > > > > > -----Message d'origine----- > > > > > De=A0: Konda, Tirumaleswar Reddy > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > Envoy=E9=A0: lundi 9 avril 2018 08:51 > > > > > =C0=A0: Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Obj= et=A0: RE: > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > Hi Jon, > > > > > > > > > > I partially agree with the suggested update. A IP address is > > > > > cached until the TTL value expires, the DOTS client need not > > > > > disconnect existing sessions after the TTL expires, but after the > > > > > TTL expires it must consider the IP address stale and not > > > > > establish new (D)TLS sessions. > > > > > > > > > > Cheers, > > > > > -Tiru > > > > > > > > > > > -----Original Message----- > > > > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon > > > > > > Shallow > > > > > > Sent: Saturday, April 7, 2018 6:58 PM > > > > > > To: Konda, Tirumaleswar Reddy > > > > > > ; > > > > > > mohamed.boucadair@orange.com; dots@ietf.org > > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > Hi there, > > > > > > > > > > > > My suggestion would be to make ttl of -1 'infinite', otherwise > > > > > > have a > > > > > minimum > > > > > > value of 300 seconds. The text could read (including referring > > > > > > to the > > > > > optional > > > > > > etc. to be consistent with the rest of the document:- > > > > > > > > > > > > alt-server: FQDN of an alternate DOTS server. > > > > > > > > > > > > This is a required attribute. > > > > > > > > > > > > alt-server-record: A list of IP addresses of an alternate D= OTS > > > > > > server. > > > > > > > > > > > > This is an optional attribute. > > > > > > > > > > > > ttl: Time to live (TTL) of the alternate DOTS server, > > > > > > represented > > > as > > > > > > an integer number of seconds. That is, the time interval > > > > > > that > > > the > > > > > > alternate DOTS server may be used by a DOTS client. > > > > > > > > > > > > The minimum value is '300' seconds, or '-1'. > > > > > > > > > > > > '-1' means that the alternate DOTS server is to be used > > > > > > until the > > > > > alternate > > > > > > DOTS server redirects the traffic with another 3.00 response. > > > > > > There is no TTL expiry. > > > > > > > > > > > > If no 'ttl' is returned in a redirect response, this is > > > equivalent > > > > > > to returning a 'ttl' parameter set to '-1'. > > > > > > > > > > > > If the alternate DOTS server TTL has expired, the DOTS > > > > > > client > > > MUST > > > > > > use the DOTS server(s) that was provisioned using means > > > discussed > > > > > > in Section 4.1. > > > > > > > > > > > > This is an optional attribute. > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > Jon > > > > > > > > > > > > -----Original Message----- > > > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, > > > > > > Tirumaleswar Reddy > > > > > > Sent: 06 April 2018 15:55 > > > > > > To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org > > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > The below proposed change does not look good to me, its causing > > > > > > the DOTS client to ping-pong between multiple DOTS servers > > > > > > because of the TTL > > > > value. > > > > > > The alternate server should serve the DOTS client till there is > > > > > > a planned maintenance, if it is getting over-subscribed it > > > > > > should re-direct the new > > > > > DOTS > > > > > > clients to an alternate server and avoid bouncing the existing > > > > > > DOTS clients > > > > > which > > > > > > have been sending mitigation requests to it. > > > > > > > > > > > > -Tiru > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > > > > Sent: Friday, April 6, 2018 8:06 PM > > > > > > > To: mohamed.boucadair@orange.com; Konda, Tirumaleswar Reddy > > > > > > > ; dots@ietf.org > > > > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > Hi Med, > > > > > > > > > > > > > > Thanks for this. I would like to see the ttl: definition > > > > > > > tightened up (moved away from the DNS TTL version) > > > > > > > > > > > > > > Old > > > > > > > > > > > > > > ttl: Time to live (TTL) of alternate records, represented= as > an > > > > > > > integer number of seconds. That is, the time interval = that > > > > > > > alternate IP addresses may be cached by a DOTS client. > > > > > > > > > > > > > > '0' means that an alternate IP address is only to be > > > > > > > used for > > > the > > > > > > > request in progress, and consequently that IP address > > > > > > > should > > > not > > > > > > > be cached. > > > > > > > > > > > > > > If no 'ttl' is returned in a redirect response, this is > > > equivalent > > > > > > > to returning a 'ttl' parameter set to '0'. > > > > > > > > > > > > > > If 'alt-server-record' has expired, the DOTS client MUS= T > > > > > > > use > > > the > > > > > > > DOTS server(s) that was provisioned using means discuss= ed > in > > > > > > > Section 4.1. Furthermore, a DOTS client MUST NOT use t= he > alt- > > > > > > > server FQDN if the 'alt-server-records' has expired. > > > > > > > > > > > > > > New > > > > > > > > > > > > > > ttl: Time to live (TTL) of the alternate DOTS server, > > > > > > > represented as > > > > > > an > > > > > > > integer number of seconds. That is, the time interval = that > > > > > > > the alternate DOTS server may be cached for use by a > > > > > > > DOTS > > > client. > > > > > > > > > > > > > > '0' means that the alternate DOTS server is only to be > > > > > > > used > > > for the > > > > > > > request in progress, and consequently the alternate DOT= S > > > > > > > server entry should not > > > > > > > be cached. > > > > > > > > > > > > > > If no 'ttl' is returned in a redirect response, this is > > > equivalent > > > > > > > to returning a 'ttl' parameter set to '0'. > > > > > > > > > > > > > > If the alternate DOTS server TTL has expired, the DOTS > > > > > > > client MUST > > > > > > use the > > > > > > > DOTS server(s) that was provisioned using means discuss= ed > in > > > > > > > Section 4.1. > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > > > > > > mohamed.boucadair@orange.com > > > > > > > Sent: 06 April 2018 15:21 > > > > > > > To: Jon Shallow; Konda, Tirumaleswar Reddy; dots@ietf.org > > > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > FWIW, I implemented the change at: > > > > > > > https://github.com/boucadair/draft-ietf-dots-signal-channel/b= l > > > > > > > ob > > > > > > > /m > > > > > > > aste > > > > > > > r/draf > > > > > > > t-ietf-dots-signal-channel.txt > > > > > > > > > > > > > > Cheers, > > > > > > > Med > > > > > > > > > > > > > > > -----Message d'origine----- > > > > > > > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > > > > > Envoy=E9=A0: vendredi 6 avril 2018 15:33 =C0=A0: BOUCADAIR = Mohamed > > > > > > > > IMT/OLN; Konda, Tirumaleswar Reddy; dots@ietf.org Objet=A0:= RE: > > > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > > Excellent. > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: mohamed.boucadair@orange.com [mailto: > > > > > > > > mohamed.boucadair@orange.com] > > > > > > > > Sent: 06 April 2018 14:29 > > > > > > > > To: Jon Shallow; Konda, Tirumaleswar Reddy; rdd@cert.org > > > > > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected > > > > > > > > Signaling > > > > > > > > > > > > > > > > Hi Jon, all, > > > > > > > > > > > > > > > > I'm fine to put ttl at the level of alt-server. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Med > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Jon Shallow > > > > > > > > > [mailto:supjps-ietf@jpshallow.com] > > > > > > > > > Envoy=E9=A0: vendredi 6 avril 2018 14:57 =C0=A0: BOUCADAI= R Mohamed > > > > > > > > > IMT/OLN; Konda, Tirumaleswar Reddy; rdd@cert.org Objet=A0= : RE: > > > > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > > > > Hi there, > > > > > > > > > > > > > > > > > > See inline [Jon3] > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Konda, Tirumales= war > > > > > > > > > > > > Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > > > > > > > Envoy=E9=A0: vendredi 6 avril 2018 07:07 =C0=A0: BO= UCADAIR > > > > > > > > > > > > Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet= =A0: RE: > > > > > > > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > > > Hi Med, > > > > > > > > > > > > > > > > > > > > > > > > The proposed update restricts the client no to do a > > > > > > > > > > > > DNS lookup using the alternate FQDN, further > > > > > > > > > > > > associating a TTL with the name complicates the > > > > > > > > > > > > functionality on the DOTS client to re-establish > > > > > > > > > > > > (D)TLS session with the primary DOTS server after > > > > > > > > > > > > the > > > > > > > > TTL expires. > > > > > > > > > > > > My suggestion is to let the DOTS client continue to > > > > > > > > > > > > use the alternate DOTS > > > > > > > > > > server > > > > > > > > > > > till it gets re-directed. > > > > > > > > > > > > > > > > > > > > > > [Med] This is possible with the current spec. > > > > > > > > > > > > > > > > > > > > > > Triggers for redirect and for falling back to the > > > > > > > > > > > nominal configuration are deployment-specific. The > > > > > > > > > > > current spec allows for almost all the cases > > > > > > > > > > discussed > > > > > > > > > > > so far: > > > > > > > > > > > > > > > > > > > > > > (1) Redirect for the request in progress: A server > > > > > > > > > > > does so by returning > > > > > > > > > > TTL=3D0. > > > > > > > > > > > (2) The alternate server is not involved in fall back > > > > > > > > > > > to the nominal > > > > > > > > > > server: upon > > > > > > > > > > > expiry of ttl of all alternate IP addresses, then fal= l > > > > > > > > > > > back automatically > > > > > > > > > > to the > > > > > > > > > > > nominal server. > > > > > > > > > > > (3) Redirect to an alternate server, which in turn > > > > > > > > > > > will instruct the client > > > > > > > > > > to > > > > > > > > > > > redirect to the "base" configuration: a TTL is > > > > > > > > > > > provided and the alternate > > > > > > > > > > server > > > > > > > > > > > can reply with a redirect code any time before the > > > > > > > > > > > expiry of the TTL. A > > > > > > > > > > long TTL > > > > > > > > > > > can be returned if the alternate server will be > > > > > > > > > > > responsible for > > > > > > > > > > coordinating fall > > > > > > > > > > > back to the base server. > > > > > > > > > > > (4) Stop infinite redirects > > > > > > > > > > > > > > > > > > > > Yes, but (1) and (2) complicate the functionality of th= e > > > > > > > > > > DOTS > > > > > > client. > > > > > > > > > > > > > > > > > > [Med] (1) and (2) is exactly the same functionality > > > > > > > > > required for caching DNS replies. > > > > > > > > > > > > > > > > > > The > > > > > > > > > > only reason for adding alt-server-record in the respons= e > > > > > > > > > > is DNS server may not be reachable by the DOTS server > > > > > > > > > > because of a DDoS > > > > > > > attack. > > > > > > > > > > > > > > > > > > > > > > > > > > > > [Med] Yes. Note that even if the name resolution was > > > > > > > > > allowed, the client has to deal with the TTL indicated in > > > > > > > > > the response...which is exactly the same as (1) and (2). > > > > > > > > > > > > > > > > > > > > > > > > > > > [Jon3] I think where I am struggling here is the > > > > > > > > > overloaded use of TTL > > > > > > > > > - The TTL as per a DNS record and held as a part of > > > > > > > > > alt-server-record and then the TTL after which that the > > > > > > > > > alt-server should be handling the traffic before handling > > > > > > > > > back to the original primary server. It either has to be > > > > > > > > > one or the other, or they have to > > > > > > > have different names. > > > > > > > > > [Jon3] If we are only going to go for one variant for > > > > > > > > > simplicity, then I would prefer that it should be at the > > > > > > > > > level of "alt- > > > > server". > > > > > > > > > Handling the TTL for DNS refresh is normally handled by a > > > > > > > > > resolver library, updated by the DNS packets coming in - > > > > > > > > > unusual for an application > > > > > > > > to have to do that. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I > > > > > > > > > > > > don't think the DOTS mitigation provider will know > > > > > > > > > > > > ahead-of-time the TTL value after which the DOTS > > > > > > > > > > > > client should disconnect communicating with the > > > > > > > > > > > > alternate DOTS server and re-establish (D)TLS > > > > > > > > > > > > session with the primary DOTS > > > > > > server. > > > > > > > > > > > > > > > > > > > > > > [Med] It depends on the nature of the redirect: > > > > > > > > > > > overload, planned > > > > > > > > > > maintenance, > > > > > > > > > > > etc. For planned maintenance, the TTL is known in > general. > > > > > > > > > > > > > > > > > > > > It's the primary DOTS server responsibility to point th= e > > > > > > > > > > DOTS client to an optimal alternate server, where the > > > > > > > > > > client can continue to send migration requests without = a > > > > > > > > > > frequent ping-pong > > > > > > > between servers. > > > > > > > > > > > > > > > > > > [Med] Agree. This is a service configuration problem. > > > > > > > > > [Jon3] Agreed - and the 5 minute minimum ping-pong time i= s > > > > > > > > > a good safety net. > > > > > > > > > ~jon3 > > > > > > > > > > > > > > > > > > > I have seen TURN servers being deployed for several > > > > > > > > > > years with > > > > > > > > > re-direction > > > > > > > > > > but without the need for TTL (see ALTERNATE-SERVER in > > > > > > > > > > https://tools.ietf.org/html/draft-ietf-tram-turnbis-11) > > > > > > > > > > > > > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > From: Dots [mailto:dots-bounces@ietf.org] On > > > > > > > > > > > > > Behalf Of mohamed.boucadair@orange.com > > > > > > > > > > > > > Sent: Thursday, April 5, 2018 4:50 PM > > > > > > > > > > > > > To: Konda, Tirumaleswar Reddy > > > > > > > > > > > > > ; > > > > > > > > > > > > > Jon Shallow ; > > > > > > > > > > > > > dots@ietf.org > > > > > > > > > > > > > Subject: Re: [Dots] Signal Channel - 300 > > > > > > > > > > > > > Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > Tiru, > > > > > > > > > > > > > > > > > > > > > > > > > > I don't see the NEW text as a restriction but as = a > > > > > > > > > > > > > simplification of the > > > > > > > > > > > > client's > > > > > > > > > > > > > behavior. I don't want to over-specify the > > > > > > > > > > > > > redirect > > > behavior. > > > > > > > > > > > > > > > > > > > > > > > > > > Adding another yet layer of resolution will raise > > > > > > > > > > > > > other issues such as the > > > > > > > > > > > > need to > > > > > > > > > > > > > associate a TTL with the name itself. > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > Med > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Konda, > > > > > > > > > > > > > > Tirumaleswar Reddy > > > > > > > > > > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > > > > > > > > > Envoy=E9=A0: jeudi 5 avril 2018 12:06 =C0=A0: J= on > > > > > > > > > > > > > > Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.o= rg > > Objet=A0: > > > > > > > > > RE: > > > > > > > > > > > > > > [Dots] Signal Channel - 300 Redirected Signalin= g > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > > From: Jon Shallow > > > > > > > > > > > > > > > [mailto:supjps-ietf@jpshallow.com] > > > > > > > > > > > > > > > Sent: Thursday, April 5, 2018 1:35 PM > > > > > > > > > > > > > > > To: mohamed.boucadair@orange.com; Konda, > > > > > > > > > > > > > > > Tirumaleswar Reddy > > > > > > > > > > > > > > > ; > > > > > > > > > > > > > > > dots@ietf.org > > > > > > > > > > > > > > > Subject: RE: [Dots] Signal Channel - 300 > > > > > > > > > > > > > > > Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Med, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks for this refresh to 4.6 Redirected > > > > > > > > > > > > > > > Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Some comments > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > #1 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The DOTS server can return the error > > > > > > > > > > > > > > > response code > > > > > > > > > > > > > > > 3.00 in > > > > > > > > > > response > > > > > > > > > > > > > > > to a PUT request from the DOTS client or > > > > > > > > > > > > > > > convey the error > > > > > > > > > > response > > > > > > > > > > > > > > > code 3.00 in a unidirectional notification > > > > > > > > > > > > > > > response from the > > > > > > > > > > DOTS > > > > > > > > > > > > > > > server. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Why is this limited to a PUT request and/or > > > > > > > > > > > > > > > unidirectional notification > > > > > > > > > > > > > > response? > > > > > > > > > > > > > > > - Surely, any response, unsolicited or > > > > > > > > > > > > > > > otherwise can contain a > > > > > > > > > > > > > > > 3.00 > > > > > > > > > > > > > > > - If Observe is not in use, then any > > > > > > > > > > > > > > > unsolicited notification response will > > > > > > > > > > > > > > > potentially get rejected by the coap library > > > > > > > > > > > > > > > layer, so a DOTS Server cannot > > > > > > > > > > > > > > signal > > > > > > > > > > > > > > > maintenance outage other than by closing the > > > session. > > > > > > > > > > > > > > > - I missed this the last review - sorry > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > #2 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If the DOTS client has been redirected to = a > > > > > > > > > > > > > > > DOTS server to > > > > > > > > > which > > > > > > > > > > it > > > > > > > > > > > > > > > has already sent the mitigation request > > > > > > > > > > > > > > > within the last five > > > > > > > > > (5) > > > > > > > > > > > > > > > minutes, it MUST ignore the redirection an= d > > > > > > > > > > > > > > > try to contact other DOTS > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > s/ has already sent the mitigation request/ > > > > > > > > > > > > > > > has already communicated with/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > #3 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > A DOTS client MUST NOT use an alternate > > > > > > > > > > > > > > > IP address to > > > > > > > > > contact > > > > > > > > > > its > > > > > > > > > > > > > > > DOTS server upon expiry of the associat= ed > TTL. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To remove ambiguity over the use of FQDN, thi= s > > > > > > > > > > > > > > > could read > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > A DOTS client MUST NOT use an alternate > > > > > > > > > > > > > > > IP address to > > > > > > > > > contact > > > > > > > > > > its > > > > > > > > > > > > > > > DOTS server upon expiry of the associat= ed > TTL. > > > > > > > > > > > > > > > Furthermore, a > > > > > > > > > > > > DOTS > > > > > > > > > > > > > > > Client MUST NOT use the alt-server FQDN > > > > > > > > > > > > > > > if all of the > > > > > > > > > > > > > > > alt-server- > > > > > > > > > > > > > > records > > > > > > > > > > > > > > > have expired. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Or alternatively > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > alt-server: FQDN of an alternate DOTS ser= ver. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This could read > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > alt-server: FQDN of an alternate DOTS ser= ver. > > > > > > > > > > > > > > > This FQDN is not to be > > > > > > > > > > > > > > used for > > > > > > > > > > > > > > > looking up IP addresses to use, but is there > > > > > > > > > > > > > > > for the SNI extension > > > > > > > > > > > > (7.1. > > > > > > > > > > > > > > (D)TLS > > > > > > > > > > > > > > > Protocol Profile) > > > > > > > > > > > > > > > > > > > > > > > > > > > > I don't think the above restriction is correct > > > > > > > > > > > > > > for the following > > > > > > > > > > reasons: > > > > > > > > > > > > > > > > > > > > > > > > > > > > 1) If the TTL value in the alt-server-record > > > > > > > > > > > > > > expires, DNS lookup can be performed by the DOT= S > > > > > > > > > > > > > > client using the alternate DOTS > > > > > > > > > server > > > > > > > > > > FQDN. > > > > > > > > > > > > > > 2) If the DNS server is reachable, the client > > > > > > > > > > > > > > may want to a DANE lookup to get the IP > > > > > > > > > > > > > > addresses and certificate to validate the > > > > > > > > > > > > > > alternate DOTS server certificate > > > > sent > > > > > > > > > > > > > > in the DTLS handshake. > > > > > > > > > > > > > > > > > > > > > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > > From: Dots [mailto: dots-bounces@ietf.org] On > > > > > > > > > > > > > > > Behalf Of mohamed.boucadair@orange.com > > > > > > > > > > > > > > > Sent: 05 April 2018 08:20 > > > > > > > > > > > > > > > To: Konda, Tirumaleswar Reddy; Jon Shallow; > > > > > > > > > > > > > > > dots@ietf.org > > > > > > > > > > > > > > > Subject: Re: [Dots] Signal Channel - 300 > > > > > > > > > > > > > > > Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Tiru, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Works for me. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I updated the draft with the text additions > > > > > > > > > > > > > > > that were discussed in this thread. The > > > > > > > > > > > > > > > changes can be > > > found at: > > > > > > > > > > > > > > > https://github.com/boucadair/draft-ietf-dots-= s > > > > > > > > > > > > > > > ig > > > > > > > > > > > > > > > na > > > > > > > > > > > > > > > l- > > > > > > > > > > > > > > channel/blob/master/draf > > > > > > > > > > > > > > > t-ietf-dots-signal-channel.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > Med > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Konda, > > > > > > > > > > > > > > > > Tirumaleswar Reddy > > > > > > > > > > > > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > > > > > > > > > > > Envoy=E9=A0: mercredi 4 avril 2018 17:40 = =C0=A0: Jon > > > > > > > > > > > > > > > > Shallow; BOUCADAIR Mohamed IMT/OLN; > > > > > > > > > > > > > > > > dots@ietf.org > > > > > > Objet=A0: RE: > > > > > > > > > > > > > > > > [Dots] Signal Channel - 300 Redirected > > > > > > > > > > > > > > > > Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The TTL value returned under > > > > > > > > > > > > > > > > alt-server-record is equivalent to the DNS > > > > > > > > > > > > > > > > TTL value. A DDoS mitigation provider with > > > > > > > > > > > > > > > > multiple DOTS servers typically re-directs = a > > > > > > > > > > > > > > > > DOTS client to a different DOTS server only > > > > > > > > > > > > > > > > if the alternate DOTS server has the > > > > > > > > > > > > > > > > capacity to handle the requests from the > > > > > > > > > > > > > > > DOTS client. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We can add the following lines to avoid loo= ps : > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If the DOTS client has been redirected to a > > > > > > > > > > > > > > > > DOTS server to which it has already sent th= e > > > > > > > > > > > > > > > > mitigation request within the last five > > > > > > > > > > > > > > > > minutes, it MUST ignore the redirection and > > > > > > > > > > > > > > > > try reaching others servers listed in the > > > > > > > > > > > > > > > > local configuration or discovered using > > > > > > > > > > > > > > > > dynamic means > > > > > > > > such as DHCP or SRV procedures. > > > > > > > > > > > > > > > > This prevents infinite ping-ponging between > > > > > > > > > > > > > > > > servers in case of redirection loops. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > > > > From: Dots [mailto:dots-bounces@ietf.org] > > > > > > > > > > > > > > > > > On Behalf Of Jon Shallow > > > > > > > > > > > > > > > > > Sent: Wednesday, April 4, 2018 8:16 PM > > > > > > > > > > > > > > > > > To: mohamed.boucadair@orange.com; > > > > > > > > > > > > > > > > > dots@ietf.org > > > > > > > > > > > > > > > > > Subject: Re: [Dots] Signal Channel - 300 > > > > > > > > > > > > > > > > > Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi there, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > See inline [Jon] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > > > > From: Dots [mailto: dots-bounces@ietf.org= ] > > > > > > > > > > > > > > > > > On Behalf Of mohamed.boucadair@orange.com > > > > > > > > > > > > > > > > > Sent: 04 April 2018 15:07 > > > > > > > > > > > > > > > > > To: Jon Shallow; dots@ietf.org > > > > > > > > > > > > > > > > > Subject: Re: [Dots] Signal Channel - 300 > > > > > > > > > > > > > > > > > Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Re-, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please see inline. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > > > Med > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Dots > > > > > > > > > > > > > > > > > > [mailto:dots-bounces@ietf.org] De la > > > > > > > > > > > > > > > > > > part de Jon Shallow Envoy=E9=A0: mercre= di 4 > > > > > > > > > > > > > > > > > > avril 2018 > > > 15:31 =C0=A0: > > > > > > > > > > > > > > > > > > dots@ietf.org > > > > > > > > > > > > Objet=A0: > > > > > > > > > > > > > > > > > > [Dots] Signal Channel - 300 Redirected > > > > > > > > > > > > > > > > > > Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi there, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have implemented the 300 > > > > > > > > > > > > > > > > > > Redirected-Signal in my DOTS > > > > > > > > > code. > > > > > > > > > > > > > > > > > > This then raises some questions about > > > usability. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Usability #1 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Architecture 3.2.2 Redirected Signallin= g > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 4. Having redirected the DOTS > > > > > > > > > > > > > > > > > > client, DOTS server A ceases > > > > > > > > > > > > > > sending > > > > > > > > > > > > > > > > > > server signals. The DOTS client > > > > > > > > > > > > > > > > > > likewise stops sending > > > > > > > > > > > > client > > > > > > > > > > > > > > > > > > signals to DOTS server A. DOTS > > > > > > > > > > > > > > > > > > session 1 is > > > > > > > > > > terminated. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Clearly indicates that the original > > > > > > > > > > > > > > > > > > session (Client to Server > > > > > > > > > > > > > > > > > > A) is no more once redirected and only > > > > > > > > > > > > > > > > > > Client to Server B is in > > > > > > > > > > > > use. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > How is the traffic redirected back to > > > > > > > > > > > > > > > > > > Server A once maintenance / overloading > etc. > > > has finished? > > > > > > > > > > > > > > > > > > My assumption is that Server B sends a > > > > > > > > > > > > > > > > > > redirect to go back to Server A as > > > > > > > > > > > > > > > > > > Server A has no way to say over a now > > > > > > > > > > > > > > > > > > non-existent session to say > > > > > > > > > > > > > "come back". > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [Med] That's one possibility. This one > > > > > > > > > > > > > > > > > does not require any update to the > > > > > > > > > > > > > > > > signal- > > > > > > > > > > > > > > > > > channel specification. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Another approach would be to not require > > > > > > > > > > > > > > > > > any redirect signal from server > > > > > > > > > > > > > > > B. > > > > > > > > > > > > > > > > > The client will remove server B's records > > > > > > > > > > > > > > > > > upon the expiry of the TTL and > > > > > > > > > > > > > > > > will fall > > > > > > > > > > > > > > > > > back to the "base" DOTS servers > > > > > > > > > > > > > > > > > configuration that was provisioned to the > > > > > > > > > > > > > > > > client > > > > > > > > > > > > > > > > > using DHCP or whatever mechanism. > > > > > > > > > > > > > > > > > [Jon] OK. The TTL is defined at, > > > > > > > > > > > > > > > > > associated with the IP address level > > > > > > > > > > > > > > > > under alt- > > > > > > > > > > > > > > > > > server-record, not under > > > > > > > > > > > > > > > > > ietf-dots-signal-channel:redirected-signa= l. > > > The ttl > > > > > > > > > > definition is > > > > > > > > > > > > > > > > > ambiguous as to what it refers to and > > > > > > > > > > > > > > > > > perhaps could be tightened up in the > > > > > > > > > > > > > > > > > language (I read it as being associated > > > > > > > > > > > > > > > > > with "addr" in the sense of a DNS > > > > > > > > > > > > > > > > TTL). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Do we need to keep the existing Client > > > > > > > > > > > > > > > > > > to Server A session warm (or perhaps to > > > > > > > > > > > > > > > > > > probe > > > > > > > > > > > > > > > > > > periodically) to see if Server A is > > > > > > > > > > > > > > > > > > capable of handling the Client again by > > > > > > > > > > > > > > > > > > a server response extension to the > > > > > > > > > > > > > > > > > > protocol (e.g. a > > > > > > > > > > > > > > > > > > 3.01) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [Med] Redirect was initially introduced t= o > > > > > > > > > > > > > > > > > manage a server overload, so I > > > > > > > > > > > > > > > > don't > > > > > > > > > > > > > > > > > think it makes sense to probe or maintain > > > > > > > > > > > > > > > > > a session with > > > > > > > > > server > > > > > > > > > > A. > > > > > > > > > > > > > > > > > [Jon] Agreed, but I needed to raise the > > > question. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Should there be a retry period paramete= r > > > > > > > > > > > > > > > > > > added in to the > > > > > > > > > > > > > > > > > > 3.00 protocol (as I read it, ttl only > > > > > > > > > > > > > > > > > > refers to the IP > > > > > > > > > > address)? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [Med] The client will automatically switc= h > > > > > > > > > > > > > > > > > to Server A when all alternate > > > > > > > > > > > > > > > > records > > > > > > > > > > > > > > > > > expire. > > > > > > > > > > > > > > > > > [Jon] OK - again the 4.6 text needs to ge= t > > > > > > > > > > > > > > > > > tightened up to reflect this as > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > intent. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Usability #2 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Server A says "Redirect to Server B" du= e > > > > > > > > > > > > > > > > > > to > > > > > > > overloading. > > > > > > > > > > > > > > > > > > Server B accepts things for a while and > > > > > > > > > > > > > > > > > > then is instructed/decides to redirect > > > > > > > > > > > > > > > > > > traffic > > > back to A. > > > > > > > > > > > > > > > > > > Server A is left still overload > > > > > > > > > > > > > > > > > > configured to redirect to B. How shoul= d > > > > > > > > > > > > > > > > > > the client handle this as there is no > > > > > > > > > > > > > > > > > > suitable > > > > > > > > > > > > > > > > > Server? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [Med] This is a service configuration > problem. > > > > > > > > > > > > > > > > > We may > > > > > > > ask: > > > > > > > > > > > > > > > > > * the client to log the error and notify > > > > > > > > > > > > > > > > > the > > > > > > > > administrator. > > > > > > > > > > > > > > > > > * and/or stop the redirection after n cyc= les. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Still, this does not solve the problem. > > > > > > > > > > > > > > > > > [Jon] Agreed there is a problem here > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I agree that there needs to be > > > > > > > > > > > > > > > > > > co-ordination between Server A and > > > > > > > > > > > > > > > > > > Server B, but user error may > > > > > > > creep in. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Usability #3 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Server A says "Redirect to Server B" as > > > > > > > > > > > > > > > > > > it going to be shut down because of > > > > > > > > > > > > > > > > > > maintenance. Server B accepts things > > > > > > > > > > > > > > > > > > for a while and then is instructed (in > > > > > > > > > > > > > > > > > > probable user > > > > > > > > > > > > > > > > > > error) to redirect traffic back to A > > > > > > > > > > > > > > > > > > (perhaps because it has hit an overload > > > > > > > > > > > > > > > > > > condition). How should the client > > > > > > > > > > > > > > > > > handle this? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [Med] Isn't this a sub-case or #2? > > > > > > > > > > > > > > > > > [Jon] Yes, but I wanted to bring in Serve= r > > > > > > > > > > > > > > > > > A being alive and able to > > > > > > > > > > > > > > > > respond > > > > > > > > > > > > > > > > > versus Server A down and not responding > > > > > > > > > > > > > > > > > due to > > > > > > > > maintenance. > > > > > > > > > > > > > > > > > [Jon] With my better understanding of TTL > > > > > > > > > > > > > > > > > we still have an issue if the TTL expires > > > > > > > > > > > > > > > > > and Server A is having an extended > > > > > > > > > > outage. > > > > > > > > > > > > > > > > > How do we recover from that? > > > > > > > > > > > > > > > > > ~jon > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________= _ > > > > > > > > > > > > > > > > > > __ __ ___ Dots mailing list > > > > > > > > > > > > > > > > > > Dots@ietf.org > > > > > > > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/d= o > > > > > > > > > > > > > > > > > > ts > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _________________________________________= _ > > > > > > > > > > > > > > > > > __ __ _ Dots mailing list Dots@ietf.org > > > > > > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dot= s > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _________________________________________= _ > > > > > > > > > > > > > > > > > __ __ _ Dots mailing list Dots@ietf.org > > > > > > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dot= s > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _____________________________________________= _ > > > > > > > > > > > > > > > _ Dots mailing list Dots@ietf.org > > > > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > Dots mailing list > > > > > > > > > > > > > Dots@ietf.org > > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > Dots mailing list > > > > > > > > > > Dots@ietf.org > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > Dots mailing list > > > > > > > > > Dots@ietf.org > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Dots mailing list > > > > > > > Dots@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > _______________________________________________ > > > > > > Dots mailing list > > > > > > Dots@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > _______________________________________________ > > > > > > Dots mailing list > > > > > > Dots@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Mon Apr 9 04:29:40 2018 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 993A5127873 for ; Mon, 9 Apr 2018 04:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 F1v8f8774bDn for ; Mon, 9 Apr 2018 04:29:35 -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 2D0DF127871 for ; Mon, 9 Apr 2018 04:29:35 -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=1523273374; 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: dlp-product:dlp-version:dlp-reaction: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-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-Network-Message-Id: 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=2 WIXkqUVeUE1gIWkL+humSvev4qPUA2DuU5Bl2z1ss U=; b=h74xX04Nf/KzSy8MFY/jL5Q3WbcWs+nMZGnIhaIT0cxN oHCY0R0dfoxNqYL899fVgpxOiYsFl6FDcT9ptiUhFdgS/0syz9 Eyi4hhGTkRKuMry/mCQOzFojd7Sgbp9FqjGhEFrEoEI2PPrXUf D4t2cgR1/eycnt92MJQ8Aeqe3+o= Received: from DNVEXAPP1N06.corpzone.internalzone.com (DNVEXAPP1N06.corpzone.internalzone.com [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 16ce_5a6d_3c12756a_0fa1_4343_8a29_3c9ef104aec4; Mon, 09 Apr 2018 06:29:33 -0500 Received: from DNVEXUSR1N14.corpzone.internalzone.com (10.44.48.87) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 9 Apr 2018 05:29:24 -0600 Received: from DNVEXUSR1N12.corpzone.internalzone.com (10.44.48.85) by DNVEXUSR1N14.corpzone.internalzone.com (10.44.48.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 9 Apr 2018 05:29:23 -0600 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXUSR1N12.corpzone.internalzone.com (10.44.48.85) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Mon, 9 Apr 2018 05:29:23 -0600 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (10.44.176.240) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 9 Apr 2018 05:29:22 -0600 Received: from BN6PR16MB1425.namprd16.prod.outlook.com (10.172.207.19) by BN6PR16MB1569.namprd16.prod.outlook.com (10.172.208.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.653.12; Mon, 9 Apr 2018 11:29:20 +0000 Received: from BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d]) by BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d%2]) with mapi id 15.20.0653.015; Mon, 9 Apr 2018 11:29:20 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Signal Channel - 300 Redirected Signaling Thread-Index: AdPMGSyCaQQbv+vLSW+0gkDbU7HOEwAAo7xAAAH7T4AAARdqYAAhoxEAAAGQiwAAAKyNYAAF3e1QACUKCFAAAZEMQAAIeXTgAARcGhAAAoG7gAABGXwAAAAjBIAAAa5ZgAAAiReAAABpmzAAL32aAABWbPEwAAIv/gAAAPiKMAAA7T0AAACbH4AAAR48IAAD29GAAAAS23A= Date: Mon, 9 Apr 2018 11:29:20 +0000 Message-ID: References: <014f01d3cc19$2e3880e0$8aa982a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7E7B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <019901d3cc23$a93ff8e0$fbbfeaa0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8524@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <004e01d3ccb4$d505e7f0$7f11b7d0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8758@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEF912A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEF93EE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <008501d3cda6$c860d210$59227630$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF951 1@OPEXCLILMA3 . corporate.adroot.infra.ftgroup> <00b001d3cdab$ba8caec0$2fa60c40$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF975C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <00b801d3cdb4$982dc4a0$c8894de0$@jpshallow.com> <015101d3ce74$351393c0$9f3abb40$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEFA190@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <01f501d3cfde$4014ca30$c03e5e90$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEFA2DF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEFA44B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DEFA44B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR16MB1569; 7:wZx0cJ1MmO2lDqLwKHiUn+z33EAwZTjPqF6FHImic8ckqxKvK27t58ySEB102fds8j49HON0K8LUFGGcvydT8/flGaYQn6PV0tzZz6oa+jzuG+ju1GcWqGoUIVhIL8BuNAU0f8GurpxmzQ8y6JslVKhQPjP6Dq/ZOddaCLd5pJcdxWJRwMDvX4Xw086zIcibmwRHTiW071p4s4YGyoI6HscwFjdJTuIz8h351hP9sIoEB+w+MhKSegaXd4iI/SgA x-ms-exchange-antispam-srfa-diagnostics: SOS; X-MS-Office365-Filtering-Correlation-Id: b9906c6c-8b4a-4d20-ece1-08d59e0d235f x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BN6PR16MB1569; x-ms-traffictypediagnostic: BN6PR16MB1569: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(166708455590820)(788757137089)(18271650672692)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231221)(944501327)(52105095)(3002001)(10201501046)(93006095)(93001095)(6041310)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(6072148)(201708071742011); SRVR:BN6PR16MB1569; BCL:0; PCL:0; RULEID:; SRVR:BN6PR16MB1569; x-forefront-prvs: 0637FCE711 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39380400002)(376002)(346002)(39860400002)(396003)(32952001)(57704003)(51444003)(13464003)(189003)(199004)(53754006)(55784002)(106356001)(74316002)(110136005)(305945005)(6506007)(59450400001)(316002)(186003)(53546011)(14454004)(105586002)(99286004)(86362001)(2501003)(5250100002)(93886005)(76176011)(5660300001)(7696005)(26005)(25786009)(7736002)(66066001)(68736007)(9686003)(53936002)(6306002)(6246003)(33656002)(476003)(81156014)(8936002)(11346002)(8676002)(446003)(2900100001)(81166006)(486006)(478600001)(16200700003)(55016002)(6116002)(3846002)(80792005)(53946003)(966005)(102836004)(72206003)(3660700001)(229853002)(2906002)(97736004)(6436002)(3280700002)(85282002)(579004)(559001)(569006); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR16MB1569; H:BN6PR16MB1425.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 2cYXYKLuw1d4IbSomKarLXo234RE+8FHoU1fVgtx4NqCBYcLBWdMmBfQRPOw/HlYP5J/0sm5XzZPUqbQ9P2/za0bIYVUsvvF1Mz+HcexUmlEN0td4pRy3eavlEC45PBDzjhTtyZ6Zq9TW6ZFYMSnzUsJuDOTfahTzb9iCYKr4EEilc5Mvm/tDkCd3wXcBGWE5k2KF0SADAOvikGKlcsZmmb6WsaVPPhxz3e0cAd80WnTBNk5tVx0342U8u6vo0j90KRBdyCespdBsHNx1QFWvSB1tpXGkbIhYj666j77Z/0YPbALEMQIitW40gPYG77+8B4mmtdR7rl2jKVofU3BNWrgFdi10Rm+SLJo7KTVmdNTUbpcWn+15ZY3Q56BGGZzDQBLUTAJlSJ3vZ6TSuVRtITv12P1haMa8GBXXcJQay4= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: b9906c6c-8b4a-4d20-ece1-08d59e0d235f X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2018 11:29:20.5033 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR16MB1569 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 <6260> : inlines <6554> : streams <1783535> : uri <2622479> Archived-At: Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling 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, 09 Apr 2018 11:29:40 -0000 > -----Original Message----- > From: mohamed.boucadair@orange.com > [mailto:mohamed.boucadair@orange.com] > Sent: Monday, April 9, 2018 4:49 PM > To: Konda, Tirumaleswar Reddy ; > Jon Shallow ; dots@ietf.org > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling >=20 > Re-, >=20 > Focusing on this part of your answer: >=20 > "No, DNS TTL lifetime does not mean existing session has to be disconnec= ted > after the TTL expires." >=20 > This is exactly the disconnect. We are not discussing **DNS TTL** but the > validity time of a an alternate server as provided in a DOTS redirect sig= nal. When the server can explicitly re-direct the client, why provide the validi= ty time of an alternate server ? >=20 > If a finite validity time is provided, the client will use that alternate= server till that > validly time expires. Passed that timer, the client will contact its "nor= mal" servers > to place requests. That behavior is straightforward. >=20 > If you insist to interpret TTL as DNS TTL, then RFC1035 says the followin= g: >=20 > " TTL a 32 bit signed integer that specifies the time interva= l > that the resource record may be cached before the source > of the information should again be consulted. " > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >=20 > In our case, the source of the information is the normal server :) Yes, caching is done based on TTL to avoid DNS lookups but it does not mean= the client has to disconnect existing=20 sessions after the TTL expires. -Tiru >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Konda, > > Tirumaleswar Reddy Envoy=E9=A0: lundi 9 avril 2018 12:08 =C0=A0: BOUCAD= AIR > > Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet=A0: Re: [Dots] Signal > > Channel - 300 Redirected Signaling > > > > > -----Original Message----- > > > From: mohamed.boucadair@orange.com > > > [mailto:mohamed.boucadair@orange.com] > > > Sent: Monday, April 9, 2018 2:27 PM > > > To: Jon Shallow ; Konda, Tirumaleswar > > > Reddy ; dots@ietf.org > > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > Re-, > > > > > > Please see inline. > > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > Envoy=E9=A0: lundi 9 avril 2018 10:39 > > > > =C0=A0: 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; > > > > dots@ietf.org Objet=A0: RE: [Dots] Signal Channel - 300 Redirected > > > > Signaling > > > > > > > > Hi all, > > > > > > > > Should 'ttl' actually be 'lifetime' to remove any confusion over wh= ether > > > > this is DNS TTL usage or not ? > > > > > > [Med] we do already have a lifetime in the cbor mapping table. So, I > > suggest to > > > maintain ttl but focus on its definition to avoid confusion. > > > > Agreed. > > > > > > > > > > > > > Otherwise see inline [Jon] > > > > > > > > Regards > > > > > > > > Jon > > > > > > > > -----Original Message----- > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, > > > > Tirumaleswar Reddy > > > > Sent: 09 April 2018 09:23 > > > > To: mohamed.boucadair@orange.com; Jon Shallow; dots@ietf.org > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > -----Original Message----- > > > > > From: mohamed.boucadair@orange.com > > > > > [mailto:mohamed.boucadair@orange.com] > > > > > Sent: Monday, April 9, 2018 1:15 PM > > > > > To: Konda, Tirumaleswar Reddy > > > > > ; > > > > > Jon Shallow ; dots@ietf.org > > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > Tiru, > > > > > > > > > > What about this update ones? > > > > > > > > > > =3D=3D=3D=3D=3D=3D=3D > > > > > ttl: Time to live (TTL) of the alternate DOTS server, > > > > > represented > > as > > > > > an integer number of seconds. That is, the time interval > > > > > that > > the > > > > > alternate DOTS server may be cached for use by a DOTS clien= t. > > > > > > > > > > A lifetime of negative one (-1) indicates indefinite TTL. = This > > > > > value means that the alternate DOTS server is to be used > > > > > until > > the > > > > > alternate DOTS server redirects the traffic with another 3.= 00 > > > > > response. > > > > > > > > > > If no 'ttl' is returned in a redirect response, this is > > equivalent > > > > > to returning a 'ttl' parameter set to '-1'. > > > > > > > > Above text looks good. > > > > > > > > [Jon] Later in the text, there is reference to a minimum of 5 > > > > minutes before being able to switch back to the original DOTS > > > > server. Don't we need to say a 5 minute (300 secs) minimum here? > > > > > > [Med] That reference is when explicit redirect signals are involved. > > > > Yup. > > > > > > > > > > > > > > > > > > > If the alternate DOTS server TTL has expired, the DOTS > > > > > client > > MUST > > > > > use the DOTS server(s), that was provisioned using means > > discussed > > > > > in Section 4.1, for creating new requests. > > > > > > > > It looks too restrictive, typically the DNS TTL values are > > > > short-lived (e.g.. few seconds) but the sessions are long-lived. > > > > Why not replace "for creating new requests" with "for creating new > > > > DOTS session" ? > > > > > > > > [Jon] I think that once the alternate DOTS server's lifetime has > > > > expired, the DOTS client should try to establish a connection with > > > > the appropriate "normal" DOTS servers, > > > > > > [Med] Bingo. > > > > No, DNS TTL lifetime does not mean existing session has to be > > disconnected after the TTL expires. > > > > -Tiru > > > > > > > > if that fails, continue to use the alternate DOTS > > > > server, but periodically retry the "normal" servers to try to > > > > maintain resilience of service. > > > > > > [Med] The document does not specify the behavior for selecting among > > multiple > > > servers. So, this details are out of scope. > > > > > > After all, the outage (e.g. maintenance window) of > > > > the original DOTS server may have to be extended, and being down, > > > > cannot respond with a 3.00 to instruct DOTS client to stay with > > > > the alternate DOTS server. > > > > > > > > > > [Med] For such cases, it is safe to return an indefinite TTL + > > > alternate > > server to > > > coordinate the fallback behavior. > > > > > > > --Tiru > > > > > > > > > > > > > > This is an optional attribute. > > > > > =3D=3D=3D > > > > > > > > > > Cheers, > > > > > Med > > > > > > > > > > > -----Message d'origine----- > > > > > > De=A0: Konda, Tirumaleswar Reddy > > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > Envoy=E9=A0: lundi 9 avril 2018 08:51 =C0=A0: Jon Shallow; BOUC= ADAIR > > > > > > Mohamed IMT/OLN; dots@ietf.org Objet=A0: RE: > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > Hi Jon, > > > > > > > > > > > > I partially agree with the suggested update. A IP address is > > > > > > cached until the TTL value expires, the DOTS client need not > > > > > > disconnect existing sessions after the TTL expires, but after > > > > > > the TTL expires it must consider the IP address stale and not > > > > > > establish new (D)TLS sessions. > > > > > > > > > > > > Cheers, > > > > > > -Tiru > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon > > > > > > > Shallow > > > > > > > Sent: Saturday, April 7, 2018 6:58 PM > > > > > > > To: Konda, Tirumaleswar Reddy > > > > > > > ; > > > > > > > mohamed.boucadair@orange.com; dots@ietf.org > > > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected > > > > > > > Signaling > > > > > > > > > > > > > > Hi there, > > > > > > > > > > > > > > My suggestion would be to make ttl of -1 'infinite', > > > > > > > otherwise have a > > > > > > minimum > > > > > > > value of 300 seconds. The text could read (including > > > > > > > referring to the > > > > > > optional > > > > > > > etc. to be consistent with the rest of the document:- > > > > > > > > > > > > > > alt-server: FQDN of an alternate DOTS server. > > > > > > > > > > > > > > This is a required attribute. > > > > > > > > > > > > > > alt-server-record: A list of IP addresses of an alternate= DOTS > > > > > > > server. > > > > > > > > > > > > > > This is an optional attribute. > > > > > > > > > > > > > > ttl: Time to live (TTL) of the alternate DOTS server, > > > > > > > represented > > > > as > > > > > > > an integer number of seconds. That is, the time > > > > > > > interval that > > > > the > > > > > > > alternate DOTS server may be used by a DOTS client. > > > > > > > > > > > > > > The minimum value is '300' seconds, or '-1'. > > > > > > > > > > > > > > '-1' means that the alternate DOTS server is to be > > > > > > > used until the > > > > > > alternate > > > > > > > DOTS server redirects the traffic with another 3.00 response. > > > > > > > There is no TTL expiry. > > > > > > > > > > > > > > If no 'ttl' is returned in a redirect response, this > > > > > > > is > > > > equivalent > > > > > > > to returning a 'ttl' parameter set to '-1'. > > > > > > > > > > > > > > If the alternate DOTS server TTL has expired, the DOTS > > > > > > > client > > > > MUST > > > > > > > use the DOTS server(s) that was provisioned using > > > > > > > means > > > > discussed > > > > > > > in Section 4.1. > > > > > > > > > > > > > > This is an optional attribute. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > > > > > > Konda, Tirumaleswar Reddy > > > > > > > Sent: 06 April 2018 15:55 > > > > > > > To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org > > > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected > > > > > > > Signaling > > > > > > > > > > > > > > The below proposed change does not look good to me, its > > > > > > > causing the DOTS client to ping-pong between multiple DOTS > > > > > > > servers because of the TTL > > > > > value. > > > > > > > The alternate server should serve the DOTS client till there > > > > > > > is a planned maintenance, if it is getting over-subscribed > > > > > > > it should re-direct the new > > > > > > DOTS > > > > > > > clients to an alternate server and avoid bouncing the > > > > > > > existing DOTS clients > > > > > > which > > > > > > > have been sending mitigation requests to it. > > > > > > > > > > > > > > -Tiru > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > > > > > Sent: Friday, April 6, 2018 8:06 PM > > > > > > > > To: mohamed.boucadair@orange.com; Konda, Tirumaleswar > > > > > > > > Reddy ; dots@ietf.org > > > > > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected > > > > > > > > Signaling > > > > > > > > > > > > > > > > Hi Med, > > > > > > > > > > > > > > > > Thanks for this. I would like to see the ttl: definition > > > > > > > > tightened up (moved away from the DNS TTL version) > > > > > > > > > > > > > > > > Old > > > > > > > > > > > > > > > > ttl: Time to live (TTL) of alternate records, > > > > > > > > represented as > > an > > > > > > > > integer number of seconds. That is, the time interva= l that > > > > > > > > alternate IP addresses may be cached by a DOTS client= . > > > > > > > > > > > > > > > > '0' means that an alternate IP address is only to be > > > > > > > > used for > > > > the > > > > > > > > request in progress, and consequently that IP > > > > > > > > address should > > > > not > > > > > > > > be cached. > > > > > > > > > > > > > > > > If no 'ttl' is returned in a redirect response, this > > > > > > > > is > > > > equivalent > > > > > > > > to returning a 'ttl' parameter set to '0'. > > > > > > > > > > > > > > > > If 'alt-server-record' has expired, the DOTS client > > > > > > > > MUST use > > > > the > > > > > > > > DOTS server(s) that was provisioned using means > > > > > > > > discussed > > in > > > > > > > > Section 4.1. Furthermore, a DOTS client MUST NOT > > > > > > > > use the > > alt- > > > > > > > > server FQDN if the 'alt-server-records' has expired. > > > > > > > > > > > > > > > > New > > > > > > > > > > > > > > > > ttl: Time to live (TTL) of the alternate DOTS server, > > > > > > > > represented as > > > > > > > an > > > > > > > > integer number of seconds. That is, the time interva= l that > > > > > > > > the alternate DOTS server may be cached for use by a > > > > > > > > DOTS > > > > client. > > > > > > > > > > > > > > > > '0' means that the alternate DOTS server is only to > > > > > > > > be used > > > > for the > > > > > > > > request in progress, and consequently the alternate > > > > > > > > DOTS server entry should not > > > > > > > > be cached. > > > > > > > > > > > > > > > > If no 'ttl' is returned in a redirect response, this > > > > > > > > is > > > > equivalent > > > > > > > > to returning a 'ttl' parameter set to '0'. > > > > > > > > > > > > > > > > If the alternate DOTS server TTL has expired, the > > > > > > > > DOTS client MUST > > > > > > > use the > > > > > > > > DOTS server(s) that was provisioned using means > > > > > > > > discussed > > in > > > > > > > > Section 4.1. > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > > > > > > > mohamed.boucadair@orange.com > > > > > > > > Sent: 06 April 2018 15:21 > > > > > > > > To: Jon Shallow; Konda, Tirumaleswar Reddy; dots@ietf.org > > > > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected > > > > > > > > Signaling > > > > > > > > > > > > > > > > FWIW, I implemented the change at: > > > > > > > > https://github.com/boucadair/draft-ietf-dots-signal-channe > > > > > > > > l/bl > > > > > > > > ob > > > > > > > > /m > > > > > > > > aste > > > > > > > > r/draf > > > > > > > > t-ietf-dots-signal-channel.txt > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Med > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Jon Shallow > > > > > > > > > [mailto:supjps-ietf@jpshallow.com] > > > > > > > > > Envoy=E9=A0: vendredi 6 avril 2018 15:33 =C0=A0: BOUCADAI= R > > > > > > > > > Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; dots@ietf.org > Objet=A0: RE: > > > > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > > > > Excellent. > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: mohamed.boucadair@orange.com [mailto: > > > > > > > > > mohamed.boucadair@orange.com] > > > > > > > > > Sent: 06 April 2018 14:29 > > > > > > > > > To: Jon Shallow; Konda, Tirumaleswar Reddy; rdd@cert.org > > > > > > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected > > > > > > > > > Signaling > > > > > > > > > > > > > > > > > > Hi Jon, all, > > > > > > > > > > > > > > > > > > I'm fine to put ttl at the level of alt-server. > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > Med > > > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Jon Shallow > > > > > > > > > > [mailto:supjps-ietf@jpshallow.com] > > > > > > > > > > Envoy=E9=A0: vendredi 6 avril 2018 14:57 =C0=A0: BOUCAD= AIR > > > > > > > > > > Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; rdd@cert.or= g > Objet=A0: RE: > > > > > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > > > > > > Hi there, > > > > > > > > > > > > > > > > > > > > See inline [Jon3] > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Konda, > > > > > > > > > > > > > Tirumaleswar Reddy > > > > > > > > > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > > > > > > > > Envoy=E9=A0: vendredi 6 avril 2018 07:07 =C0=A0: > > > > > > > > > > > > > BOUCADAIR Mohamed IMT/OLN; Jon Shallow; > dots@ietf.org Objet=A0: RE: > > > > > > > > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Med, > > > > > > > > > > > > > > > > > > > > > > > > > > The proposed update restricts the client no to > > > > > > > > > > > > > do a DNS lookup using the alternate FQDN, > > > > > > > > > > > > > further associating a TTL with the name > > > > > > > > > > > > > complicates the functionality on the DOTS client > > > > > > > > > > > > > to re-establish (D)TLS session with the primary > > > > > > > > > > > > > DOTS server after the > > > > > > > > > TTL expires. > > > > > > > > > > > > > My suggestion is to let the DOTS client continue > > > > > > > > > > > > > to use the alternate DOTS > > > > > > > > > > > server > > > > > > > > > > > > till it gets re-directed. > > > > > > > > > > > > > > > > > > > > > > > > [Med] This is possible with the current spec. > > > > > > > > > > > > > > > > > > > > > > > > Triggers for redirect and for falling back to the > > > > > > > > > > > > nominal configuration are deployment-specific. The > > > > > > > > > > > > current spec allows for almost all the cases > > > > > > > > > > > discussed > > > > > > > > > > > > so far: > > > > > > > > > > > > > > > > > > > > > > > > (1) Redirect for the request in progress: A server > > > > > > > > > > > > does so by returning > > > > > > > > > > > TTL=3D0. > > > > > > > > > > > > (2) The alternate server is not involved in fall > > > > > > > > > > > > back to the nominal > > > > > > > > > > > server: upon > > > > > > > > > > > > expiry of ttl of all alternate IP addresses, then > > > > > > > > > > > > fall back automatically > > > > > > > > > > > to the > > > > > > > > > > > > nominal server. > > > > > > > > > > > > (3) Redirect to an alternate server, which in turn > > > > > > > > > > > > will instruct the client > > > > > > > > > > > to > > > > > > > > > > > > redirect to the "base" configuration: a TTL is > > > > > > > > > > > > provided and the alternate > > > > > > > > > > > server > > > > > > > > > > > > can reply with a redirect code any time before the > > > > > > > > > > > > expiry of the TTL. A > > > > > > > > > > > long TTL > > > > > > > > > > > > can be returned if the alternate server will be > > > > > > > > > > > > responsible for > > > > > > > > > > > coordinating fall > > > > > > > > > > > > back to the base server. > > > > > > > > > > > > (4) Stop infinite redirects > > > > > > > > > > > > > > > > > > > > > > Yes, but (1) and (2) complicate the functionality of > > > > > > > > > > > the DOTS > > > > > > > client. > > > > > > > > > > > > > > > > > > > > [Med] (1) and (2) is exactly the same functionality > > > > > > > > > > required for caching DNS replies. > > > > > > > > > > > > > > > > > > > > The > > > > > > > > > > > only reason for adding alt-server-record in the > > > > > > > > > > > response is DNS server may not be reachable by the > > > > > > > > > > > DOTS server because of a DDoS > > > > > > > > attack. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [Med] Yes. Note that even if the name resolution was > > > > > > > > > > allowed, the client has to deal with the TTL indicated > > > > > > > > > > in the response...which is exactly the same as (1) and = (2). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [Jon3] I think where I am struggling here is the > > > > > > > > > > overloaded use of TTL > > > > > > > > > > - The TTL as per a DNS record and held as a part of > > > > > > > > > > alt-server-record and then the TTL after which that > > > > > > > > > > the alt-server should be handling the traffic before > > > > > > > > > > handling back to the original primary server. It > > > > > > > > > > either has to be one or the other, or they have to > > > > > > > > have different names. > > > > > > > > > > [Jon3] If we are only going to go for one variant for > > > > > > > > > > simplicity, then I would prefer that it should be at > > > > > > > > > > the level of "alt- > > > > > server". > > > > > > > > > > Handling the TTL for DNS refresh is normally handled > > > > > > > > > > by a resolver library, updated by the DNS packets > > > > > > > > > > coming in - unusual for an application > > > > > > > > > to have to do that. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I > > > > > > > > > > > > > don't think the DOTS mitigation provider will > > > > > > > > > > > > > know ahead-of-time the TTL value after which the > > > > > > > > > > > > > DOTS client should disconnect communicating with > > > > > > > > > > > > > the alternate DOTS server and re-establish > > > > > > > > > > > > > (D)TLS session with the primary DOTS > > > > > > > server. > > > > > > > > > > > > > > > > > > > > > > > > [Med] It depends on the nature of the redirect: > > > > > > > > > > > > overload, planned > > > > > > > > > > > maintenance, > > > > > > > > > > > > etc. For planned maintenance, the TTL is known in > > general. > > > > > > > > > > > > > > > > > > > > > > It's the primary DOTS server responsibility to point > > > > > > > > > > > the DOTS client to an optimal alternate server, > > > > > > > > > > > where the client can continue to send migration > > > > > > > > > > > requests without a frequent ping-pong > > > > > > > > between servers. > > > > > > > > > > > > > > > > > > > > [Med] Agree. This is a service configuration problem. > > > > > > > > > > [Jon3] Agreed - and the 5 minute minimum ping-pong > > > > > > > > > > time is a good safety net. > > > > > > > > > > ~jon3 > > > > > > > > > > > > > > > > > > > > > I have seen TURN servers being deployed for several > > > > > > > > > > > years with > > > > > > > > > > re-direction > > > > > > > > > > > but without the need for TTL (see ALTERNATE-SERVER > > > > > > > > > > > in > > > > > > > > > > > https://tools.ietf.org/html/draft-ietf-tram-turnbis- > > > > > > > > > > > 11) > > > > > > > > > > > > > > > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > From: Dots [mailto:dots-bounces@ietf.org] On > > > > > > > > > > > > > > Behalf Of mohamed.boucadair@orange.com > > > > > > > > > > > > > > Sent: Thursday, April 5, 2018 4:50 PM > > > > > > > > > > > > > > To: Konda, Tirumaleswar Reddy > > > > > > > > > > > > > > ; > > > > > > > > > > > > > > Jon Shallow ; > > > > > > > > > > > > > > dots@ietf.org > > > > > > > > > > > > > > Subject: Re: [Dots] Signal Channel - 300 > > > > > > > > > > > > > > Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > > > Tiru, > > > > > > > > > > > > > > > > > > > > > > > > > > > > I don't see the NEW text as a restriction but > > > > > > > > > > > > > > as a simplification of the > > > > > > > > > > > > > client's > > > > > > > > > > > > > > behavior. I don't want to over-specify the > > > > > > > > > > > > > > redirect > > > > behavior. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Adding another yet layer of resolution will > > > > > > > > > > > > > > raise other issues such as the > > > > > > > > > > > > > need to > > > > > > > > > > > > > > associate a TTL with the name itself. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > Med > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Konda, > > > > > > > > > > > > > > > Tirumaleswar Reddy > > > > > > > > > > > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > > > > > > > > > > Envoy=E9=A0: jeudi 5 avril 2018 12:06 =C0=A0:= Jon > > > > > > > > > > > > > > > Shallow; BOUCADAIR Mohamed IMT/OLN; > > > > > > > > > > > > > > > dots@ietf.org > > > Objet=A0: > > > > > > > > > > RE: > > > > > > > > > > > > > > > [Dots] Signal Channel - 300 Redirected > > > > > > > > > > > > > > > Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > > > From: Jon Shallow > > > > > > > > > > > > > > > > [mailto:supjps-ietf@jpshallow.com] > > > > > > > > > > > > > > > > Sent: Thursday, April 5, 2018 1:35 PM > > > > > > > > > > > > > > > > To: mohamed.boucadair@orange.com; Konda, > > > > > > > > > > > > > > > > Tirumaleswar Reddy > > > > > > > > > > > > > > > > ; > > > > > > > > > > > > > > > > dots@ietf.org > > > > > > > > > > > > > > > > Subject: RE: [Dots] Signal Channel - 300 > > > > > > > > > > > > > > > > Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Med, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks for this refresh to 4.6 Redirected > > > > > > > > > > > > > > > > Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Some comments > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > #1 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The DOTS server can return the error > > > > > > > > > > > > > > > > response code > > > > > > > > > > > > > > > > 3.00 in > > > > > > > > > > > response > > > > > > > > > > > > > > > > to a PUT request from the DOTS client > > > > > > > > > > > > > > > > or convey the error > > > > > > > > > > > response > > > > > > > > > > > > > > > > code 3.00 in a unidirectional > > > > > > > > > > > > > > > > notification response from the > > > > > > > > > > > DOTS > > > > > > > > > > > > > > > > server. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Why is this limited to a PUT request > > > > > > > > > > > > > > > > and/or unidirectional notification > > > > > > > > > > > > > > > response? > > > > > > > > > > > > > > > > - Surely, any response, unsolicited or > > > > > > > > > > > > > > > > otherwise can contain a > > > > > > > > > > > > > > > > 3.00 > > > > > > > > > > > > > > > > - If Observe is not in use, then any > > > > > > > > > > > > > > > > unsolicited notification response will > > > > > > > > > > > > > > > > potentially get rejected by the coap > > > > > > > > > > > > > > > > library layer, so a DOTS Server cannot > > > > > > > > > > > > > > > signal > > > > > > > > > > > > > > > > maintenance outage other than by closing > > > > > > > > > > > > > > > > the > > > > session. > > > > > > > > > > > > > > > > - I missed this the last review - sorry > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > #2 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If the DOTS client has been redirected > > > > > > > > > > > > > > > > to a DOTS server to > > > > > > > > > > which > > > > > > > > > > > it > > > > > > > > > > > > > > > > has already sent the mitigation request > > > > > > > > > > > > > > > > within the last five > > > > > > > > > > (5) > > > > > > > > > > > > > > > > minutes, it MUST ignore the redirection > > > > > > > > > > > > > > > > and try to contact other DOTS > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > s/ has already sent the mitigation > > > > > > > > > > > > > > > > request/ has already communicated with/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > #3 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > A DOTS client MUST NOT use an > > > > > > > > > > > > > > > > alternate IP address to > > > > > > > > > > contact > > > > > > > > > > > its > > > > > > > > > > > > > > > > DOTS server upon expiry of the > > > > > > > > > > > > > > > > associated > > TTL. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To remove ambiguity over the use of FQDN, > > > > > > > > > > > > > > > > this could read > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > A DOTS client MUST NOT use an > > > > > > > > > > > > > > > > alternate IP address to > > > > > > > > > > contact > > > > > > > > > > > its > > > > > > > > > > > > > > > > DOTS server upon expiry of the > > > > > > > > > > > > > > > > associated > > TTL. > > > > > > > > > > > > > > > > Furthermore, a > > > > > > > > > > > > > DOTS > > > > > > > > > > > > > > > > Client MUST NOT use the alt-server > > > > > > > > > > > > > > > > FQDN if all of the > > > > > > > > > > > > > > > > alt-server- > > > > > > > > > > > > > > > records > > > > > > > > > > > > > > > > have expired. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Or alternatively > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > alt-server: FQDN of an alternate DOTS s= erver. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This could read > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > alt-server: FQDN of an alternate DOTS s= erver. > > > > > > > > > > > > > > > > This FQDN is not to be > > > > > > > > > > > > > > > used for > > > > > > > > > > > > > > > > looking up IP addresses to use, but is > > > > > > > > > > > > > > > > there for the SNI extension > > > > > > > > > > > > > (7.1. > > > > > > > > > > > > > > > (D)TLS > > > > > > > > > > > > > > > > Protocol Profile) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I don't think the above restriction is > > > > > > > > > > > > > > > correct for the following > > > > > > > > > > > reasons: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 1) If the TTL value in the alt-server-record > > > > > > > > > > > > > > > expires, DNS lookup can be performed by the > > > > > > > > > > > > > > > DOTS client using the alternate DOTS > > > > > > > > > > server > > > > > > > > > > > FQDN. > > > > > > > > > > > > > > > 2) If the DNS server is reachable, the > > > > > > > > > > > > > > > client may want to a DANE lookup to get the > > > > > > > > > > > > > > > IP addresses and certificate to validate the > > > > > > > > > > > > > > > alternate DOTS server certificate > > > > > sent > > > > > > > > > > > > > > > in the DTLS handshake. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > > > From: Dots [mailto: dots-bounces@ietf.org] > > > > > > > > > > > > > > > > On Behalf Of mohamed.boucadair@orange.com > > > > > > > > > > > > > > > > Sent: 05 April 2018 08:20 > > > > > > > > > > > > > > > > To: Konda, Tirumaleswar Reddy; Jon > > > > > > > > > > > > > > > > Shallow; dots@ietf.org > > > > > > > > > > > > > > > > Subject: Re: [Dots] Signal Channel - 300 > > > > > > > > > > > > > > > > Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Tiru, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Works for me. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I updated the draft with the text > > > > > > > > > > > > > > > > additions that were discussed in this > > > > > > > > > > > > > > > > thread. The changes can be > > > > found at: > > > > > > > > > > > > > > > > https://github.com/boucadair/draft-ietf-do > > > > > > > > > > > > > > > > ts-s > > > > > > > > > > > > > > > > ig > > > > > > > > > > > > > > > > na > > > > > > > > > > > > > > > > l- > > > > > > > > > > > > > > > channel/blob/master/draf > > > > > > > > > > > > > > > > t-ietf-dots-signal-channel.txt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > > Med > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Konda, > > > > > > > > > > > > > > > > > Tirumaleswar Reddy > > > > > > > > > > > > > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.c > > > > > > > > > > > > > > > > > om] Envoy=E9=A0: mercredi 4 avril 2018 17= :40 > > > > > > > > > > > > > > > > > =C0=A0: Jon Shallow; BOUCADAIR Mohamed > > > > > > > > > > > > > > > > > IMT/OLN; dots@ietf.org > > > > > > > Objet=A0: RE: > > > > > > > > > > > > > > > > > [Dots] Signal Channel - 300 Redirected > > > > > > > > > > > > > > > > > Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The TTL value returned under > > > > > > > > > > > > > > > > > alt-server-record is equivalent to the > > > > > > > > > > > > > > > > > DNS TTL value. A DDoS mitigation > > > > > > > > > > > > > > > > > provider with multiple DOTS servers > > > > > > > > > > > > > > > > > typically re-directs a DOTS client to a > > > > > > > > > > > > > > > > > different DOTS server only if the > > > > > > > > > > > > > > > > > alternate DOTS server has the capacity > > > > > > > > > > > > > > > > > to handle the requests from the > > > > > > > > > > > > > > > > DOTS client. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We can add the following lines to avoid l= oops : > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If the DOTS client has been redirected > > > > > > > > > > > > > > > > > to a DOTS server to which it has already > > > > > > > > > > > > > > > > > sent the mitigation request within the > > > > > > > > > > > > > > > > > last five minutes, it MUST ignore the > > > > > > > > > > > > > > > > > redirection and try reaching others > > > > > > > > > > > > > > > > > servers listed in the local > > > > > > > > > > > > > > > > > configuration or discovered using > > > > > > > > > > > > > > > > > dynamic means > > > > > > > > > such as DHCP or SRV procedures. > > > > > > > > > > > > > > > > > This prevents infinite ping-ponging > > > > > > > > > > > > > > > > > between servers in case of redirection lo= ops. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -Tiru > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > > > > > From: Dots > > > > > > > > > > > > > > > > > > [mailto:dots-bounces@ietf.org] On > > > > > > > > > > > > > > > > > > Behalf Of Jon Shallow > > > > > > > > > > > > > > > > > > Sent: Wednesday, April 4, 2018 8:16 PM > > > > > > > > > > > > > > > > > > To: mohamed.boucadair@orange.com; > > > > > > > > > > > > > > > > > > dots@ietf.org > > > > > > > > > > > > > > > > > > Subject: Re: [Dots] Signal Channel - > > > > > > > > > > > > > > > > > > 300 Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi there, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > See inline [Jon] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > > > > > From: Dots [mailto: > > > > > > > > > > > > > > > > > > dots-bounces@ietf.org] On Behalf Of > > > > > > > > > > > > > > > > > > mohamed.boucadair@orange.com > > > > > > > > > > > > > > > > > > Sent: 04 April 2018 15:07 > > > > > > > > > > > > > > > > > > To: Jon Shallow; dots@ietf.org > > > > > > > > > > > > > > > > > > Subject: Re: [Dots] Signal Channel - > > > > > > > > > > > > > > > > > > 300 Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Re-, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please see inline. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, Med > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: > > > > > > > > > > > > > > > > > > > Dots [mailto:dots-bounces@ietf.org] > > > > > > > > > > > > > > > > > > > De la part de Jon Shallow Envoy=E9=A0= : > > > > > > > > > > > > > > > > > > > mercredi 4 avril 2018 > > > > 15:31 =C0=A0: > > > > > > > > > > > > > > > > > > > dots@ietf.org > > > > > > > > > > > > > Objet=A0: > > > > > > > > > > > > > > > > > > > [Dots] Signal Channel - 300 > > > > > > > > > > > > > > > > > > > Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi there, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have implemented the 300 > > > > > > > > > > > > > > > > > > > Redirected-Signal in my DOTS > > > > > > > > > > code. > > > > > > > > > > > > > > > > > > > This then raises some questions > > > > > > > > > > > > > > > > > > > about > > > > usability. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Usability #1 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Architecture 3.2.2 Redirected > > > > > > > > > > > > > > > > > > > Signalling > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 4. Having redirected the DOTS > > > > > > > > > > > > > > > > > > > client, DOTS server A ceases > > > > > > > > > > > > > > > sending > > > > > > > > > > > > > > > > > > > server signals. The DOTS > > > > > > > > > > > > > > > > > > > client likewise stops sending > > > > > > > > > > > > > client > > > > > > > > > > > > > > > > > > > signals to DOTS server A. > > > > > > > > > > > > > > > > > > > DOTS session 1 is > > > > > > > > > > > terminated. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Clearly indicates that the original > > > > > > > > > > > > > > > > > > > session (Client to Server > > > > > > > > > > > > > > > > > > > A) is no more once redirected and > > > > > > > > > > > > > > > > > > > only Client to Server B is in > > > > > > > > > > > > > use. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > How is the traffic redirected back > > > > > > > > > > > > > > > > > > > to Server A once maintenance / > > > > > > > > > > > > > > > > > > > overloading > > etc. > > > > has finished? > > > > > > > > > > > > > > > > > > > My assumption is that Server B sends > > > > > > > > > > > > > > > > > > > a redirect to go back to Server A as > > > > > > > > > > > > > > > > > > > Server A has no way to say over a > > > > > > > > > > > > > > > > > > > now non-existent session to say > > > > > > > > > > > > > > "come back". > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [Med] That's one possibility. This one > > > > > > > > > > > > > > > > > > does not require any update to the > > > > > > > > > > > > > > > > > signal- > > > > > > > > > > > > > > > > > > channel specification. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Another approach would be to not > > > > > > > > > > > > > > > > > > require any redirect signal from > > > > > > > > > > > > > > > > > > server > > > > > > > > > > > > > > > > B. > > > > > > > > > > > > > > > > > > The client will remove server B's > > > > > > > > > > > > > > > > > > records upon the expiry of the TTL and > > > > > > > > > > > > > > > > > will fall > > > > > > > > > > > > > > > > > > back to the "base" DOTS servers > > > > > > > > > > > > > > > > > > configuration that was provisioned to > > > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > client > > > > > > > > > > > > > > > > > > using DHCP or whatever mechanism. > > > > > > > > > > > > > > > > > > [Jon] OK. The TTL is defined at, > > > > > > > > > > > > > > > > > > associated with the IP address level > > > > > > > > > > > > > > > > > under alt- > > > > > > > > > > > > > > > > > > server-record, not under > > > > > > > > > > > > > > > > > > ietf-dots-signal-channel:redirected-sig= nal. > > > > The ttl > > > > > > > > > > > definition is > > > > > > > > > > > > > > > > > > ambiguous as to what it refers to and > > > > > > > > > > > > > > > > > > perhaps could be tightened up in the > > > > > > > > > > > > > > > > > > language (I read it as being > > > > > > > > > > > > > > > > > > associated with "addr" in the sense of > > > > > > > > > > > > > > > > > > a DNS > > > > > > > > > > > > > > > > > TTL). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Do we need to keep the existing > > > > > > > > > > > > > > > > > > > Client to Server A session warm (or > > > > > > > > > > > > > > > > > > > perhaps to probe > > > > > > > > > > > > > > > > > > > periodically) to see if Server A is > > > > > > > > > > > > > > > > > > > capable of handling the Client again > > > > > > > > > > > > > > > > > > > by a server response extension to > > > > > > > > > > > > > > > > > > > the protocol (e.g. a > > > > > > > > > > > > > > > > > > > 3.01) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [Med] Redirect was initially > > > > > > > > > > > > > > > > > > introduced to manage a server > > > > > > > > > > > > > > > > > > overload, so I > > > > > > > > > > > > > > > > > don't > > > > > > > > > > > > > > > > > > think it makes sense to probe or > > > > > > > > > > > > > > > > > > maintain a session with > > > > > > > > > > server > > > > > > > > > > > A. > > > > > > > > > > > > > > > > > > [Jon] Agreed, but I needed to raise > > > > > > > > > > > > > > > > > > the > > > > question. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Should there be a retry period > > > > > > > > > > > > > > > > > > > parameter added in to the > > > > > > > > > > > > > > > > > > > 3.00 protocol (as I read it, ttl > > > > > > > > > > > > > > > > > > > only refers to the IP > > > > > > > > > > > address)? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [Med] The client will automatically > > > > > > > > > > > > > > > > > > switch to Server A when all alternate > > > > > > > > > > > > > > > > > records > > > > > > > > > > > > > > > > > > expire. > > > > > > > > > > > > > > > > > > [Jon] OK - again the 4.6 text needs to > > > > > > > > > > > > > > > > > > get tightened up to reflect this as > > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > intent. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Usability #2 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Server A says "Redirect to Server B" > > > > > > > > > > > > > > > > > > > due to > > > > > > > > overloading. > > > > > > > > > > > > > > > > > > > Server B accepts things for a while > > > > > > > > > > > > > > > > > > > and then is instructed/decides to > > > > > > > > > > > > > > > > > > > redirect traffic > > > > back to A. > > > > > > > > > > > > > > > > > > > Server A is left still overload > > > > > > > > > > > > > > > > > > > configured to redirect to B. How > > > > > > > > > > > > > > > > > > > should the client handle this as > > > > > > > > > > > > > > > > > > > there is no suitable > > > > > > > > > > > > > > > > > > Server? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [Med] This is a service configuration > > problem. > > > > > > > > > > > > > > > > > > We may > > > > > > > > ask: > > > > > > > > > > > > > > > > > > * the client to log the error and > > > > > > > > > > > > > > > > > > notify the > > > > > > > > > administrator. > > > > > > > > > > > > > > > > > > * and/or stop the redirection after n c= ycles. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Still, this does not solve the problem. > > > > > > > > > > > > > > > > > > [Jon] Agreed there is a problem here > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I agree that there needs to be > > > > > > > > > > > > > > > > > > > co-ordination between Server A and > > > > > > > > > > > > > > > > > > > Server B, but user error may > > > > > > > > creep in. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Usability #3 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Server A says "Redirect to Server B" > > > > > > > > > > > > > > > > > > > as it going to be shut down because > > > > > > > > > > > > > > > > > > > of maintenance. Server B accepts > > > > > > > > > > > > > > > > > > > things for a while and then is > > > > > > > > > > > > > > > > > > > instructed (in probable user > > > > > > > > > > > > > > > > > > > error) to redirect traffic back to A > > > > > > > > > > > > > > > > > > > (perhaps because it has hit an > > > > > > > > > > > > > > > > > > > overload condition). How should the > > > > > > > > > > > > > > > > > > > client > > > > > > > > > > > > > > > > > > handle this? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [Med] Isn't this a sub-case or #2? > > > > > > > > > > > > > > > > > > [Jon] Yes, but I wanted to bring in > > > > > > > > > > > > > > > > > > Server A being alive and able to > > > > > > > > > > > > > > > > > respond > > > > > > > > > > > > > > > > > > versus Server A down and not > > > > > > > > > > > > > > > > > > responding due to > > > > > > > > > maintenance. > > > > > > > > > > > > > > > > > > [Jon] With my better understanding of > > > > > > > > > > > > > > > > > > TTL we still have an issue if the TTL > > > > > > > > > > > > > > > > > > expires and Server A is having an > > > > > > > > > > > > > > > > > > extended > > > > > > > > > > > outage. > > > > > > > > > > > > > > > > > > How do we recover from that? > > > > > > > > > > > > > > > > > > ~jon > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ____________________________________ > > > > > > > > > > > > > > > > > > > ____ __ __ ___ Dots mailing list > > > > > > > > > > > > > > > > > > > Dots@ietf.org > > > > > > > > > > > > > > > > > > > https://www.ietf.org/mailman/listinf > > > > > > > > > > > > > > > > > > > o/do > > > > > > > > > > > > > > > > > > > ts > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ______________________________________ > > > > > > > > > > > > > > > > > > ____ __ __ _ Dots mailing list > > > > > > > > > > > > > > > > > > Dots@ietf.org > > > > > > > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/ > > > > > > > > > > > > > > > > > > dots > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ______________________________________ > > > > > > > > > > > > > > > > > > ____ __ __ _ Dots mailing list > > > > > > > > > > > > > > > > > > Dots@ietf.org > > > > > > > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/ > > > > > > > > > > > > > > > > > > dots > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > __________________________________________ > > > > > > > > > > > > > > > > ____ _ Dots mailing list Dots@ietf.org > > > > > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > > > > > > > > > > > > > ______________________________________________ > > > > > > > > > > > > > > _ Dots mailing list Dots@ietf.org > > > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > Dots mailing list > > > > > > > > > > > Dots@ietf.org > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > Dots mailing list > > > > > > > > > > Dots@ietf.org > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Dots mailing list > > > > > > > > Dots@ietf.org > > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Dots mailing list > > > > > > > Dots@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Dots mailing list > > > > > > > Dots@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > _______________________________________________ > > > > Dots mailing list > > > > Dots@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots From nobody Mon Apr 9 04:33:50 2018 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 6062612778E for ; Mon, 9 Apr 2018 04:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hb6u2Wo9Ojud for ; Mon, 9 Apr 2018 04:33:44 -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 C82AC127871 for ; Mon, 9 Apr 2018 04:33:43 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.90_1) (envelope-from ) id 1f5V3N-0003Wy-Up; Mon, 09 Apr 2018 12:33:42 +0100 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , , References: <008401d3c4fd$216d0840$644718c0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF1067@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <014801d3c5b7$94c67f00$be537d00$@jpshallow.com> <009a01d3cdab$150b4c40$3f21e4c0$@jpshallow.com> <00cf01d3cdbe$24876650$6d9632f0$@jpshallow.com> <01fd01d3cfe4$a71b6580$f5523080$@jpshallow.com> In-Reply-To: Date: Mon, 9 Apr 2018 12:33:43 +0100 Message-ID: <024901d3cff6$9d4beea0$d7e3cbe0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_024A_01D3CFFE.FF140020" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGlexwLZckIYJuvKwEmwuQr1rXL6AKpdMHOAgMRKpIBsBKRFgKXgqsdAxHSSssB/GODugGyw551AT90vc8BfRxiYwGyPN+Io7PO9dA= Content-Language: en-gb Archived-At: Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 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, 09 Apr 2018 11:33:48 -0000 This is a multipart message in MIME format. ------=_NextPart_000_024A_01D3CFFE.FF140020 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Tiru, =20 See inline [Jon1] =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 09 April 2018 11:32 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 =20 Hi Jon, =20 Please see inline=20 =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Monday, April 9, 2018 2:55 PM To: Konda, Tirumaleswar Reddy ; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 =20 Hi Tiru, =20 If a DOTS client knows the full scope of the Networks that it is allowed = to use in a ACL or mitigate request, and the DOTS server limits any update = from that client to the scope of Networks (with any unexpected side effects = that may have), then there is no difference in my mind as to whether the DOTS clients fills in the destination-network, or the DOTS server does so on = the DOTS client=92s behalf before ACL instantiation if destination-network = is not defined. =20 [TR] The above model only works when the DOTS server and DOTS client are directly communicating with each other (In the above, the DOTS server = knows the DOTS client identity to enforce the scope but will not the DOTS = client identity in the presence of a client-domain DOTS gateway).=20 =20 [Jon1] The last para of =9310. Security Considerations=94 states DOTS servers MUST verify that requesting DOTS clients are entitled to trigger actions on a given IP prefix. That is, only actions on IP resources that belong to the DOTS client' domain MUST be authorized by a DOTS server. The exact mechanism for the DOTS servers to validate that the target prefixes are within the scope of the DOTS client's domain is deployment-specific. =20 [Jon1] So it makes no difference if the DOTS client happens to be an = agent part of a client-domain DOTS gateway. If the client-domain DOTS gateway = is hiding all the =91behind=92 clients and presenting as single client, = there is no issue. However, if the =91behind=92 clients are presented as 2 or more = =91cuid=92s by the DOTS gateway, then either the scope is per =91cuid=92, or if = =91cdid=92s are being applied by the upstream server domain DOTS gateway then on a per =91cdid=92 basis if wanted. =20 For a client behind a client domain DOTS gateway, there may be non = public IP addresses that the (DMS) client is responsible for, but these should = never be sent out through the DOTS gateway (and should be rejected by the DOTS server as out of scope). There does have to be a common agreement = between DOTS client & DOTS server as to what Networks are in scope, but the DOTS client currently cannot request this from the DOTS server and has to be agreed out of band. =20 [TR] I don=92t see a new problem, even when a DOTS client sends a = mitigation request it needs to know if the targets conveyed in the mitigation = request are in its scope or not. =20 [Jon1] but again, the DOTS server MUST verify the IP prefix is valid, so = has to know scope. I agree that the DOTS client (or client domain DOTS = gateway) needs to know (today out of band) what is the scope of what is valid to request. The challenge comes when the DOTS server=92s scope is = reconfigured, but not yet updated on the DOTS client. =20 =20 There is no reason as to why the DOTS server cannot maintain a valid = scope of Networks that the client domain DOTS gateway is allowed to request = for validity checking =96 unless I am missing something? =20 [TR] You are partially right, the DOTS server does not know the valid = scope of prefixes that a DOTS client behind client-domain DOTS gateway is = allowed to request. =20 [Jon1] Again, the last para of 10. stands here, and so the scope has to = be known by the DOTS server. =20 Troubleshooting has kept me in a job for more years than I care to = remember, anything to aid troubleshooting is what I am interested in and so = totally agree that rogue DOTS client=92s capabilities need to be kept under = control with suitable logging to aid diagnosis is a major plus. However in this case, the implicit rule is no different to the DOTS client requesting = the full Networks scope in an ACL request. =20 [TR] If the client is not authorized to request the full network scope, = it can detected by the client-domain DOTS gateway and rejects the filtering rule by comparing the destination-networks=20 specified in the ACE. [Jon1] Agreed, it is the responsibility of the client domain DOTS = gateway to only allow out valid networks that are valid within the DOTS server=92s = scope. =20 [Jon1] Should we support a way for the client domain DOTS gateway (i.e. DOTS client agent) to programmatically get the current valid network = scope from the DOTS server? ~jon1 =20 -Tiru =20 Regards =20 Jon =20 From: Konda, Tirumaleswar Reddy [mailto: = TirumaleswarReddy_Konda@mcafee.com] Sent: 07 April 2018 06:48 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 =20 Hi Jon, =20 DOTS clients (intelligent DDoS mitigation system, application server) = will know the destination networks, what kind of DOTS clients will not know = the destination networks they are allowed to use ? DOTS clients could be behind client-domain DOTS gateway, DOTS server = will have no way to validate the DOTS client identity sending the ACE request = to determine the destination IP addresses in its scope, it will only know = the destination IP addresses in the DOTS client domain scope.=20 Further, the implicit rule can be misused by compromised DOTS clients = (e.g. black-list good traffic to the entire DOTS client domain) and it=92s a troubleshooting nightmare to find the culprit device adversely impacting = the entire network. =20 Cheers, -Tiru =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Friday, April 6, 2018 9:14 PM To: Konda, Tirumaleswar Reddy ; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 =20 Hi Tiru, =20 The DOTS server is likely to have a scope of IP addresses that are valid = for the client to ask for protection for based on the cuid or cdid. =20 The DOTS client may have some knowledge of the scope IPs by some out of = band method, but programmatically cannot ask the server what they are.=20 =20 If a client specifies a destination network that is out of the valid = scope of IP addresses, then the ACE request will get rejected. The client may then have a challenge to work out what destination networks it is = allowed to use. =20 How does a client set up a blacklist for all the IPS within his allowed scope if it does not know what the scope is? =20 If the client has not provided a destination network, then the DOTS = server can auto-fill in the missing information at the time of the ACE instantiation =96 and this then handles if the scope of IP addresses = change. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 06 April 2018 16:19 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 =20 I don=92t understand how the DOTS server/mitigation will fill it in at = time of ACE instantiation, and why can=92t the DOTS client fill the destination network details ? =20 -Tiru =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Friday, April 6, 2018 6:58 PM To: Konda, Tirumaleswar Reddy ; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 =20 Hi there, =20 There is no current way to request of a DOTS Server as to what is the = set of IP networks that a DOTS client can use either within a mitigation = request or to set up an ACL other than by =93testing for ok or not ok=94 with lots = of different IP addresses. =20 There is a reasonable likelihood of the scope of valid IPs from the = Server=92s perspective will change over time. So, unless a DOTS client wants to control a specific destination network, then my suggestion would be to = leave the ACE destination network empty and for the DOTS Server / DOTS = mitigator (how is out of scope) to fill it in at time of ACE instantiation. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 27 March 2018 13:49 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 =20 Please see inline [TR] =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Tuesday, March 27, 2018 4:07 PM To: Konda, Tirumaleswar Reddy ; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 =20 Hi Tiru / Med =20 See inline [Jon] =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 27 March 2018 09:47 To: mohamed.boucadair@orange.com; Jon Shallow; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 =20 I also support to mandate destination-network for immediately enforced filtering rules. [Jon] This can be enforced / inserted by the DOTS Server for all the destination networks of the domain that the DOTS client =91belongs=92 = to. That said, it would be good to always have the destination network in an ACL = as it can be validated and cross-checked whenever the legitimate set of = domain protected IPs are updated. [Jon] However, what happens to the Destination network in the case of a = call home DOTS client that becomes a quasi DOTS server and the Destination networks are somewhere out on the Internet? =20 [TR] DDOS is a targeted attack, so the DOTS client can specify the destination network targeted by devices in the DOTS server domain and = the DOTS server can validate if the destination network is indeed targeted = by its devices. =20 -Tiru =20 From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed....boucadair@orange.com =20 Sent: Tuesday, March 27, 2018 1:09 PM To: Jon Shallow ; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 =20 Hi Jon,=20 =20 Thank you for the comments. =20 Please see inline. =20 Cheers, Med =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : lundi 26 mars 2018 14:23 =C0 : dots@ietf.org Objet : [Dots] IETF 101 Presentation Data Channel Issue #4 =20 Hi there, =20 As per Med=92s presentation to the IETF 101 =20 Issue #4: Per-Domain or Per-client Filters? =20 =95 Conclusion =96 Filters that are activated only during mitigation time are on a = per-client basis =95 Filters are per-domain when are immediately applied =20 =93Filters are per-domain when are immediately applied=94 is what I have = an challenge with. =20 If we have a compromised or rogue DOTS client, the simple use of = something like curl, along with the client certificates etc. can be used to = generate any ACL with activation-type :=3D =91immediate=92 which is then = immediately applied for all traffic within the domain as per the above. =20 [Med] Yes. FWIW, this attack is called out in the security = considerations section:=20 =20 =93Nevertheless, an attacker who can access a DOTS client is technically capable of launching various attacks, such as: =20 ..; =20 o Set invalid ACL entries, which may prevent legitimate traffic from being forwarded. Likewise, invalid ACL entries may lead to forward DDoS traffic. =93 [Jon] Agreed that the attack is covered off in the Security section, but = we should be limiting the possibility / scope of the attack vector by = enforcing some rules as to what is / is not allowed. Allowing a DOTS client to be able to affect all the traffic within the domain is a huge risk to me = and should not be allowed. =20 So, a ACL that blacklists the DNS server, or drops all port 443 traffic = etc. can easily cause all of the other clients / devices within the domain to = be taken off air. Putting the intelligence into the DOTS server to not = allow this to happen could be a challenge. [The signal channel is much harder to compromise and affect traffic = flows to other areas within the domain] =20 I believe that an ACL instantiated by a DOTS client (immediate or when-mitigating) should only apply to the DOTS client=92s traffic which = means that the destination-network has to be a part of the ACL, whether = implicitly added by the DOTS server, or by the DOTS client and suitably validated. =20 [Med] Putting aside that I don=92t parse =93DOTS client=92s traffic=94, [Jon] I was referring to all the traffic flows that a DOTS client can legitimately request control of to the DOTS server that are within the = scope of what the DOTS client is protecting (which may or may not be the DOTS client=92s IP address). I interpret your answer as a support to this question raised for issue = #4: * =93Should we mandate destination-network to be present for immediately enforced filters?=94 [Jon] See response to Tiru=92s Agreement above. ~Jon There is nothing to stop the DOTS server or DOTS mitigator merging = common ACLs to reduce the number of ACLs within the mitigation device. =20 As a side note =93mitigation-time=94 is perhaps a bad name as it implies = a time period =96 something like =93when-mitigating=94 to me is clearer. [Med] Fixed in my local copy. Thank you. =20 Regards =20 Jon ------=_NextPart_000_024A_01D3CFFE.FF140020 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

See inline = [Jon1]

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = Konda, Tirumaleswar Reddy
Sent: 09 April 2018 = 11:32
To: Jon Shallow; mohamed.boucadair@orange.com; = dots@ietf.org
Subject: Re: [Dots] IETF 101 Presentation Data = Channel Issue #4

 

Hi = Jon,

 

Please see inline =

 

From: Jon Shallow = [mailto:supjps-ietf@jpshallow.com]
Sent: Monday, April 9, = 2018 2:55 PM
To: Konda, Tirumaleswar Reddy = <TirumaleswarReddy_Konda@McAfee.com>; = mohamed.boucadair@orange.com; dots@ietf.org
Subject: RE: = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

Hi Tiru,

 

If a DOTS client knows = the full scope of the Networks that it is allowed to use in a ACL or = mitigate request, and the DOTS server limits any update from that client = to the scope of Networks (with any unexpected side effects that may = have), then there is no difference in my mind as to whether the DOTS = clients fills in the destination-network, or the DOTS server does so on = the DOTS client’s behalf before ACL instantiation if = destination-network is not defined.

 

[TR] The = above model only works when the DOTS server and DOTS client are directly = communicating with each other (In the above, the DOTS server knows the = DOTS client identity to enforce the scope but will not the DOTS client = identity in the presence of a client-domain DOTS gateway). =

 

[Jon1] The last para of = “10. Security Considerations” states

=A0=A0 DOTS servers MUST verify that requesting = DOTS clients are entitled to

=A0=A0 = trigger actions on a given IP prefix.=A0 That is, only actions on = IP

=A0=A0 = resources that belong to the DOTS client' domain MUST be = authorized

=A0=A0 by a = DOTS server.=A0 The exact mechanism for the DOTS servers = to

=A0=A0 = validate that the target prefixes are within the scope of the = DOTS

=A0=A0 client's domain is = deployment-specific.

 

[Jon1] So it makes no = difference if the DOTS client happens to be an agent part of a = client-domain DOTS gateway.=A0 If the client-domain DOTS gateway is = hiding all the ‘behind’ clients and presenting as single = client, there is no issue.=A0 However, if the ‘behind’ = clients are presented as 2 or more ‘cuid’s by the DOTS = gateway, then either the scope is per ‘cuid’, or if = ‘cdid’s are being applied by the upstream server domain DOTS = gateway then on a per ‘cdid’ basis if = wanted.

 

For a client behind a = client domain DOTS gateway, there may be non public IP addresses that = the (DMS) client is responsible for, but these should never be sent out = through the DOTS gateway (and should be rejected by the DOTS server as = out of scope).  There does have to be a common agreement between = DOTS client & DOTS server as to what Networks are in scope, but the = DOTS client currently cannot request this from the DOTS server and has = to be agreed out of band.

 

[TR] I = don’t see a new problem, even when a DOTS client sends a = mitigation request it needs to know if the targets conveyed in the = mitigation request are in its scope or not.

 

[Jon1] but again, the = DOTS server MUST verify the IP prefix is valid, so has to know scope.=A0 = I agree that the DOTS client (or client domain DOTS gateway) needs to = know (today out of band) what is the scope of what is valid to = request.=A0 The challenge comes when the DOTS server’s scope is = reconfigured, but not yet updated on the DOTS client.=A0 =

 

There is no reason as to = why the DOTS server cannot maintain a valid scope of Networks that the = client domain DOTS gateway is allowed to request for validity checking = – unless I am missing something?

 

[TR] You are = partially right, the DOTS server does not know the valid scope of = prefixes that a DOTS client behind client-domain DOTS gateway is allowed = to request.

 

[Jon1] Again, the last = para of 10. stands here, and so the scope has to be known by the DOTS = server.

 

Troubleshooting has kept = me in a job for more years than I care to remember, anything to aid = troubleshooting is what I am interested in and so totally agree that = rogue DOTS client’s capabilities need to be kept under control = with suitable logging to aid diagnosis is a major plus.  However in = this case, the implicit rule is no different to the DOTS client = requesting the full Networks scope in an ACL = request.

 

[TR] If the = client is not authorized to request the full network scope, it can = detected by the client-domain DOTS gateway and rejects the filtering = rule by comparing the destination-networks

        specifi= ed in the ACE.

[Jon1] Agreed, it is the = responsibility of the client domain DOTS gateway to only allow out valid = networks that are valid within the DOTS server’s = scope.

 

[Jon1] Should we support = a way for the client domain DOTS gateway =A0(i.e. DOTS client agent) to = programmatically get the current valid network scope from the DOTS = server?

~jon1

 

-Tiru

 

Regards

 

Jon

 

From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Kond= a@mcafee.com]
Sent: 07 April 2018 06:48
To: Jon = Shallow; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: RE: = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

Hi = Jon,

 

DOTS clients (intelligent DDoS = mitigation system, application server) will know the destination = networks, what kind of DOTS clients will not know the destination = networks they are allowed to use ?

DOTS clients could be behind = client-domain DOTS gateway, DOTS server will have no way to validate the = DOTS client identity sending the ACE request to determine the = destination IP addresses in its scope, it will only know the destination = IP addresses in the DOTS client domain scope.

Further, the implicit rule can be = misused by compromised DOTS clients (e.g. black-list good traffic to the = entire DOTS client domain) and it’s a  troubleshooting = nightmare to find the culprit device adversely impacting the entire = network.

 

Cheers,

-Tiru

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Friday, April 6, 2018 9:14 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: RE: = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

Hi Tiru,

 

The DOTS server is = likely to have a scope of IP addresses that are valid for the client to = ask for protection for based on the cuid or = cdid.

 

The DOTS client may have = some knowledge of the scope IPs by some out of band method, but = programmatically cannot ask the server what they are. =

 

If a client specifies a = destination network that is out of the valid scope of IP addresses, then = the ACE request will get rejected.  The client may then have a = challenge to work out what destination networks it is allowed to = use.

 

How does a client set up = a blacklist for all the IPS within his allowed scope if it does not know = what the scope is?

 

If the client has not = provided a destination network, then the DOTS server can auto-fill in = the missing information at the time of the ACE instantiation – and = this then handles if the scope of IP addresses = change.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 06 April 2018 = 16:19
To: Jon Shallow; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: Re: = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

I don’t = understand how the DOTS server/mitigation will fill it in at time of ACE = instantiation, and why can’t the DOTS client fill the destination = network details ?

 

-Tiru

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Friday, April 6, 2018 6:58 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: RE: = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

Hi there,

 

There is no current way = to request of a DOTS Server as to what is the set of IP networks that a = DOTS client can use either within a mitigation request or to set up an = ACL other than by “testing for ok or not ok” with lots of = different IP addresses.

 

There is a reasonable = likelihood of the scope of valid IPs from the Server’s perspective = will change over time.  So, unless a DOTS client wants to control a = specific destination network, then my suggestion would be to leave the = ACE destination network empty and for the DOTS Server / DOTS mitigator = (how is out of scope) to fill it in at time of ACE = instantiation.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 27 March 2018 = 13:49
To: Jon Shallow; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: Re: = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

Please see inline = [TR]

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Tuesday, March 27, 2018 4:07 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: RE: = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

Hi Tiru / Med

 

See inline = [Jon]

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 27 March 2018 = 09:47
To: mohamed.boucadair@orange.com= ; Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

I also support to = mandate destination-network for immediately enforced filtering = rules.

[Jon] This can be = enforced / inserted by the DOTS Server for all the destination networks = of the domain that the DOTS client ‘belongs’ to.  That = said, it would be good to always have the destination network in an ACL = as it can be validated and cross-checked whenever the legitimate set of = domain protected IPs are updated.

[Jon] However, what = happens to the Destination network in the case of a call home DOTS = client that becomes a quasi DOTS server and the Destination networks are = somewhere out on the Internet?

 

[TR] DDOS is a targeted attack, so = the DOTS client can specify the destination network targeted by devices = in the DOTS server domain and the DOTS server can validate if the = destination network is indeed targeted by its = devices.

 

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of mohamed....boucadair@orange.= com
Sent: Tuesday, March 27, 2018 1:09 PM
To: = Jon Shallow <supjps-ietf@jpshallow.com&g= t;; dots@ietf.org
Subject: Re: = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

Hi Jon,

 

Thank you for the comments.

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] = De la part de Jon Shallow
Envoy=E9 : lundi 26 mars = 2018 14:23
=C0 : dots@ietf.org
Objet : = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

Hi = there,

 

As per Med’s presentation to the IETF = 101

 

Issue #4: Per-Domain or Per-client = Filters?

 

• Conclusion

– Filters that are activated only during = mitigation time are on a per-client basis

   • Filters are per-domain when are = immediately applied

 

“Filters are per-domain when are immediately = applied” is what I have an challenge with.

 

If we have a = compromised or rogue DOTS client, the simple use of something like curl, = along with the client certificates etc. can be used to generate any ACL = with activation-type :=3D ‘immediate’ which is then = immediately applied for all traffic within the domain as per the = above.

 

[Med] = Yes. FWIW, this attack is called out in the security considerations = section:

 

“Nevertheless, =
an

   attacker who can access a = DOTS client is technically capable of

   launching various attacks, = such as:

 

..;

 

   o  Set invalid ACL entries, which may =
prevent legitimate traffic from
      being forwarded.  =
Likewise, invalid ACL entries may lead =
to
      forward DDoS traffic.

“

[Jon] Agreed that the = attack is covered off in the Security section, but we should be limiting = the possibility / scope of the attack vector by enforcing some rules as = to what is / is not allowed.  Allowing a DOTS client to be able to = affect all the traffic within the domain is a huge risk to me and should = not be allowed.

 

So, a ACL = that blacklists the DNS server, or drops all port 443 traffic etc. can = easily cause all of the other clients / devices within the domain to be = taken off air.  Putting the intelligence into the DOTS server to = not allow this to happen could be a challenge.

[The signal channel is much harder to compromise and = affect traffic flows to other areas within the domain]

 

I believe = that an ACL instantiated by a DOTS client (immediate or when-mitigating) = should only apply to the DOTS client’s traffic which means that = the destination-network has to be a part of the ACL, whether implicitly = added by the DOTS server, or by the DOTS client and suitably = validated.

 

[Med] = Putting aside that I don’t parse “DOTS client’s = traffic”,

[Jon] I was referring to all the traffic flows = that a DOTS client can legitimately request control of to the DOTS = server that are within the scope of what the DOTS client is protecting = (which may or may not be the DOTS client’s IP = address).

I = interpret your answer as a support to this question raised for issue = #4:

    • “Should = we mandate destination-network to be present for immediately enforced = filters?”

[Jon] See response to = Tiru’s Agreement above.

~Jon

There is nothing to stop the DOTS server or DOTS = mitigator merging common ACLs to reduce the number of ACLs within the = mitigation device.

 

As a side = note “mitigation-time” is perhaps a bad name as it implies a = time period – something like “when-mitigating” to me = is clearer.

[Med] = Fixed in my local copy. Thank you.

 

Regards

 

Jon

<= /div> ------=_NextPart_000_024A_01D3CFFE.FF140020-- From nobody Mon Apr 9 04:42:07 2018 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 97842124BFA for ; Mon, 9 Apr 2018 04:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gh4Rmgnxir7T for ; Mon, 9 Apr 2018 04:42:04 -0700 (PDT) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D4591241F5 for ; Mon, 9 Apr 2018 04:42:04 -0700 (PDT) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 83D751C0835; Mon, 9 Apr 2018 13:42:02 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.13]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id 537DD180083; Mon, 9 Apr 2018 13:42:02 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6D.corporate.adroot.infra.ftgroup ([fe80::54f9:a6c3:c013:cbc7%19]) with mapi id 14.03.0382.000; Mon, 9 Apr 2018 13:42:02 +0200 From: To: "Konda, Tirumaleswar Reddy" , "Jon Shallow" , "dots@ietf.org" Thread-Topic: [Dots] Signal Channel - 300 Redirected Signaling Thread-Index: AQJ5xX4UsK17va5Vv37fpNudI6+9awAAo7xAAAH7T4AAARdqYAAhoxEAAAGQiwAAAKyNYAAF3e1QACUKCFAAAZEMQAAIeXTgAARcGhAAAoG7gAABGXwAAAAjBIAAAa5ZgAAAiReAAABpmzAAL32aAABWbPEwAAIv/gAAAPiKMAAA7T0AAACbH4AAAR48IAAD29GAAAAS23CipKrW4A== Date: Mon, 9 Apr 2018 11:42:01 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DEFA4A0@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <014f01d3cc19$2e3880e0$8aa982a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7E7B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <019901d3cc23$a93ff8e0$fbbfeaa0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8524@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <004e01d3ccb4$d505e7f0$7f11b7d0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8758@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEF912A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEF93EE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <008501d3cda6$c860d210$59227630$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF951 1@OPEXCLILMA3 . corporate.adroot.infra.ftgroup> <00b001d3cdab$ba8caec0$2fa60c40$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF975C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <00b801d3cdb4$982dc4a0$c8894de0$@jpshallow.com> <015101d3ce74$351393c0$9f3abb40$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEFA190@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <01f501d3cfde$4014ca30$c03e5e90$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEFA2DF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEFA44B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling 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, 09 Apr 2018 11:42:06 -0000 Re-, Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumales= war > Reddy > Envoy=E9=A0: lundi 9 avril 2018 13:29 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org > Objet=A0: Re: [Dots] Signal Channel - 300 Redirected Signaling >=20 > > -----Original Message----- > > From: mohamed.boucadair@orange.com > > [mailto:mohamed.boucadair@orange.com] > > Sent: Monday, April 9, 2018 4:49 PM > > To: Konda, Tirumaleswar Reddy ; > > Jon Shallow ; dots@ietf.org > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > Re-, > > > > Focusing on this part of your answer: > > > > "No, DNS TTL lifetime does not mean existing session has to be > disconnected > > after the TTL expires." > > > > This is exactly the disconnect. We are not discussing **DNS TTL** but t= he > > validity time of a an alternate server as provided in a DOTS redirect > signal. >=20 > When the server can explicitly re-direct the client, why provide the vali= dity > time of an alternate server ? [Med] Involving the alternate server is one deployment mode among others. T= he current text allows for these two modes: =20 (1) redirect upon an explicit signal (2) automatic fallback upon ttl expiry Which one to pick is deployment-specific.=20 TTL makes sense only for (2). >=20 > > > > If a finite validity time is provided, the client will use that alterna= te > server till that > > validly time expires. Passed that timer, the client will contact its > "normal" servers > > to place requests. That behavior is straightforward. > > > > If you insist to interpret TTL as DNS TTL, then RFC1035 says the follow= ing: > > > > " TTL a 32 bit signed integer that specifies the time inter= val > > that the resource record may be cached before the sourc= e > > of the information should again be consulted. " > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > In our case, the source of the information is the normal server :) >=20 > Yes, caching is done based on TTL to avoid DNS lookups but it does not me= an > the client has to disconnect existing > sessions after the TTL expires. >=20 [Med] It seems that I didn't made my point clear. I was explicitly referrin= g to "...the source of the information should again be consulted". Which means that, if we maintain the comparison with DNS, upon expiry of TT= L the source of the information (our case=3Dnormal DOTS server) should be c= onsulted. I suggest we get out from the DNS thing, but focus on the functionality we = want for TTL.=20 > -Tiru >=20 From nobody Mon Apr 9 04:45:12 2018 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 C8FC2124B17 for ; Mon, 9 Apr 2018 04:45:08 -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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 o-Et3xTsxgl9 for ; Mon, 9 Apr 2018 04:45:04 -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 707FB12426E for ; Mon, 9 Apr 2018 04:45:04 -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=1523274303; 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: dlp-product:dlp-version:dlp-reaction: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: authentication-results:x-microsoft-antispam-prvs: x-exchange-antispam-report-test:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: 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=n R0ozUgVa3z+V1ihMIyCFmTCRtFm+fUHO5hf7uafkC U=; b=NtggC24XLi4GFmcYTO4nOqrfAS6RvddAdVNrCYND5+Av dZYR6aJHSWNa4C72vwBCmwa3NWD+z0xXPllPll3kGKYT1sGBNE i5LpuxytWClSSuzRC3ESN531HmCCE3wujHhtK9ouGIAyUSJadJ 5FvbxmagQrcdUGb3vLRjy1m+Y4s= Received: from DNVEXAPP1N04.corpzone.internalzone.com (unknown [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 16d2_a739_a95a10db_c931_441e_978f_186e7d12a633; Mon, 09 Apr 2018 06:45:02 -0500 Received: from DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 9 Apr 2018 05:44:22 -0600 Received: from DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) by DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 9 Apr 2018 05:44:21 -0600 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Mon, 9 Apr 2018 05:44:21 -0600 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (10.44.176.240) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 9 Apr 2018 05:44:20 -0600 Received: from BN6PR16MB1425.namprd16.prod.outlook.com (10.172.207.19) by BN6PR16MB1634.namprd16.prod.outlook.com (10.172.27.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.653.12; Mon, 9 Apr 2018 11:44:19 +0000 Received: from BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d]) by BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d%2]) with mapi id 15.20.0653.015; Mon, 9 Apr 2018 11:44:19 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: [Dots] IETF 101 Presentation Data Channel Issue #4 Thread-Index: AdPE/QAkDtOD9YeqSAaov9+szxQnSQAoMdfAAAKPC+AAA+QiAAAEVj7wAfiJ0YAAA7+48AABBD0AAByNZ3AAbRM0AAABj4SQAALuHIAAAB7MkA== Date: Mon, 9 Apr 2018 11:44:19 +0000 Message-ID: References: <008401d3c4fd$216d0840$644718c0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF1067@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <014801d3c5b7$94c67f00$be537d00$@jpshallow.com> <009a01d3cdab$150b4c40$3f21e4c0$@jpshallow.com> <00cf01d3cdbe$24876650$6d9632f0$@jpshallow.com> <01fd01d3cfe4$a71b6580$f5523080$@jpshallow.com> <024901d3cff6$9d4beea0$d7e3cbe0$@jpshallow.com> In-Reply-To: <024901d3cff6$9d4beea0$d7e3cbe0$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR16MB1634; 7:NjbzOeCc8q6aQRoPcy73OwqK0aIMaKORcX1xdIEhGbCyIbz7imH05E73dCvrvQwuLUGw8NpB+iKpDdI48mK41c4hXm9ebNU117+2HyMOgU2K0LCbpSYDeBVLKeT/Kzo2avfDTKvDxC95u/WNqJN5/+Fii9q8/5RMK55alA1G6TrIqRSzs5HScamhpNeg7GHKeYzjcudEOZGtkuxPTFDU71xbvs4HH7irJyb9nvH73e/2TxttnpIef4i/Bmi9nn8l x-ms-exchange-antispam-srfa-diagnostics: SOS; X-MS-Office365-Filtering-Correlation-Id: fed6d080-5a6e-49a9-77e7-08d59e0f3afe x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BN6PR16MB1634; x-ms-traffictypediagnostic: BN6PR16MB1634: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(192374486261705)(18271650672692)(21748063052155)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231221)(944501327)(52105095)(10201501046)(3002001)(93006095)(93001095)(6041310)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(6072148)(201708071742011); SRVR:BN6PR16MB1634; BCL:0; PCL:0; RULEID:; SRVR:BN6PR16MB1634; x-forefront-prvs: 0637FCE711 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39380400002)(346002)(396003)(366004)(376002)(39860400002)(32952001)(5383002)(189003)(199004)(14454004)(19609705001)(316002)(6506007)(66066001)(72206003)(59450400001)(478600001)(53546011)(33656002)(25786009)(110136005)(81166006)(97736004)(76176011)(8676002)(81156014)(8936002)(345774005)(80792005)(68736007)(9326002)(3660700001)(2906002)(7696005)(2501003)(74316002)(53946003)(236005)(229853002)(6306002)(54896002)(9686003)(6436002)(106356001)(186003)(3846002)(6116002)(790700001)(5660300001)(26005)(2900100001)(5250100002)(102836004)(55016002)(3280700002)(93886005)(105586002)(86362001)(486006)(99286004)(7736002)(476003)(11346002)(446003)(53936002)(6246003)(2201001)(91024005)(85282002)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR16MB1634; H:BN6PR16MB1425.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 1F3/sgkU++lj0Bng1K7dV6m9f60dc7mgEHCwM15K7AYhYQfZcqboi94rYi6rQJfvOzqi8NlcyRGuQ5yfdZzuoGRqf5u9ILflDmpf1sIOZPy7SsTZnpw50TD+l9HpRn4+C+cPrqV8Yd64oeK69LmzyhUdcUpJm9DwON33hqtljhFfKuHZNV4oEjJa7Y5EZKjqiMfAnAtILlFIfcIcytZeoBgPfhoQGNpge8hFwYHKQddagBD+86dGbpHwlY2SQGHOMYyp4BTbFks0R5MgeWDU8v05xIUhqLbeQTYf5OS8T/PtEp6sET7J5Whs09ZJzCi0ajdfK/0gK1dQvAm/I3yuYMhl44/IilqpDCeafTdXqk9LgQ+uiBVpCrGeKrbMOl4UBhoKyEuKo6v+sZs30Mi3yMjiuDM7bXZ5/nKG2TrJA4M= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR16MB14251FF465F52593D5FD817CEABF0BN6PR16MB1425namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: fed6d080-5a6e-49a9-77e7-08d59e0f3afe X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2018 11:44:19.3105 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR16MB1634 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 <6260> : inlines <6554> : streams <1783535> : uri <2622487> Archived-At: Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 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, 09 Apr 2018 11:45:09 -0000 --_000_BN6PR16MB14251FF465F52593D5FD817CEABF0BN6PR16MB1425namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jon, Please see inline [TR2] From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Monday, April 9, 2018 5:04 PM To: Konda, Tirumaleswar Reddy ; mohamed= .boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 Hi Tiru, See inline [Jon1] Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 09 April 2018 11:32 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 Hi Jon, Please see inline From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Monday, April 9, 2018 2:55 PM To: Konda, Tirumaleswar Reddy >; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 Hi Tiru, If a DOTS client knows the full scope of the Networks that it is allowed to= use in a ACL or mitigate request, and the DOTS server limits any update fr= om that client to the scope of Networks (with any unexpected side effects t= hat may have), then there is no difference in my mind as to whether the DOT= S clients fills in the destination-network, or the DOTS server does so on t= he DOTS client's behalf before ACL instantiation if destination-network is = not defined. [TR] The above model only works when the DOTS server and DOTS client are di= rectly communicating with each other (In the above, the DOTS server knows t= he DOTS client identity to enforce the scope but will not the DOTS client i= dentity in the presence of a client-domain DOTS gateway). [Jon1] The last para of "10. Security Considerations" states DOTS servers MUST verify that requesting DOTS clients are entitled to trigger actions on a given IP prefix. That is, only actions on IP resources that belong to the DOTS client' domain MUST be authorized by a DOTS server. The exact mechanism for the DOTS servers to validate that the target prefixes are within the scope of the DOTS client's domain is deployment-specific. [Jon1] So it makes no difference if the DOTS client happens to be an agent = part of a client-domain DOTS gateway. If the client-domain DOTS gateway is= hiding all the 'behind' clients and presenting as single client, there is = no issue. However, if the 'behind' clients are presented as 2 or more 'cui= d's by the DOTS gateway, then either the scope is per 'cuid', or if 'cdid's= are being applied by the upstream server domain DOTS gateway then on a per= 'cdid' basis if wanted. For a client behind a client domain DOTS gateway, there may be non public I= P addresses that the (DMS) client is responsible for, but these should neve= r be sent out through the DOTS gateway (and should be rejected by the DOTS = server as out of scope). There does have to be a common agreement between = DOTS client & DOTS server as to what Networks are in scope, but the DOTS cl= ient currently cannot request this from the DOTS server and has to be agree= d out of band. [TR] I don't see a new problem, even when a DOTS client sends a mitigation = request it needs to know if the targets conveyed in the mitigation request = are in its scope or not. [Jon1] but again, the DOTS server MUST verify the IP prefix is valid, so ha= s to know scope. I agree that the DOTS client (or client domain DOTS gatew= ay) needs to know (today out of band) what is the scope of what is valid to= request. The challenge comes when the DOTS server's scope is reconfigured= , but not yet updated on the DOTS client. [TR2] The scope would be first updated on the DOTS client domain and then o= n the DOTS server (e.g. IP prefix re-numbering). There is no reason as to why the DOTS server cannot maintain a valid scope = of Networks that the client domain DOTS gateway is allowed to request for v= alidity checking - unless I am missing something? [TR] You are partially right, the DOTS server does not know the valid scope= of prefixes that a DOTS client behind client-domain DOTS gateway is allowe= d to request. [Jon1] Again, the last para of 10. stands here, and so the scope has to be = known by the DOTS server. [TR] Yes, but it may not know the scope of a DOTS client behind a client-do= main DOTS gateway. Troubleshooting has kept me in a job for more years than I care to remember= , anything to aid troubleshooting is what I am interested in and so totally= agree that rogue DOTS client's capabilities need to be kept under control = with suitable logging to aid diagnosis is a major plus. However in this ca= se, the implicit rule is no different to the DOTS client requesting the ful= l Networks scope in an ACL request. [TR] If the client is not authorized to request the full network scope, it = can detected by the client-domain DOTS gateway and rejects the filtering ru= le by comparing the destination-networks specified in the ACE. [Jon1] Agreed, it is the responsibility of the client domain DOTS gateway t= o only allow out valid networks that are valid within the DOTS server's sco= pe. [Jon1] Should we support a way for the client domain DOTS gateway (i.e. DO= TS client agent) to programmatically get the current valid network scope fr= om the DOTS server? [TR2] It will not solve the above problem of detecting and rejecting a roug= e (or misconfigured) DOTS client behind client domain DOTS gateway sending = ACL without specifying destination-network. -Tiru ~jon1 -Tiru Regards Jon From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Konda@mcafee.com= ] Sent: 07 April 2018 06:48 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 Hi Jon, DOTS clients (intelligent DDoS mitigation system, application server) will = know the destination networks, what kind of DOTS clients will not know the = destination networks they are allowed to use ? DOTS clients could be behind client-domain DOTS gateway, DOTS server will h= ave no way to validate the DOTS client identity sending the ACE request to = determine the destination IP addresses in its scope, it will only know the = destination IP addresses in the DOTS client domain scope. Further, the implicit rule can be misused by compromised DOTS clients (e.g.= black-list good traffic to the entire DOTS client domain) and it's a trou= bleshooting nightmare to find the culprit device adversely impacting the en= tire network. Cheers, -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Friday, April 6, 2018 9:14 PM To: Konda, Tirumaleswar Reddy >; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 Hi Tiru, The DOTS server is likely to have a scope of IP addresses that are valid fo= r the client to ask for protection for based on the cuid or cdid. The DOTS client may have some knowledge of the scope IPs by some out of ban= d method, but programmatically cannot ask the server what they are. If a client specifies a destination network that is out of the valid scope = of IP addresses, then the ACE request will get rejected. The client may th= en have a challenge to work out what destination networks it is allowed to = use. How does a client set up a blacklist for all the IPS within his allowed sco= pe if it does not know what the scope is? If the client has not provided a destination network, then the DOTS server = can auto-fill in the missing information at the time of the ACE instantiati= on - and this then handles if the scope of IP addresses change. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 06 April 2018 16:19 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 I don't understand how the DOTS server/mitigation will fill it in at time o= f ACE instantiation, and why can't the DOTS client fill the destination net= work details ? -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Friday, April 6, 2018 6:58 PM To: Konda, Tirumaleswar Reddy >; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 Hi there, There is no current way to request of a DOTS Server as to what is the set o= f IP networks that a DOTS client can use either within a mitigation request= or to set up an ACL other than by "testing for ok or not ok" with lots of = different IP addresses. There is a reasonable likelihood of the scope of valid IPs from the Server'= s perspective will change over time. So, unless a DOTS client wants to con= trol a specific destination network, then my suggestion would be to leave t= he ACE destination network empty and for the DOTS Server / DOTS mitigator (= how is out of scope) to fill it in at time of ACE instantiation. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 27 March 2018 13:49 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 Please see inline [TR] From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Tuesday, March 27, 2018 4:07 PM To: Konda, Tirumaleswar Reddy >; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 Hi Tiru / Med See inline [Jon] Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 27 March 2018 09:47 To: mohamed.boucadair@orange.com; Jon = Shallow; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 I also support to mandate destination-network for immediately enforced filt= ering rules. [Jon] This can be enforced / inserted by the DOTS Server for all the destin= ation networks of the domain that the DOTS client 'belongs' to. That said,= it would be good to always have the destination network in an ACL as it ca= n be validated and cross-checked whenever the legitimate set of domain prot= ected IPs are updated. [Jon] However, what happens to the Destination network in the case of a cal= l home DOTS client that becomes a quasi DOTS server and the Destination net= works are somewhere out on the Internet? [TR] DDOS is a targeted attack, so the DOTS client can specify the destinat= ion network targeted by devices in the DOTS server domain and the DOTS serv= er can validate if the destination network is indeed targeted by its device= s. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed....boucadair= @orange.com Sent: Tuesday, March 27, 2018 1:09 PM To: Jon Shallow >; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 Hi Jon, Thank you for the comments. Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : lundi 26 mars 2018 14:23 =C0 : dots@ietf.org Objet : [Dots] IETF 101 Presentation Data Channel Issue #4 Hi there, As per Med's presentation to the IETF 101 Issue #4: Per-Domain or Per-client Filters? * Conclusion - Filters that are activated only during mitigation time are on a per-clien= t basis * Filters are per-domain when are immediately applied "Filters are per-domain when are immediately applied" is what I have an cha= llenge with. If we have a compromised or rogue DOTS client, the simple use of something = like curl, along with the client certificates etc. can be used to generate = any ACL with activation-type :=3D 'immediate' which is then immediately app= lied for all traffic within the domain as per the above. [Med] Yes. FWIW, this attack is called out in the security considerations s= ection: "Nevertheless, an attacker who can access a DOTS client is technically capable of launching various attacks, such as: ..; o Set invalid ACL entries, which may prevent legitimate traffic from being forwarded. Likewise, invalid ACL entries may lead to forward DDoS traffic. " [Jon] Agreed that the attack is covered off in the Security section, but we= should be limiting the possibility / scope of the attack vector by enforci= ng some rules as to what is / is not allowed. Allowing a DOTS client to be= able to affect all the traffic within the domain is a huge risk to me and = should not be allowed. So, a ACL that blacklists the DNS server, or drops all port 443 traffic etc= . can easily cause all of the other clients / devices within the domain to = be taken off air. Putting the intelligence into the DOTS server to not all= ow this to happen could be a challenge. [The signal channel is much harder to compromise and affect traffic flows t= o other areas within the domain] I believe that an ACL instantiated by a DOTS client (immediate or when-miti= gating) should only apply to the DOTS client's traffic which means that the= destination-network has to be a part of the ACL, whether implicitly added = by the DOTS server, or by the DOTS client and suitably validated. [Med] Putting aside that I don't parse "DOTS client's traffic", [Jon] I was referring to all the traffic flows that a DOTS client can legit= imately request control of to the DOTS server that are within the scope of = what the DOTS client is protecting (which may or may not be the DOTS client= 's IP address). I interpret your answer as a support to this question raised for issue #4: * "Should we mandate destination-network to be present for immediate= ly enforced filters?" [Jon] See response to Tiru's Agreement above. ~Jon There is nothing to stop the DOTS server or DOTS mitigator merging common A= CLs to reduce the number of ACLs within the mitigation device. As a side note "mitigation-time" is perhaps a bad name as it implies a time= period - something like "when-mitigating" to me is clearer. [Med] Fixed in my local copy. Thank you. Regards Jon --_000_BN6PR16MB14251FF465F52593D5FD817CEABF0BN6PR16MB1425namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jon,

&nbs= p;

Please se= e inline [TR2]

 

From:<= /span> Jon Shallow [mailto:s= upjps-ietf@jpshallow.com]
Sent: Monday, April 9, 2018 5:04 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; mohamed.boucadair@orange.com; dots@ietf.org
Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Hi Tiru= ,

&n= bsp;

See inl= ine [Jon1]

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 09 April 2018 11:32
To: Jon Shallow; moh= amed.boucadair@orange.com; dots@ietf.org
Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Hi Jon,

&nbs= p;

Please se= e inline

&nbs= p;

From:<= /span> Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Monday, April 9, 2018 2:55 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; mohamed.boucadair@orange.co= m; dots@ietf.org
Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Hi Tiru= ,

&n= bsp;

If a DO= TS client knows the full scope of the Networks that it is allowed to use in= a ACL or mitigate request, and the DOTS server limits any update from that= client to the scope of Networks (with any unexpected side effects that may have), then there is no difference in= my mind as to whether the DOTS clients fills in the destination-network, o= r the DOTS server does so on the DOTS client’s behalf before ACL inst= antiation if destination-network is not defined.

 

[TR] The above model only works= when the DOTS server and DOTS client are directly communicating with each = other (In the above, the DOTS server knows the DOTS client identity to enfo= rce the scope but will not the DOTS client identity in the presence of a client-domain DOTS gateway).

&n= bsp;

[Jon1] = The last para of “10. Security Considerations” states

   DOTS servers MUST verify that requesting= DOTS clients are entitled to

   trigger actions on a given IP prefix.&nb= sp; That is, only actions on IP

   resources that belong to the DOTS client= ' domain MUST be authorized

   by a DOTS server.  The exact mechan= ism for the DOTS servers to

   validate that the target prefixes are wi= thin the scope of the DOTS

 &= nbsp; client's domain is deployment-specific.

 

[Jon1] = So it makes no difference if the DOTS client happens to be an agent part of= a client-domain DOTS gateway.  If the client-domain DOTS gateway is h= iding all the ‘behind’ clients and presenting as single client, there is no issue.  However, if the ‘behind&#= 8217; clients are presented as 2 or more ‘cuid’s by the DOTS ga= teway, then either the scope is per ‘cuid’, or if ‘cdid&#= 8217;s are being applied by the upstream server domain DOTS gateway then on= a per ‘cdid’ basis if wanted.

&n= bsp;

For a c= lient behind a client domain DOTS gateway, there may be non public IP addre= sses that the (DMS) client is responsible for, but these should never be se= nt out through the DOTS gateway (and should be rejected by the DOTS server as out of scope).  There does have to = be a common agreement between DOTS client & DOTS server as to what Netw= orks are in scope, but the DOTS client currently cannot request this from t= he DOTS server and has to be agreed out of band.

 

[TR] I don’t see a new pr= oblem, even when a DOTS client sends a mitigation request it needs to know = if the targets conveyed in the mitigation request are in its scope or not.<= o:p>

&n= bsp;

[Jon1] = but again, the DOTS server MUST verify the IP prefix is valid, so has to kn= ow scope.  I agree that the DOTS client (or client domain DOTS gateway= ) needs to know (today out of band) what is the scope of what is valid to request.  The challenge comes when the = DOTS server’s scope is reconfigured, but not yet updated on the DOTS = client. 

 

[TR2] The scope would be first = updated on the DOTS client domain and then on the DOTS server (e.g. IP pref= ix re-numbering).

 

There i= s no reason as to why the DOTS server cannot maintain a valid scope of Netw= orks that the client domain DOTS gateway is allowed to request for validity= checking – unless I am missing something?

 

[TR] You are partially right, t= he DOTS server does not know the valid scope of prefixes that a DOTS client= behind client-domain DOTS gateway is allowed to request.=

&n= bsp;

[Jon1] = Again, the last para of 10. stands here, and so the scope has to be known b= y the DOTS server.

 

[TR] Yes, but it may not know t= he scope of a DOTS client behind a client-domain DOTS gateway.

&n= bsp;

Trouble= shooting has kept me in a job for more years than I care to remember, anyth= ing to aid troubleshooting is what I am interested in and so totally agree = that rogue DOTS client’s capabilities need to be kept under control with suitable logging to aid diagnosis is a = major plus.  However in this case, the implicit rule is no different t= o the DOTS client requesting the full Networks scope in an ACL request.

 

[TR] If the client is not autho= rized to request the full network scope, it can detected by the client-doma= in DOTS gateway and rejects the filtering rule by comparing the destination= -networks

     &= nbsp;  specified in the ACE.

[Jon1] = Agreed, it is the responsibility of the client domain DOTS gateway to only = allow out valid networks that are valid within the DOTS server’s scop= e.

&n= bsp;

[Jon1] = Should we support a way for the client domain DOTS gateway  (i.e. DOTS= client agent) to programmatically get the current valid network scope from= the DOTS server?

 

[TR2] It will not solve the abo= ve problem of detecting and rejecting a rouge (or misconfigured) DOTS clien= t behind client domain DOTS gateway sending ACL without specifying destinat= ion-network.

 

-Tiru

 

~jon1

 

-Tiru

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Kon= da@mcafee.com]
Sent: 07 April 2018 06:48
To: Jon Shallow; moh= amed.boucadair@orange.com; dots@ietf.org
Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Hi Jon,

&nbs= p;

DOTS clie= nts (intelligent DDoS mitigation system, application server) will know the = destination networks, what kind of DOTS clients will not know the destinati= on networks they are allowed to use ?

DOTS clie= nts could be behind client-domain DOTS gateway, DOTS server will have no wa= y to validate the DOTS client identity sending the ACE request to determine= the destination IP addresses in its scope, it will only know the destination IP addresses in the DOTS client d= omain scope.

Further, = the implicit rule can be misused by compromised DOTS clients (e.g. black-li= st good traffic to the entire DOTS client domain) and it’s a  tr= oubleshooting nightmare to find the culprit device adversely impacting the entire network.

&nbs= p;

Cheers,

-Tiru

&nbs= p;

From:<= /span> Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Friday, April 6, 2018 9:14 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; mohamed.boucadair@orange.co= m; dots@ietf.org
Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Hi Tiru= ,

&n= bsp;

The DOT= S server is likely to have a scope of IP addresses that are valid for the c= lient to ask for protection for based on the cuid or cdid.

&n= bsp;

The DOT= S client may have some knowledge of the scope IPs by some out of band metho= d, but programmatically cannot ask the server what they are.

&n= bsp;

If a cl= ient specifies a destination network that is out of the valid scope of IP a= ddresses, then the ACE request will get rejected.  The client may then= have a challenge to work out what destination networks it is allowed to use.

&n= bsp;

How doe= s a client set up a blacklist for all the IPS within his allowed scope if i= t does not know what the scope is?

&n= bsp;

If the = client has not provided a destination network, then the DOTS server can aut= o-fill in the missing information at the time of the ACE instantiation R= 11; and this then handles if the scope of IP addresses change.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 06 April 2018 16:19
To: Jon Shallow; moh= amed.boucadair@orange.com; dots@ietf.org
Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

I donR= 17;t understand how the DOTS server/mitigation will fill it in at time of A= CE instantiation, and why can’t the DOTS client fill the destination = network details ?

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Friday, April 6, 2018 6:58 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; mohamed.boucadair@orange.co= m; dots@ietf.org
Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Hi ther= e,

&n= bsp;

There i= s no current way to request of a DOTS Server as to what is the set of IP ne= tworks that a DOTS client can use either within a mitigation request or to = set up an ACL other than by “testing for ok or not ok” with lots of different IP addresses.=

&n= bsp;

There i= s a reasonable likelihood of the scope of valid IPs from the Server’s= perspective will change over time.  So, unless a DOTS client wants to= control a specific destination network, then my suggestion would be to leave the ACE destination network empty and for the= DOTS Server / DOTS mitigator (how is out of scope) to fill it in at time o= f ACE instantiation.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 27 March 2018 13:49
To: Jon Shallow; moh= amed.boucadair@orange.com; dots@ietf.org
Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Please se= e inline [TR]

&nbs= p;

From:<= /span> Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Tuesday, March 27, 2018 4:07 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; mohamed.boucadair@orange.co= m; dots@ietf.org
Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Hi Tiru= / Med

&n= bsp;

See inl= ine [Jon]

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 27 March 2018 09:47
To: mohamed.boucadai= r@orange.com; Jon Shallow; dots@ietf.org
Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

I also su= pport to mandate destination-network for immediately enforced filtering rul= es.

[Jon] This can be enforced / inserted by the DOTS Server for all the d= estination networks of the domain that the DOTS client ‘belongs’= ; to.  That said, it would be good to always have the destination network in an ACL as it can be validated and cross-checked= whenever the legitimate set of domain protected IPs are updated.

[Jon] However, what happens to the Destination network in the case of = a call home DOTS client that becomes a quasi DOTS server and the Destinatio= n networks are somewhere out on the Internet?

&nbs= p;

[TR] DDOS= is a targeted attack, so the DOTS client can specify the destination netwo= rk targeted by devices in the DOTS server domain and the DOTS server can va= lidate if the destination network is indeed targeted by its devices.

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed= ....boucadair@orange.com
Sent: Tuesday, March 27, 2018 1:09 PM
To: Jon Shallow <sup= jps-ietf@jpshallow.com>; dots@ietf.org
Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Hi Jon,

 

Thank you for the comments.<= /p>

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow
Envoy=E9 : lundi 26 mars 2018 14:23
=C0 : dots@ietf.org
Objet : [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Hi there,

 

As per Med’s presentation= to the IETF 101

 

Issue #4: Per-Domain or Per-cli= ent Filters?

 

• Conclusion

– Filters that are activa= ted only during mitigation time are on a per-client basis=

   • Filters ar= e per-domain when are immediately applied

 

“Filters are per-domain w= hen are immediately applied” is what I have an challenge with.

 

If we have a compromised or rog= ue DOTS client, the simple use of something like curl, along with the clien= t certificates etc. can be used to generate any ACL with activation-type := =3D ‘immediate’ which is then immediately applied for all traffic within the domain as per the above.

 

[Med] Yes. FWIW, this attack is= called out in the security considerations section:

 

“Nevertheless,=
 an

   attacker who can acce= ss a DOTS client is technically capable of

   launching various att= acks, such as:

 

..;

 

   o  Set invalid ACL entries, which may prevent legiti=
mate traffic from
      being forwarded.  Likewise, invali=
d ACL entries may lead to
      forward DDoS traffic.=

“

[Jon] A= greed that the attack is covered off in the Security section, but we should= be limiting the possibility / scope of the attack vector by enforcing some= rules as to what is / is not allowed.  Allowing a DOTS client to be able to affect all the traffic within the dom= ain is a huge risk to me and should not be allowed.

 

So, a ACL that blacklists the D= NS server, or drops all port 443 traffic etc. can easily cause all of the o= ther clients / devices within the domain to be taken off air.  Putting= the intelligence into the DOTS server to not allow this to happen could be a challenge.

[The signal channel is much har= der to compromise and affect traffic flows to other areas within the domain= ]

 

I believe that an ACL instantia= ted by a DOTS client (immediate or when-mitigating) should only apply to th= e DOTS client’s traffic which means that the destination-network has = to be a part of the ACL, whether implicitly added by the DOTS server, or by the DOTS client and suitably validated.

 

[Med] Putting aside that I don&= #8217;t parse “DOTS client’s traffic”,

[Jon] I= was referring to all the traffic flows that a DOTS client can legitimately= request control of to the DOTS server that are within the scope of what th= e DOTS client is protecting (which may or may not be the DOTS client’s IP address).

I interpret your answer as a su= pport to this question raised for issue #4:

    • “Should we mandate destination-network to be present for immediately enforced filters?”

[Jon] S= ee response to Tiru’s Agreement above.

~Jon

There is nothing to stop the DO= TS server or DOTS mitigator merging common ACLs to reduce the number of ACL= s within the mitigation device.

 

As a side note “mitigatio= n-time” is perhaps a bad name as it implies a time period – som= ething like “when-mitigating” to me is clearer.

[Med] Fixed in my local copy. T= hank you.

 

Regards

 

Jon

--_000_BN6PR16MB14251FF465F52593D5FD817CEABF0BN6PR16MB1425namp_-- From nobody Mon Apr 9 04:49:26 2018 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 56838124BFA for ; Mon, 9 Apr 2018 04:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 cwtGDJghknkb for ; Mon, 9 Apr 2018 04:49:23 -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 5E2D51241F5 for ; Mon, 9 Apr 2018 04:49: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=1523274551; 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: dlp-product:dlp-version:dlp-reaction: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-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-Network-Message-Id: 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=+ efAXZ7WWNyuLZV+eqkgK9AQOUEptOw4m9YDOVBSbh 0=; b=pdwbRBeVPpP/iwu5E3jVLNxRp4eezeZGBJ1RUysaP1eI voTkJOnKToXWCe3kCLBAt5zbqhz51EsJ8X+vGcs1KfKUVLFDu9 OqOEsaruIwGsWyjRfj+2CTu3YS/aOUcjvcEsnZ6S6bru96v0aq iu/krzR+IYpbWf35T3pd0AWqLHM= Received: from DNVEXAPP1N04.corpzone.internalzone.com (unknown [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 16ce_66a1_797569b9_1b8c_4752_8f3d_2ec0bf2d747d; Mon, 09 Apr 2018 06:49:11 -0500 Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 9 Apr 2018 05:48:23 -0600 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Mon, 9 Apr 2018 05:48:23 -0600 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (10.44.176.241) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 9 Apr 2018 05:48:22 -0600 Received: from BN6PR16MB1425.namprd16.prod.outlook.com (10.172.207.19) by BN6PR16MB1780.namprd16.prod.outlook.com (10.172.28.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.653.12; Mon, 9 Apr 2018 11:48:22 +0000 Received: from BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d]) by BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d%2]) with mapi id 15.20.0653.015; Mon, 9 Apr 2018 11:48:22 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Signal Channel - 300 Redirected Signaling Thread-Index: AdPMGSyCaQQbv+vLSW+0gkDbU7HOEwAAo7xAAAH7T4AAARdqYAAhoxEAAAGQiwAAAKyNYAAF3e1QACUKCFAAAZEMQAAIeXTgAARcGhAAAoG7gAABGXwAAAAjBIAAAa5ZgAAAiReAAABpmzAAL32aAABWbPEwAAIv/gAAAPiKMAAA7T0AAACbH4AAAR48IAAD29GAAAAS23AAALmWgAAAGvzw Date: Mon, 9 Apr 2018 11:48:22 +0000 Message-ID: References: <014f01d3cc19$2e3880e0$8aa982a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7E7B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <019901d3cc23$a93ff8e0$fbbfeaa0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8524@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <004e01d3ccb4$d505e7f0$7f11b7d0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF8758@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEF912A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEF93EE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <008501d3cda6$c860d210$59227630$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF951 1@OPEXCLILMA3 . corporate.adroot.infra.ftgroup> <00b001d3cdab$ba8caec0$2fa60c40$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF975C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <00b801d3cdb4$982dc4a0$c8894de0$@jpshallow.com> <015101d3ce74$351393c0$9f3abb40$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEFA190@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <01f501d3cfde$4014ca30$c03e5e90$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEFA2DF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEFA44B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEFA4A0@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DEFA4A0@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR16MB1780; 7:ZqMqJWARUensBfCpQzD/Z8Q9Cs6i8NCZebsdD1/EJUEdwFa2n3lum9zSPgROlT47OZvE3ToTUlXrSKv1FvthqkPdX6nSz4UFp0Rr51XEVV7meW6iPmWcHlerkTUFomaa0nsKU5NSCpOik2/q4+ey6wpqN2kdeGIuoOssk/J5jq5I73vttKGpUmOJTkzKVRdFrxRrHKl3TzqbI/N1QXltU0vYLlYbiTho5bGOaMTk7zOG2dBI68Judi9WSeCxzEs9 x-ms-exchange-antispam-srfa-diagnostics: SOS; X-MS-Office365-Filtering-Correlation-Id: fa2c70f0-5888-475f-6729-08d59e0fcbb3 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BN6PR16MB1780; x-ms-traffictypediagnostic: BN6PR16MB1780: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(18271650672692)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231221)(944501327)(52105095)(3002001)(10201501046)(93006095)(93001095)(6041310)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(6072148)(201708071742011); SRVR:BN6PR16MB1780; BCL:0; PCL:0; RULEID:; SRVR:BN6PR16MB1780; x-forefront-prvs: 0637FCE711 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(376002)(39860400002)(396003)(39380400002)(13464003)(55784002)(32952001)(189003)(199004)(7696005)(316002)(6306002)(9686003)(53546011)(76176011)(53936002)(6246003)(55016002)(59450400001)(6116002)(3846002)(2906002)(2900100001)(110136005)(6436002)(66066001)(3280700002)(33656002)(97736004)(5250100002)(68736007)(478600001)(106356001)(81156014)(81166006)(8936002)(8676002)(11346002)(80792005)(99286004)(486006)(93886005)(476003)(229853002)(2501003)(305945005)(7736002)(446003)(74316002)(26005)(186003)(5660300001)(102836004)(6506007)(14454004)(86362001)(966005)(3660700001)(105586002)(25786009)(72206003)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR16MB1780; H:BN6PR16MB1425.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: ZUw5bNYUTqpVK+UNdObCYh4hAWMY5MPi/syJm2muuotWKUsxIX/xP24K538/VwJ06KWXxT62gNpSb2B3OYjAIW4Hwn6m84E1riQvGmtCips0f3fSMVTRR/e7cKyvwjeY0RfefkbA9MsRQnlk3+UoLsfGaw5k4SYutpyF1NHm3NLs/eZb5ZrypLcrBBrAAFbIoD0IfPoH8hRLy3aiQxRzYUvoP/oZtNOLj6bvusfVfDYnUtdOK6aqmCvQkN8suF/CR0z2i7PCOQM3YPOza81o/3G3eJq0BYy9Akq7VVbH6ZKkey4nrqZmwR+o0SwHM+i4HcJ8iLsWTrrS7y7gvrwSXfPxif73k0r5kYl+bxgAGuLVhihLDwhSqzS3DotdS7Vr7QUYaod9+BEEL1x9VR1JmV0fZn05+2BIa7zPofxLNGQ= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: fa2c70f0-5888-475f-6729-08d59e0fcbb3 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2018 11:48:22.1222 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR16MB1780 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 <6260> : inlines <6554> : streams <1783535> : uri <2622489> Archived-At: Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling 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, 09 Apr 2018 11:49:25 -0000 > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of > mohamed.boucadair@orange.com > Sent: Monday, April 9, 2018 5:12 PM > To: Konda, Tirumaleswar Reddy ; > Jon Shallow ; dots@ietf.org > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling >=20 > Re-, >=20 > Please see inline. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Konda, > > Tirumaleswar Reddy Envoy=E9=A0: lundi 9 avril 2018 13:29 =C0=A0: BOUCAD= AIR > > Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet=A0: Re: [Dots] Signal > > Channel - 300 Redirected Signaling > > > > > -----Original Message----- > > > From: mohamed.boucadair@orange.com > > > [mailto:mohamed.boucadair@orange.com] > > > Sent: Monday, April 9, 2018 4:49 PM > > > To: Konda, Tirumaleswar Reddy ; > > > Jon Shallow ; dots@ietf.org > > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > Re-, > > > > > > Focusing on this part of your answer: > > > > > > "No, DNS TTL lifetime does not mean existing session has to be > > disconnected > > > after the TTL expires." > > > > > > This is exactly the disconnect. We are not discussing **DNS TTL** > > > but the validity time of a an alternate server as provided in a DOTS > > > redirect > > signal. > > > > When the server can explicitly re-direct the client, why provide the > > validity time of an alternate server ? >=20 > [Med] Involving the alternate server is one deployment mode among others. > The current text allows for these two modes: >=20 > (1) redirect upon an explicit signal > (2) automatic fallback upon ttl expiry >=20 > Which one to pick is deployment-specific. >=20 > TTL makes sense only for (2). I don't think (2) is required, HTTP does not support (2) for Temporary re-d= irect (see https://tools.ietf.org/html/rfc7285#section-8.5.3). >=20 > > > > > > > > If a finite validity time is provided, the client will use that > > > alternate > > server till that > > > validly time expires. Passed that timer, the client will contact its > > "normal" servers > > > to place requests. That behavior is straightforward. > > > > > > If you insist to interpret TTL as DNS TTL, then RFC1035 says the foll= owing: > > > > > > " TTL a 32 bit signed integer that specifies the time int= erval > > > that the resource record may be cached before the sou= rce > > > of the information should again be consulted. " > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > > > In our case, the source of the information is the normal server :) > > > > Yes, caching is done based on TTL to avoid DNS lookups but it does not > > mean the client has to disconnect existing sessions after the TTL > > expires. > > >=20 > [Med] It seems that I didn't made my point clear. I was explicitly referr= ing to > "...the source of the information should again be consulted". > Which means that, if we maintain the comparison with DNS, upon expiry of = TTL > the source of the information (our case=3Dnormal DOTS server) should be > consulted. No, client contacts the source of the information only when a new TCP/UDP s= ession needs to be established. >=20 > I suggest we get out from the DNS thing, but focus on the functionality w= e want > for TTL. Works for me. -Tiru >=20 > > -Tiru > > >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Mon Apr 9 05:27:54 2018 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 7726E127871 for ; Mon, 9 Apr 2018 05:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wq4SJdk9gF0Y for ; Mon, 9 Apr 2018 05:27:51 -0700 (PDT) Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2C9F127010 for ; Mon, 9 Apr 2018 05:27:50 -0700 (PDT) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id C9431208F2; Mon, 9 Apr 2018 14:19:48 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.17]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id AC5CF40080; Mon, 9 Apr 2018 14:19:48 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM24.corporate.adroot.infra.ftgroup ([fe80::a1e6:3e6a:1f68:5f7e%18]) with mapi id 14.03.0382.000; Mon, 9 Apr 2018 14:19:48 +0200 From: To: "Konda, Tirumaleswar Reddy" , "Jon Shallow" , "dots@ietf.org" Thread-Topic: [Dots] Signal Channel - 300 Redirected Signaling Thread-Index: AdPMGSyCsK17va5Vv37fpNudI6+9awAAo7xAAAH7T4AAARdqYAAhoxEAAAGQiwAAAKyNYAAF3e1QACUKCFAAAZEMQAAIeXTgAARcGhAAAoG7gAABGXwAAAAjBIAAAa5ZgAAAiReAAABpmzAAL32aAABWbPEwAAIv/gAAAPiKMAAA7T0AAACbH4AAAR48IAAD29GAAAAS23AAALmWgAAAGvzwAABn2FA= Date: Mon, 9 Apr 2018 12:19:48 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DEFA561@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93302DEFA4A0@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling 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, 09 Apr 2018 12:27:52 -0000 Re-, Glad to see that we both agree to get out from the DNS comparison.=20 Please see inline. Cheers, Med > -----Message d'origine----- > De=A0: Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.c= om] > Envoy=E9=A0: lundi 9 avril 2018 13:48 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org > Objet=A0: RE: [Dots] Signal Channel - 300 Redirected Signaling >=20 > > -----Original Message----- > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of > > mohamed.boucadair@orange.com > > Sent: Monday, April 9, 2018 5:12 PM > > To: Konda, Tirumaleswar Reddy ; > > Jon Shallow ; dots@ietf.org > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > Re-, > > > > Please see inline. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Konda, > > > Tirumaleswar Reddy Envoy=E9=A0: lundi 9 avril 2018 13:29 =C0=A0: BOUC= ADAIR > > > Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet=A0: Re: [Dots] Sign= al > > > Channel - 300 Redirected Signaling > > > > > > > -----Original Message----- > > > > From: mohamed.boucadair@orange.com > > > > [mailto:mohamed.boucadair@orange.com] > > > > Sent: Monday, April 9, 2018 4:49 PM > > > > To: Konda, Tirumaleswar Reddy ; > > > > Jon Shallow ; dots@ietf.org > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > Re-, > > > > > > > > Focusing on this part of your answer: > > > > > > > > "No, DNS TTL lifetime does not mean existing session has to be > > > disconnected > > > > after the TTL expires." > > > > > > > > This is exactly the disconnect. We are not discussing **DNS TTL** > > > > but the validity time of a an alternate server as provided in a DOT= S > > > > redirect > > > signal. > > > > > > When the server can explicitly re-direct the client, why provide the > > > validity time of an alternate server ? > > > > [Med] Involving the alternate server is one deployment mode among other= s. > > The current text allows for these two modes: > > > > (1) redirect upon an explicit signal > > (2) automatic fallback upon ttl expiry > > > > Which one to pick is deployment-specific. > > > > TTL makes sense only for (2). >=20 > I don't think (2) is required, HTTP does not support (2) for Temporary re= - > direct (see https://tools.ietf.org/html/rfc7285#section-8.5.3). >=20 [Med] The comparison with 307 is not accurate because that code assumes the= following: The 307 (Temporary Redirect) status code indicates that the target resource resides temporarily under a different URI and the user agent MUST NOT change the request method if it performs an automatic redirection to that URI. Since the redirection can change over time, = =20 the client ought to continue using the original effective request URI ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ for future requests. ^^^^^^^^^^^^^^^^^^^ Supplying the TTL is the only way to master the automatic fall back while a= voiding contacting the "normal" server during the "temporary redirect'.=20 From nobody Mon Apr 9 13:40:27 2018 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 B5F721204DA for ; Mon, 9 Apr 2018 13:40:25 -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 gr2DHoWWqb2p for ; Mon, 9 Apr 2018 13:40:23 -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 73C82124D6C for ; Mon, 9 Apr 2018 13:40:23 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.90_1) (envelope-from ) id 1f5daN-0003mD-28; Mon, 09 Apr 2018 21:40:20 +0100 From: "Jon Shallow" To: , "Konda, Tirumaleswar Reddy" , References: <787AE7BB302AE849A7480A190F8B93302DEFA4A0@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEFA561@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DEFA561@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Mon, 9 Apr 2018 21:40:16 +0100 Message-ID: <029b01d3d042$fa319a10$ee94ce30$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIamFCo/JtwOnwhldffQNYnbiNPYAIQjxxBAf1MOQOjSuUXYA== Content-Language: en-gb Archived-At: Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling 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, 09 Apr 2018 20:40:26 -0000 Hi, See inline [Jon] Regards Jon -----Original Message----- From: mohamed.boucadair@orange.com [mailto: = mohamed.boucadair@orange.com]=20 Sent: 09 April 2018 13:20 To: Konda, Tirumaleswar Reddy; Jon Shallow; dots@ietf.org Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling Re-, Glad to see that we both agree to get out from the DNS comparison.=20 [Jon] Also agree. Perhaps 'ttl' should be renamed 'alt-server-ttl'. Please see inline. Cheers, Med > -----Message d'origine----- > De=A0: Konda, Tirumaleswar Reddy=20 > [mailto:TirumaleswarReddy_Konda@McAfee.com] > Envoy=E9=A0: lundi 9 avril 2018 13:48 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org = Objet=A0: RE:=20 > [Dots] Signal Channel - 300 Redirected Signaling >=20 > > -----Original Message----- > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of=20 > > mohamed.boucadair@orange.com > > Sent: Monday, April 9, 2018 5:12 PM > > To: Konda, Tirumaleswar Reddy ; > > Jon Shallow ; dots@ietf.org > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > Re-, > > > > Please see inline. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Konda,=20 > > > Tirumaleswar Reddy Envoy=E9=A0: lundi 9 avril 2018 13:29 =C0=A0: = BOUCADAIR=20 > > > Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet=A0: Re: [Dots]=20 > > > Signal Channel - 300 Redirected Signaling > > > > > > > -----Original Message----- > > > > From: mohamed.boucadair@orange.com=20 > > > > [mailto:mohamed.boucadair@orange.com] > > > > Sent: Monday, April 9, 2018 4:49 PM > > > > To: Konda, Tirumaleswar Reddy=20 > > > > ; > > > > Jon Shallow ; dots@ietf.org > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > Re-, > > > > > > > > Focusing on this part of your answer: > > > > > > > > "No, DNS TTL lifetime does not mean existing session has to be > > > disconnected > > > > after the TTL expires." > > > > > > > > This is exactly the disconnect. We are not discussing **DNS=20 > > > > TTL** but the validity time of a an alternate server as provided = > > > > in a DOTS redirect > > > signal. > > > > > > When the server can explicitly re-direct the client, why provide=20 > > > the validity time of an alternate server ? > > > > [Med] Involving the alternate server is one deployment mode among others. > > The current text allows for these two modes: > > > > (1) redirect upon an explicit signal > > (2) automatic fallback upon ttl expiry > > > > Which one to pick is deployment-specific. > > > > TTL makes sense only for (2). >=20 > I don't think (2) is required, HTTP does not support (2) for Temporary = > re- direct (see https://tools.ietf.org/html/rfc7285#section-8.5.3). >=20 [Jon] in the general potential overloading case of a specific DOTS = server, to redirect a DOTS client to an alternative DOTS server for a period of = time makes sense to me - and then the DOTS client can then come back again. = So, to me, [2] is a valid option. [Med] The comparison with 307 is not accurate because that code assumes = the following: The 307 (Temporary Redirect) status code indicates that the target resource resides temporarily under a different URI and the user agent MUST NOT change the request method if it performs an automatic redirection to that URI. Since the redirection can change over time, = =20 the client ought to continue using the original effective request URI ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ for future requests. ^^^^^^^^^^^^^^^^^^^ Supplying the TTL is the only way to master the automatic fall back = while avoiding contacting the "normal" server during the "temporary redirect'. = [Jon] Agreed. From nobody Mon Apr 9 14:21:08 2018 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 21E4B12E865 for ; Mon, 9 Apr 2018 14:20:58 -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 OU7-Q044gC_L for ; Mon, 9 Apr 2018 14:20:54 -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 CA563126CBF for ; Mon, 9 Apr 2018 14:20:53 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.90_1) (envelope-from ) id 1f5eDY-0003o5-Qv; Mon, 09 Apr 2018 22:20:52 +0100 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , , References: <016401d3cc1c$03321200$09963600$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7F97@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <01a701d3cc29$ba915b10$2fb41130$@jpshallow.com> <007501d3ccc2$b49f0b00$1ddd2100$@jpshallow.com> <021301d3cfe7$77e5cbe0$67b163a0$@jpshallow.com> In-Reply-To: Date: Mon, 9 Apr 2018 22:20:44 +0100 Message-ID: <02b001d3d048$a2c68be0$e853a3a0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02B1_01D3D051.048EC470" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEYhrWXRSNBek+fWBybzdJS41Z0KAI4GsKdAX18SvQDE9KikwNzyn9FAeCfBHcAmG/gMgGrGCDSpPxxLxA= Content-Language: en-gb Archived-At: Subject: Re: [Dots] Data Channel ACL fragments 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, 09 Apr 2018 21:20:59 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02B1_01D3D051.048EC470 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Tiru, =20 See inline [Jon2] =20 Regards =20 Jon =20 =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Thursday, April 5, 2018 3:15 PM To: Konda, Tirumaleswar Reddy ; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] Data Channel ACL fragments =20 Hi Tiru, =20 Actually no, as there is a disconnect between the Cisco document and = what we have currently got set up. =20 The Cisco Document refers to ACL, which is an ACE in = netmod-acl-model/DOTS speak. A DOTS ACL can be a list of separate matching ACEs. =20 With netmod-acl, we have layer 3 definitions and then separately layer 4 definitions =96 there is now no concept of L3+L4 within the same ACE. =20 So, the Cisco statement =93Note: When there is both Layer 3 and Layer 4 information in the ACL line and the fragments keyword is present=94 will = never be true for an ACE entry. =20 [TR] No, as per the ACE definition in draft-ietf-netmod-acl-model-16, = The choice statements within the match container allow for selection of one header within each of "l2", "l3", or "l4" headers.=20 It is possible to specify both L3 and L4 information in the ACE (each = ACE has a group of match criteria). =20 [Jon1] =96 My bad =96 I was reading =93Choice=94 as choosing L3 or L4, = not that the choice was referring to the sub-elements within the choice. So, yes, L3 = + L4 are supported. =20 ---- =20 I still do not understand from the Cisco Document how you can build a = set of ACLs that say (but I may be missing something) =93All traffic to port 53 is allowed unless it is fragmented, in which = case all fragments are to be dropped=94 =20 I can create a set of ACLs that say =93All traffic to port 53 is allowed unless it is fragmented, in which = case all non-initial fragments are to be dropped=94 Which does set things up for a DoS of the target with all the initial fragments waiting re-assembly. =20 [TR] The don=92t think a ACL should blindly drop all fragmented packets, fragmentation may or may not happen because of a DoS attack. Do vendors currently support what you are asking ? =20 [Jon1] If (IP_MF | IP_OFFMASK) is set in frag_off (linux) in an IPv4 = packet, then the packet is a part of a fragmented packet sequence. Dropping any packets with (IP_MF | IP_OFFMASK) !=3D 0 will safely drop all the = fragmented packets. This then protects the target=92s IP reassembly logic=92s RAM = usage. Similarly, for IPv6 there is the detection of protocol 44. =20 [Jon1] NCC=92s mitigation appliances can disable fragmented packets = either manually or when there is an ongoing fragmentation attack where the = complete set of fragments for a packet are not seen. =20 [TR2] My question is whether vendors support any ACL that drops all fragments (e.g. a separate feature called virtual fragmentation and reassembly is used by Cisco devices to protect the target=92s reassembly logic, see https://www.cisco.com/c/en/us/td/docs/ios/sec_data_plane/configuration/gu= ide /12_4/sec_data_plane_12_4_book/sec_virt_frag_reassm.html but I did not = find any proprietary ACL to drop all fragments) ? =20 [Jon2] I would not want use virtual re-assembly (performance / RAM = usage) as that is a simple way to take out a router [Jon2] Off the top of my head =20 [Jon1] I still question as to whether we should be using netmod-acl=92s version of fragmentation instead of using a DOTS extension. =20 [TR2] How will using netmod-acl version helps drop DoS attack using non-initial fragments only ? =20 [Jon2] Dropping all but the initial fragment will in its own rights = cause a IP re-assembly RAM attack on the target if the L3+L4 definition is to = allow traffic through (as well as a potential performance lookup hit). So, I think we are asking the wrong question here. =20 [Jon2] In the early days of the Internet, someone had the smart idea of sending the final fragment first =96 so the recipient could pre-allocate = the full packet size before the remaining fragments came in. This then = messed up firewalls who could not properly do any filtering as the initial = fragment came in last. And hence the perceived need to drop non-initial = fragments to get around this issue. It still does not handle the buildup of the = first fragment set building up on the target server. =20 [Jon2] The =93flags->fragment=94 definition is ambiguous for an ACE (but = valid as to whether to allow a packet to get fragmented or not =96 is that = really a ACE?) which I would like to use. =93Flags->more=94 definition covers = all fragments but the last fragment. =93Offset=94 is unfortunately not a = range, but otherwise would get used for the final fragment. ~jon2 =20 -Tiru =20 ~jon1 =20 -Tiru =20 ---- =20 Which then gets more complicated to construct something when we can only = do either L3 or L4 matching on a per ACE. =20 Regards =20 Jon =20 From: Dots [ mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 05 April 2018 09:23 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] Data Channel ACL fragments =20 Hi Jon, =20 The fragment definition to protect the target from attacks that use non-initial fragments only. We followed the Security considerations for IP filtering given in = Section 2 of https://www.ietf.org/rfc/rfc1858.txt to drop the initial fragment, so = the non-initial fragments will be discarded by the destination host (its implemented and discussed in https://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulati= on- gre/8014-acl-wp.html). =20 -Tiru =20 From: Dots [ = mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Wednesday, April 4, 2018 9:00 PM To: mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] Data Channel ACL fragments =20 Hi Med et all, =20 See inline [Jon] =20 Regards =20 Jon =20 From: Dots [mailto: = dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 04 April 2018 15:27 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Data Channel ACL fragments =20 Re-, =20 I guess we do still need this because we wanted to achieve this functionality (especially for the non-initial fragments): =20 =3D=3D This document supports fragment filtering which adds an additional layer of protection against a DoS attack that uses non-initial fragments only. When there is only layer 3 information in the ACL entry and the fragments keyword is present, for non-initial fragments matching the ACE entry, the 'deny' or 'accept' action associated with the ACE entry will be enforced. For initial or non-fragment matching the ACE entry, the next ACE entry will be processed. When there is both layer 3 and layer 4 information in the ACE entry and the fragments keyword is present, the ACE action is conservative for both 'accept' and 'deny' actions. The actions are conservative to not accidentally deny a fragmented portion of a flow because the fragments do not contain sufficient information to match all of the filter attributes. In the 'deny' action case, instead of denying a non-initial fragment, the next ACE entry is processed. In the 'accept' case, it is assumed that the layer 4 information in the non- initial fragment, if available, matches the layer 4 information in the ACE entry. =3D=3D =20 [Jon] Actually, as I read the text above, if the additional layer of protection is required against fragmented attacks and v-[46]-fragment is = set with action =93drop=94, then any non-initial fragment is dropped =96 = fine. =20 However, the initial fragment skips this ACE test and goes onto the next ACE. Assuming that there is a =93accept=94 that matches everything else = (i.e. we like the packet apart from when it is fragmented), then the initial fragment is let through. =20 The target IP then consumes lots of RAM whilst waiting for the missing fragment segments=85=85..D(D)oS Success. =20 There is no way to drop the initial fragment with the above text other = than to =93drop=94 genuine non fragmented traffic as well. I think that = logic is flawed to drop just subsequent fragments. =20 [Jon] I also wonder how the above is going to get implemented =96 it = would be easier to say any fragmented packet sequence is not allowed (including = the initial packet) rather than only a part of the sequence which then leads = to a DoS in its own rights. =20 No? =20 [Jon] See above. I do agree that flags -> fragment -> 1 is a bit = ambiguous is its definition when used to match a packet as an acl/ace, but I do = think the match intent is that the packet is not fragmented. =20 =20 Cheers, Med =20 De : Dots [ mailto:dots-bounces@ietf.org] = De la part de Jon Shallow Envoy=E9 : mercredi 4 avril 2018 15:51 =C0 : dots@ietf.org Objet : [Dots] Data Channel ACL fragments =20 Hi there, =20 Do we still need to have the fragment definition for ACEs in the data channel? =20 draft-ietf-netmod-acl-model-18 now supports fragments for ipv4 (flags + options) and implicitly in ipv6 through the next header field protocol = set to 44 (fragment extension header). =20 IPV4 =3D=3D=3D=3D grouping acl-ipv4-header-fields { description "Fields in IPv4 header."; ... leaf flags { type bits { bit reserved { position 0; description "Reserved. Must be zero."; } bit fragment { position 1; description "Setting value to 0 indicates may fragment, while setting the value to 1 indicates do not fragment."; } bit more { position 2; description "Setting the value to 0 indicates this is the last fragment, and setting the value to 1 indicates more fragments are coming."; } } description "Bit definitions for the flags field in IPv4 header."; } =20 leaf offset { type uint16 { range "20..65535"; } description "The fragment offset is measured in units of 8 octets (64 bits). The first fragment has offset zero. The length is 13 bits"; } =20 Regards =20 Jon =20 ------=_NextPart_000_02B1_01D3D051.048EC470 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

See inline = [Jon2]

 

Regards

 

Jon

 

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Thursday, April 5, 2018 3:15 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: RE: = [Dots] Data Channel ACL fragments

 

Hi = Tiru,

 

Actually no, as there is = a disconnect between the Cisco document and what we have currently got = set up.

 

The Cisco Document = refers to ACL, which is an ACE in netmod-acl-model/DOTS speak.  A = DOTS ACL can be a list of separate matching = ACEs.

 

With netmod-acl, we have = layer 3 definitions and then separately layer 4 definitions – = there is now no concept of L3+L4 within the same = ACE.

 

So, the Cisco statement = “Note: When there is both Layer 3 and Layer 4 information in the = ACL line and the fragments keyword is present” will never be true = for an ACE entry.

 

[TR] No, as per the ACE = definition in draft-ietf-netmod-acl-model-16, The choice statements = within the match container allow for selection of one header within each = of "l2", "l3", or "l4" headers. =

It is possible to specify both L3 and L4 = information in the ACE (each ACE has a group of match = criteria).

 

[Jon1] – My bad = – I was reading “Choice” as choosing L3 or L4, not = that the choice was referring to the sub-elements within the = choice.  So, yes, L3 + L4 are supported.

 

----

 

I still do not = understand from the Cisco Document how you can build a set of ACLs that = say (but I may be missing something)

“All traffic to = port 53 is allowed unless it is fragmented, in which case all fragments = are to be dropped”

 

I can create a set of = ACLs that say

“All traffic to port 53 is allowed unless = it is fragmented, in which case all non-initial fragments are to be = dropped”

Which does set things up for a DoS of the target = with all the initial fragments waiting = re-assembly.

 

[TR] The don’t think a ACL should blindly drop all = fragmented packets, fragmentation may or may not happen because of a DoS = attack. Do vendors currently support what you are asking = ?

 

[Jon1] If = (IP_MF | IP_OFFMASK) is set in frag_off (linux) in an IPv4 packet, then = the packet is a part of a fragmented packet sequence.  Dropping any = packets with (IP_MF | IP_OFFMASK) !=3D 0 will safely drop all the = fragmented packets.  This then protects the target’s IP = reassembly logic’s RAM usage.   Similarly, for IPv6 = there is the detection of protocol 44.

 

[Jon1] = NCC’s mitigation appliances can disable fragmented packets either = manually or when there is an ongoing fragmentation attack where the = complete set of fragments for a packet are not = seen.

 

[TR2]  My question is whether vendors support any ACL = that drops all fragments (e.g. a separate feature called virtual = fragmentation and reassembly is used by Cisco devices to protect the = target’s reassembly logic, see http= s://www.cisco.com/c/en/us/td/docs/ios/sec_data_plane/configuration/guide/= 12_4/sec_data_plane_12_4_book/sec_virt_frag_reassm.html but I did = not find any proprietary ACL to drop all fragments) = ?

 

[Jon2] I = would not want use virtual re-assembly (performance / RAM usage) as that = is a simple way to take out a router

[Jon2] Off = the top of my head

 

[Jon1] I = still question as to whether we should be using netmod-acl’s = version of fragmentation instead of using a DOTS = extension.

 

[TR2] How will using netmod-acl version helps drop DoS = attack using non-initial fragments only ?

 

[Jon2] = Dropping all but the initial fragment will in its own rights cause a IP = re-assembly RAM attack on the target if the L3+L4 definition is to allow = traffic through (as well as a potential performance lookup hit).=A0 So, = I think we are asking the wrong question here.

 

[Jon2] In = the early days of the Internet, someone had the smart idea of sending = the final fragment first – so the recipient could pre-allocate the = full packet size before the remaining fragments came in.=A0 This then = messed up firewalls who could not properly do any filtering as the = initial fragment came in last.=A0 And hence the perceived need to drop = non-initial fragments to get around this issue.=A0 It still does not = handle the buildup of the first fragment set building up on the target = server.

 

[Jon2] The = “flags->fragment” definition is ambiguous for an ACE (but = valid as to whether to allow a packet to get fragmented or not – = is that really a ACE?) which I would like to use.=A0 = “Flags->more” definition covers all fragments but the = last fragment. “Offset” is unfortunately not a range, but = otherwise would get used for the final fragment.

~jon2

 

-Tiru

 

~jon1

 

-Tiru

 

----

 

Which then gets more = complicated to construct something when we can only do either L3 or L4 = matching on a per ACE.

 

Regards

 

Jon

 

From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org= ] On Behalf Of Konda, Tirumaleswar = Reddy
Sent: 05 April 2018 09:23
To: Jon Shallow; = mohamed.boucadair@orange.com; dots@ietf.org
Subject: Re: [Dots] Data Channel ACL = fragments

 

Hi = Jon,

 

The fragment definition to protect = the target from attacks that use non-initial fragments = only.

We followed the Security = considerations for IP filtering given in Section 2 of https://www.ietf.org/rfc/rfc1858.txt= to drop the initial fragment, so = the non-initial fragments will be discarded by the destination host (its = implemented and discussed in https://www.cisco.com/c/en/us/suppor= t/docs/ip/generic-routing-encapsulation-gre/8014-acl-wp.html).

 

-Tiru

 

 

Hi Med et all,

 

See inline = [Jon]

 

Regards

 

Jon

 

From: Dots [mailto: do= ts-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com
Sent: 04 April 2018 15:27
To: Jon = Shallow; dots@ietf.org
Subject: Re: [Dots] Data Channel ACL = fragments

 

Re-,

 

I guess we do still need this because we wanted to = achieve this functionality (especially for the non-initial = fragments):

 

=3D=3D

   This document supports = fragment filtering which adds an additional

   layer of protection against a = DoS attack that uses non-initial

   fragments only.  When = there is only layer 3 information in the ACL

   entry and the fragments = keyword is present, for non-initial fragments

   matching the ACE entry, the = 'deny' or 'accept' action associated with

   the ACE entry will be = enforced.  For initial or non-fragment = matching

   the ACE entry, the next ACE = entry will be processed.  When there is

   both layer 3 and layer 4 = information in the ACE entry and the

   fragments keyword is present, = the ACE action is conservative for both

   'accept' and 'deny' = actions.  The actions are conservative to = not

   accidentally deny a = fragmented portion of a flow because the

   fragments do not contain = sufficient information to match all of the

   filter attributes.  In = the 'deny' action case, instead of denying a

   non-initial fragment, the = next ACE entry is processed.  In the

   'accept' case, it is assumed = that the layer 4 information in the non-

   initial fragment, if = available, matches the layer 4 information in

   the ACE = entry.

=3D=3D

 

[Jon] = Actually, as I read the text above, if the additional layer of = protection is required against fragmented attacks and v-[46]-fragment is = set with action “drop”, then any non-initial fragment is = dropped – fine.

 

However, = the initial fragment skips this ACE test and goes onto the next = ACE.  Assuming that there is a “accept” that matches = everything else (i.e. we like the packet apart from when it is = fragmented), then the initial fragment is let = through.

 

The target = IP then consumes lots of RAM whilst waiting for the missing fragment = segments……..D(D)oS Success.

 

There is no = way to drop the initial fragment with the above text other than to = “drop” genuine non fragmented traffic as well.  I think = that logic is flawed to drop just subsequent = fragments.

 

[Jon] I = also wonder how the above is going to get implemented – it would = be easier to say any fragmented packet sequence is not allowed = (including the initial packet) rather than only a part of the sequence = which then leads to a DoS in its own rights.

 

No?

 

[Jon] See = above.  I do agree that flags -> fragment -> 1 is a bit = ambiguous is its definition when used to match a packet as an acl/ace, = but I do think the match intent is that the packet is not = fragmented.

 

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow
Envoy=E9 : = mercredi 4 avril 2018 15:51
=C0 : dots@ietf.org
Objet : [Dots] Data Channel ACL = fragments

 

Hi = there,

 

Do we still need to have the fragment definition for = ACEs in the data channel?

 

draft-ietf-netmod-acl-model-18 now supports fragments = for ipv4 (flags + options) and implicitly in ipv6 through the next = header field protocol set to 44 (fragment extension = header).

 

IPV4

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

  = grouping acl-ipv4-header-fields {

    description

      "Fields in IPv4 = header.";

...

    leaf flags {

      type bits = {

        bit = reserved {

          = position 0;

          = description

         &= nbsp;  "Reserved. Must be zero.";

        = }

        bit = fragment {

          = position 1;

          = description

         &= nbsp;  "Setting value to 0 indicates may fragment, while = setting

         &= nbsp;   the value to 1 indicates do not = fragment.";

        = }

        bit more = {

          = position 2;

          = description

         &= nbsp;  "Setting the value to 0 indicates this is the last = fragment,

         &= nbsp;   and setting the value to 1 indicates more fragments = are

         &= nbsp;   coming.";

        = }

      = }

      = description

        "Bit = definitions for the flags field in IPv4 header.";

    }

 

    leaf offset {

      type uint16 = {

   =      range = "20..65535";

      }

      = description

        "The = fragment offset is measured in units of 8 octets (64 = bits).

         The = first fragment has offset zero. The length is 13 = bits";

    = }

 

Regards

 

Jon

 

------=_NextPart_000_02B1_01D3D051.048EC470-- From nobody Mon Apr 9 14:24:54 2018 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 5672312D7EF for ; Mon, 9 Apr 2018 14:24:53 -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 Lu3AClGZMpqX for ; Mon, 9 Apr 2018 14:24:49 -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 93FAC126CBF for ; Mon, 9 Apr 2018 14:24:48 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.90_1) (envelope-from ) id 1f5eHN-0003oN-50; Mon, 09 Apr 2018 22:24:47 +0100 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , , References: <008401d3c4fd$216d0840$644718c0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF1067@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <014801d3c5b7$94c67f00$be537d00$@jpshallow.com> <009a01d3cdab$150b4c40$3f21e4c0$@jpshallow.com> <00cf01d3cdbe$24876650$6d9632f0$@jpshallow.com> <01fd01d3cfe4$a71b6580$f5523080$@jpshallow.com> <024901d3cff6$9d4beea0$d7e3cbe0$@jpshallow.com> In-Reply-To: Date: Mon, 9 Apr 2018 22:24:43 +0100 Message-ID: <02c301d3d049$2f60cf20$8e226d60$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02C4_01D3D051.9128E0A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGlexwLZckIYJuvKwEmwuQr1rXL6AKpdMHOAgMRKpIBsBKRFgKXgqsdAxHSSssB/GODugGyw551AT90vc8BfRxiYwGyPN+IAfZRzPoCBSpzvqOUoCFA Content-Language: en-gb Archived-At: Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 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, 09 Apr 2018 21:24:53 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02C4_01D3D051.9128E0A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Tiru, =20 See inline [Jon2] =20 Regards =20 Jon =20 =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Monday, April 9, 2018 2:55 PM To: Konda, Tirumaleswar Reddy ; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 =20 Hi Tiru, =20 If a DOTS client knows the full scope of the Networks that it is allowed = to use in a ACL or mitigate request, and the DOTS server limits any update = from that client to the scope of Networks (with any unexpected side effects = that may have), then there is no difference in my mind as to whether the DOTS clients fills in the destination-network, or the DOTS server does so on = the DOTS client=92s behalf before ACL instantiation if destination-network = is not defined. =20 [TR] The above model only works when the DOTS server and DOTS client are directly communicating with each other (In the above, the DOTS server = knows the DOTS client identity to enforce the scope but will not the DOTS = client identity in the presence of a client-domain DOTS gateway).=20 =20 [Jon1] The last para of =9310. Security Considerations=94 states DOTS servers MUST verify that requesting DOTS clients are entitled to trigger actions on a given IP prefix. That is, only actions on IP resources that belong to the DOTS client' domain MUST be authorized by a DOTS server. The exact mechanism for the DOTS servers to validate that the target prefixes are within the scope of the DOTS client's domain is deployment-specific. =20 [Jon1] So it makes no difference if the DOTS client happens to be an = agent part of a client-domain DOTS gateway. If the client-domain DOTS gateway = is hiding all the =91behind=92 clients and presenting as single client, = there is no issue. However, if the =91behind=92 clients are presented as 2 or more = =91cuid=92s by the DOTS gateway, then either the scope is per =91cuid=92, or if = =91cdid=92s are being applied by the upstream server domain DOTS gateway then on a per =91cdid=92 basis if wanted. =20 For a client behind a client domain DOTS gateway, there may be non = public IP addresses that the (DMS) client is responsible for, but these should = never be sent out through the DOTS gateway (and should be rejected by the DOTS server as out of scope). There does have to be a common agreement = between DOTS client & DOTS server as to what Networks are in scope, but the DOTS client currently cannot request this from the DOTS server and has to be agreed out of band. =20 [TR] I don=92t see a new problem, even when a DOTS client sends a = mitigation request it needs to know if the targets conveyed in the mitigation = request are in its scope or not. =20 [Jon1] but again, the DOTS server MUST verify the IP prefix is valid, so = has to know scope. I agree that the DOTS client (or client domain DOTS = gateway) needs to know (today out of band) what is the scope of what is valid to request. The challenge comes when the DOTS server=92s scope is = reconfigured, but not yet updated on the DOTS client. =20 =20 [TR2] The scope would be first updated on the DOTS client domain and = then on the DOTS server (e.g. IP prefix re-numbering).=20 =20 [Jon2] I was more thinking of a DOTS client that got missed off a list = when the DOTS server was updated. Normally though, they should be kept in = sync but which one gets updated first is uncertain to me. =20 There is no reason as to why the DOTS server cannot maintain a valid = scope of Networks that the client domain DOTS gateway is allowed to request = for validity checking =96 unless I am missing something? =20 [TR] You are partially right, the DOTS server does not know the valid = scope of prefixes that a DOTS client behind client-domain DOTS gateway is = allowed to request. =20 [Jon1] Again, the last para of 10. stands here, and so the scope has to = be known by the DOTS server. =20 [TR] Yes, but it may not know the scope of a DOTS client behind a client-domain DOTS gateway. =20 [Jon2] But it will know what the client-domain DOTS gateway is allowed = to pass through in terms of Destination Network. The client-domain DOTS gateway will separately need to know what Destination networks are = allowed to get out through the gateway. =20 Troubleshooting has kept me in a job for more years than I care to = remember, anything to aid troubleshooting is what I am interested in and so = totally agree that rogue DOTS client=92s capabilities need to be kept under = control with suitable logging to aid diagnosis is a major plus. However in this case, the implicit rule is no different to the DOTS client requesting = the full Networks scope in an ACL request. =20 [TR] If the client is not authorized to request the full network scope, = it can detected by the client-domain DOTS gateway and rejects the filtering rule by comparing the destination-networks=20 specified in the ACE. [Jon1] Agreed, it is the responsibility of the client domain DOTS = gateway to only allow out valid networks that are valid within the DOTS server=92s = scope. =20 [Jon1] Should we support a way for the client domain DOTS gateway (i.e. DOTS client agent) to programmatically get the current valid network = scope from the DOTS server? =20 [TR2] It will not solve the above problem of detecting and rejecting a = rouge (or misconfigured) DOTS client behind client domain DOTS gateway sending = ACL without specifying destination-network. =20 [Jon2] Hmm. If the client-domain DOTS gateway is restricted in scope as = to what it is allowed to request, and a rogue client behind the gateway = does not specify a destination-network, then when the request passes through = the gateway the upstream DOTS server will only use the scope allowed for = that specific client-domain DOTS gateway. Again, it is exactly the same as = if the rogue client was to specify the full set of allowed scope as a set = of destination networks in terms of damage capabilities. =20 -Tiru =20 ~jon1 =20 -Tiru =20 Regards =20 Jon =20 From: Konda, Tirumaleswar Reddy [mailto: = TirumaleswarReddy_Konda@mcafee.com] Sent: 07 April 2018 06:48 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 =20 Hi Jon, =20 DOTS clients (intelligent DDoS mitigation system, application server) = will know the destination networks, what kind of DOTS clients will not know = the destination networks they are allowed to use ? DOTS clients could be behind client-domain DOTS gateway, DOTS server = will have no way to validate the DOTS client identity sending the ACE request = to determine the destination IP addresses in its scope, it will only know = the destination IP addresses in the DOTS client domain scope.=20 Further, the implicit rule can be misused by compromised DOTS clients = (e.g. black-list good traffic to the entire DOTS client domain) and it=92s a troubleshooting nightmare to find the culprit device adversely impacting = the entire network. =20 Cheers, -Tiru =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Friday, April 6, 2018 9:14 PM To: Konda, Tirumaleswar Reddy ; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 =20 Hi Tiru, =20 The DOTS server is likely to have a scope of IP addresses that are valid = for the client to ask for protection for based on the cuid or cdid. =20 The DOTS client may have some knowledge of the scope IPs by some out of = band method, but programmatically cannot ask the server what they are.=20 =20 If a client specifies a destination network that is out of the valid = scope of IP addresses, then the ACE request will get rejected. The client may then have a challenge to work out what destination networks it is = allowed to use. =20 How does a client set up a blacklist for all the IPS within his allowed scope if it does not know what the scope is? =20 If the client has not provided a destination network, then the DOTS = server can auto-fill in the missing information at the time of the ACE instantiation =96 and this then handles if the scope of IP addresses = change. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 06 April 2018 16:19 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 =20 I don=92t understand how the DOTS server/mitigation will fill it in at = time of ACE instantiation, and why can=92t the DOTS client fill the destination network details ? =20 -Tiru =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Friday, April 6, 2018 6:58 PM To: Konda, Tirumaleswar Reddy ; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 =20 Hi there, =20 There is no current way to request of a DOTS Server as to what is the = set of IP networks that a DOTS client can use either within a mitigation = request or to set up an ACL other than by =93testing for ok or not ok=94 with lots = of different IP addresses. =20 There is a reasonable likelihood of the scope of valid IPs from the = Server=92s perspective will change over time. So, unless a DOTS client wants to control a specific destination network, then my suggestion would be to = leave the ACE destination network empty and for the DOTS Server / DOTS = mitigator (how is out of scope) to fill it in at time of ACE instantiation. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 27 March 2018 13:49 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 =20 Please see inline [TR] =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Tuesday, March 27, 2018 4:07 PM To: Konda, Tirumaleswar Reddy ; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 =20 Hi Tiru / Med =20 See inline [Jon] =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 27 March 2018 09:47 To: mohamed.boucadair@orange.com; Jon Shallow; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 =20 I also support to mandate destination-network for immediately enforced filtering rules. [Jon] This can be enforced / inserted by the DOTS Server for all the destination networks of the domain that the DOTS client =91belongs=92 = to. That said, it would be good to always have the destination network in an ACL = as it can be validated and cross-checked whenever the legitimate set of = domain protected IPs are updated. [Jon] However, what happens to the Destination network in the case of a = call home DOTS client that becomes a quasi DOTS server and the Destination networks are somewhere out on the Internet? =20 [TR] DDOS is a targeted attack, so the DOTS client can specify the destination network targeted by devices in the DOTS server domain and = the DOTS server can validate if the destination network is indeed targeted = by its devices. =20 -Tiru =20 From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.....boucadair@orange.com =20 Sent: Tuesday, March 27, 2018 1:09 PM To: Jon Shallow ; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 =20 Hi Jon,=20 =20 Thank you for the comments. =20 Please see inline. =20 Cheers, Med =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : lundi 26 mars 2018 14:23 =C0 : dots@ietf.org Objet : [Dots] IETF 101 Presentation Data Channel Issue #4 =20 Hi there, =20 As per Med=92s presentation to the IETF 101 =20 Issue #4: Per-Domain or Per-client Filters? =20 =95 Conclusion =96 Filters that are activated only during mitigation time are on a = per-client basis =95 Filters are per-domain when are immediately applied =20 =93Filters are per-domain when are immediately applied=94 is what I have = an challenge with. =20 If we have a compromised or rogue DOTS client, the simple use of = something like curl, along with the client certificates etc. can be used to = generate any ACL with activation-type :=3D =91immediate=92 which is then = immediately applied for all traffic within the domain as per the above. =20 [Med] Yes. FWIW, this attack is called out in the security = considerations section:=20 =20 =93Nevertheless, an attacker who can access a DOTS client is technically capable of launching various attacks, such as: =20 ..; =20 o Set invalid ACL entries, which may prevent legitimate traffic from being forwarded. Likewise, invalid ACL entries may lead to forward DDoS traffic. =93 [Jon] Agreed that the attack is covered off in the Security section, but = we should be limiting the possibility / scope of the attack vector by = enforcing some rules as to what is / is not allowed. Allowing a DOTS client to be able to affect all the traffic within the domain is a huge risk to me = and should not be allowed. =20 So, a ACL that blacklists the DNS server, or drops all port 443 traffic = etc. can easily cause all of the other clients / devices within the domain to = be taken off air. Putting the intelligence into the DOTS server to not = allow this to happen could be a challenge. [The signal channel is much harder to compromise and affect traffic = flows to other areas within the domain] =20 I believe that an ACL instantiated by a DOTS client (immediate or when-mitigating) should only apply to the DOTS client=92s traffic which = means that the destination-network has to be a part of the ACL, whether = implicitly added by the DOTS server, or by the DOTS client and suitably validated. =20 [Med] Putting aside that I don=92t parse =93DOTS client=92s traffic=94, [Jon] I was referring to all the traffic flows that a DOTS client can legitimately request control of to the DOTS server that are within the = scope of what the DOTS client is protecting (which may or may not be the DOTS client=92s IP address). I interpret your answer as a support to this question raised for issue = #4: * =93Should we mandate destination-network to be present for immediately enforced filters?=94 [Jon] See response to Tiru=92s Agreement above. ~Jon There is nothing to stop the DOTS server or DOTS mitigator merging = common ACLs to reduce the number of ACLs within the mitigation device. =20 As a side note =93mitigation-time=94 is perhaps a bad name as it implies = a time period =96 something like =93when-mitigating=94 to me is clearer. [Med] Fixed in my local copy. Thank you. =20 Regards =20 Jon ------=_NextPart_000_02C4_01D3D051.9128E0A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

See inline = [Jon2]

 

Regards

 

Jon

 

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Monday, April 9, 2018 2:55 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: RE: = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

Hi Tiru,

 

If a DOTS client knows = the full scope of the Networks that it is allowed to use in a ACL or = mitigate request, and the DOTS server limits any update from that client = to the scope of Networks (with any unexpected side effects that may = have), then there is no difference in my mind as to whether the DOTS = clients fills in the destination-network, or the DOTS server does so on = the DOTS client’s behalf before ACL instantiation if = destination-network is not defined.

 

[TR] The = above model only works when the DOTS server and DOTS client are directly = communicating with each other (In the above, the DOTS server knows the = DOTS client identity to enforce the scope but will not the DOTS client = identity in the presence of a client-domain DOTS gateway). =

 

[Jon1] The last para of = “10. Security Considerations” states

   DOTS servers MUST verify that = requesting DOTS clients are entitled to

   trigger actions on a given IP = prefix.  That is, only actions on IP

   resources that belong to the DOTS = client' domain MUST be authorized

   by a DOTS server.  The exact = mechanism for the DOTS servers to

   validate that the target prefixes = are within the scope of the DOTS

   client's = domain is deployment-specific.

 

[Jon1] So it makes no difference if the DOTS = client happens to be an agent part of a client-domain DOTS = gateway.  If the client-domain DOTS gateway is hiding all the = ‘behind’ clients and presenting as single client, there is = no issue.  However, if the ‘behind’ clients are = presented as 2 or more ‘cuid’s by the DOTS gateway, then = either the scope is per ‘cuid’, or if ‘cdid’s = are being applied by the upstream server domain DOTS gateway then on a = per ‘cdid’ basis if wanted.

 

For a client behind a = client domain DOTS gateway, there may be non public IP addresses that = the (DMS) client is responsible for, but these should never be sent out = through the DOTS gateway (and should be rejected by the DOTS server as = out of scope).  There does have to be a common agreement between = DOTS client & DOTS server as to what Networks are in scope, but the = DOTS client currently cannot request this from the DOTS server and has = to be agreed out of band.

 

[TR] I = don’t see a new problem, even when a DOTS client sends a = mitigation request it needs to know if the targets conveyed in the = mitigation request are in its scope or not.

 

[Jon1] but again, the = DOTS server MUST verify the IP prefix is valid, so has to know = scope.  I agree that the DOTS client (or client domain DOTS = gateway) needs to know (today out of band) what is the scope of what is = valid to request.  The challenge comes when the DOTS server’s = scope is reconfigured, but not yet updated on the DOTS client.  =

 

[TR2] The scope would be first updated on the DOTS = client domain and then on the DOTS server (e.g. IP prefix re-numbering). =

 

[Jon2] I was more = thinking of a DOTS client that got missed off a list when the DOTS = server was updated.  Normally though, they should be kept in sync = but which one gets updated first is uncertain to = me.

 

There is no reason as to = why the DOTS server cannot maintain a valid scope of Networks that the = client domain DOTS gateway is allowed to request for validity checking = – unless I am missing something?

 

[TR] You are = partially right, the DOTS server does not know the valid scope of = prefixes that a DOTS client behind client-domain DOTS gateway is allowed = to request.

 

[Jon1] Again, the last = para of 10. stands here, and so the scope has to be known by the DOTS = server.

 

[TR] Yes, = but it may not know the scope of a DOTS client behind a client-domain = DOTS gateway.

 

[Jon2] But it will know = what the client-domain DOTS gateway is allowed to pass through in terms = of Destination Network.  The client-domain DOTS gateway will = separately need to know what Destination networks are allowed to get out = through the gateway.

 

Troubleshooting has kept = me in a job for more years than I care to remember, anything to aid = troubleshooting is what I am interested in and so totally agree that = rogue DOTS client’s capabilities need to be kept under control = with suitable logging to aid diagnosis is a major plus.  However in = this case, the implicit rule is no different to the DOTS client = requesting the full Networks scope in an ACL = request.

 

[TR] If the = client is not authorized to request the full network scope, it can = detected by the client-domain DOTS gateway and rejects the filtering = rule by comparing the destination-networks

        specifi= ed in the ACE.

[Jon1] Agreed, it is the = responsibility of the client domain DOTS gateway to only allow out valid = networks that are valid within the DOTS server’s = scope.

 

[Jon1] Should we support = a way for the client domain DOTS gateway  (i.e. DOTS client agent) = to programmatically get the current valid network scope from the DOTS = server?

 

[TR2] It = will not solve the above problem of detecting and rejecting a rouge (or = misconfigured) DOTS client behind client domain DOTS gateway sending ACL = without specifying destination-network.

 

[Jon2] Hmm.  If the = client-domain DOTS gateway is restricted in scope as to what it is = allowed to request, and a rogue client behind the gateway does not = specify a destination-network, then when the request passes through the = gateway the upstream DOTS server will only use the scope allowed for = that specific client-domain DOTS gateway.  Again, it is exactly the = same as if the rogue client was to specify the full set of allowed scope = as a set of destination networks in terms of damage = capabilities.

 

-Tiru

 

~jon1

 

-Tiru

 

Regards

 

Jon

 

From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Kond= a@mcafee.com]
Sent: 07 April 2018 06:48
To: Jon = Shallow; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: RE: = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

Hi = Jon,

 

DOTS clients (intelligent DDoS = mitigation system, application server) will know the destination = networks, what kind of DOTS clients will not know the destination = networks they are allowed to use ?

DOTS clients could be behind = client-domain DOTS gateway, DOTS server will have no way to validate the = DOTS client identity sending the ACE request to determine the = destination IP addresses in its scope, it will only know the destination = IP addresses in the DOTS client domain scope.

Further, the implicit rule can be = misused by compromised DOTS clients (e.g. black-list good traffic to the = entire DOTS client domain) and it’s a  troubleshooting = nightmare to find the culprit device adversely impacting the entire = network.

 

Cheers,

-Tiru

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Friday, April 6, 2018 9:14 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: RE: = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

Hi Tiru,

 

The DOTS server is = likely to have a scope of IP addresses that are valid for the client to = ask for protection for based on the cuid or = cdid.

 

The DOTS client may have = some knowledge of the scope IPs by some out of band method, but = programmatically cannot ask the server what they are. =

 

If a client specifies a = destination network that is out of the valid scope of IP addresses, then = the ACE request will get rejected.  The client may then have a = challenge to work out what destination networks it is allowed to = use.

 

How does a client set up = a blacklist for all the IPS within his allowed scope if it does not know = what the scope is?

 

If the client has not = provided a destination network, then the DOTS server can auto-fill in = the missing information at the time of the ACE instantiation – and = this then handles if the scope of IP addresses = change.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 06 April 2018 = 16:19
To: Jon Shallow; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: Re: = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

I don’t = understand how the DOTS server/mitigation will fill it in at time of ACE = instantiation, and why can’t the DOTS client fill the destination = network details ?

 

-Tiru

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Friday, April 6, 2018 6:58 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: RE: = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

Hi there,

 

There is no current way = to request of a DOTS Server as to what is the set of IP networks that a = DOTS client can use either within a mitigation request or to set up an = ACL other than by “testing for ok or not ok” with lots of = different IP addresses.

 

There is a reasonable = likelihood of the scope of valid IPs from the Server’s perspective = will change over time.  So, unless a DOTS client wants to control a = specific destination network, then my suggestion would be to leave the = ACE destination network empty and for the DOTS Server / DOTS mitigator = (how is out of scope) to fill it in at time of ACE = instantiation.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 27 March 2018 = 13:49
To: Jon Shallow; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: Re: = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

Please see inline = [TR]

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Tuesday, March 27, 2018 4:07 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: RE: = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

Hi Tiru / Med

 

See inline = [Jon]

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 27 March 2018 = 09:47
To: mohamed.boucadair@orange.com= ; Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

I also support to = mandate destination-network for immediately enforced filtering = rules.

[Jon] This can be = enforced / inserted by the DOTS Server for all the destination networks = of the domain that the DOTS client ‘belongs’ to.  That = said, it would be good to always have the destination network in an ACL = as it can be validated and cross-checked whenever the legitimate set of = domain protected IPs are updated.

[Jon] However, what = happens to the Destination network in the case of a call home DOTS = client that becomes a quasi DOTS server and the Destination networks are = somewhere out on the Internet?

 

[TR] DDOS is a targeted attack, so = the DOTS client can specify the destination network targeted by devices = in the DOTS server domain and the DOTS server can validate if the = destination network is indeed targeted by its = devices.

 

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of mohamed.....boucadair@orange= .com
Sent: Tuesday, March 27, 2018 1:09 PM
To: = Jon Shallow <supjps-ietf@jpshallow.com&g= t;; dots@ietf.org
Subject: Re: = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

Hi Jon,

 

Thank you for the comments.

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] = De la part de Jon Shallow
Envoy=E9 : lundi 26 mars = 2018 14:23
=C0 : dots@ietf.org
Objet : = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

Hi = there,

 

As per Med’s presentation to the IETF = 101

 

Issue #4: Per-Domain or Per-client = Filters?

 

• Conclusion

– Filters that are activated only during = mitigation time are on a per-client basis

   • Filters are per-domain when are = immediately applied

 

“Filters are per-domain when are immediately = applied” is what I have an challenge with.

 

If we have a = compromised or rogue DOTS client, the simple use of something like curl, = along with the client certificates etc. can be used to generate any ACL = with activation-type :=3D ‘immediate’ which is then = immediately applied for all traffic within the domain as per the = above.

 

[Med] = Yes. FWIW, this attack is called out in the security considerations = section:

 

“Nevertheless, =
an

   attacker who can access a = DOTS client is technically capable of

   launching various attacks, = such as:

 

..;

 

   o  Set invalid ACL entries, which may =
prevent legitimate traffic from
      being forwarded.  =
Likewise, invalid ACL entries may lead =
to
      forward DDoS traffic.

“

[Jon] Agreed that the = attack is covered off in the Security section, but we should be limiting = the possibility / scope of the attack vector by enforcing some rules as = to what is / is not allowed.  Allowing a DOTS client to be able to = affect all the traffic within the domain is a huge risk to me and should = not be allowed.

 

So, a ACL = that blacklists the DNS server, or drops all port 443 traffic etc. can = easily cause all of the other clients / devices within the domain to be = taken off air.  Putting the intelligence into the DOTS server to = not allow this to happen could be a challenge.

[The signal channel is much harder to compromise and = affect traffic flows to other areas within the domain]

 

I believe = that an ACL instantiated by a DOTS client (immediate or when-mitigating) = should only apply to the DOTS client’s traffic which means that = the destination-network has to be a part of the ACL, whether implicitly = added by the DOTS server, or by the DOTS client and suitably = validated.

 

[Med] = Putting aside that I don’t parse “DOTS client’s = traffic”,

[Jon] I was referring to all the traffic flows = that a DOTS client can legitimately request control of to the DOTS = server that are within the scope of what the DOTS client is protecting = (which may or may not be the DOTS client’s IP = address).

I = interpret your answer as a support to this question raised for issue = #4:

    • “Should = we mandate destination-network to be present for immediately enforced = filters?”

[Jon] See response to = Tiru’s Agreement above.

~Jon

There is nothing to stop the DOTS server or DOTS = mitigator merging common ACLs to reduce the number of ACLs within the = mitigation device.

 

As a side = note “mitigation-time” is perhaps a bad name as it implies a = time period – something like “when-mitigating” to me = is clearer.

[Med] = Fixed in my local copy. Thank you.

 

Regards

 

Jon

<= /div>
------=_NextPart_000_02C4_01D3D051.9128E0A0-- From nobody Mon Apr 9 22:30:51 2018 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 A0EF212D950 for ; Mon, 9 Apr 2018 22:30:50 -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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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 kvhW-aLa0A-H for ; Mon, 9 Apr 2018 22:30:48 -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 C5B5A12751F for ; Mon, 9 Apr 2018 22:30:47 -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=1523338237; 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: dlp-product:dlp-version:dlp-reaction: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-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-Network-Message-Id: 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=CbAQl2JDldA03DevLlFaz41KFEfhOpCrU3uH+s XyePE=; b=XKqUSgxlaGNaAfGWJ1iBqXxVUEjtiInO2Cx7cHhn GTNlWkZpLhixaDLpKS97UnSpETz5UjtAEYFCr/rrVnHdN+TRh4 GDFvKaRzv46OCBjsD4y6r3ZvbUSW596tVqXg4pZFMeEzzu5ICB qpG7wAHwesMqZIWXCPWmeZsYnTjm2NY= Received: from DNVEXAPP1N04.corpzone.internalzone.com (unknown [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 5832_0987_00ed8052_b138_4c53_b011_96933021a4cd; Tue, 10 Apr 2018 00:30:36 -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; Mon, 9 Apr 2018 23:30:35 -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.1347.2 via Frontend Transport; Mon, 9 Apr 2018 23:30:36 -0600 Received: from NAM02-SN1-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.1347.2; Mon, 9 Apr 2018 23:30:30 -0600 Received: from BN6PR16MB1425.namprd16.prod.outlook.com (10.172.207.19) by BN6PR16MB0066.namprd16.prod.outlook.com (10.172.111.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.653.12; Tue, 10 Apr 2018 05:30:34 +0000 Received: from BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d]) by BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d%2]) with mapi id 15.20.0653.015; Tue, 10 Apr 2018 05:30:34 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: [Dots] Signal Channel - 300 Redirected Signaling Thread-Index: AdPMGSyCaQQbv+vLSW+0gkDbU7HOEwAAo7xAAAH7T4AAARdqYAAhoxEAAAGQiwAAAKyNYAAF3e1QACUKCFAAAZEMQAAIeXTgAARcGhAAAoG7gAABGXwAAAAjBIAAAa5ZgAAAiReAAABpmzAAL32aAABWbPEwAAIv/gAAAPiKMAAA7T0AAACbH4AAAR48IAAD29GAAAAS23AAALmWgAAAGvzwAAE21AAAEXqFAAAR0YPw Date: Tue, 10 Apr 2018 05:30:33 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93302DEFA4A0@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEFA561@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <029b01d3d042$fa319a10$ee94ce30$@jpshallow.com> In-Reply-To: <029b01d3d042$fa319a10$ee94ce30$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [122.172.69.219] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR16MB0066; 7:vof6Qw+MdkzlufnoD8wjUAjZWulyGOBJoJySu6KtKYMwHG5HpQoIDu4Xs1Hmt1WDk9uypo6Z0Hgipv3TkDSrYMJA1MNvQ2DPP4JMoCRGNS1dKoPnkncvuMLnuFAW0VOZP3/YVJQPVBDPUXju9TBHhqkBMX2u3LBOxr+SWA5aiYdzDM0zGGZ4Chf2ZZggbNlKrxGHrdAhnzw6gt5nfddUFQNeFNJsxZZlQ63HAzYqyHjHzDYZxod4AJ8QtUzrL3Ga x-ms-exchange-antispam-srfa-diagnostics: SOS; X-MS-Office365-Filtering-Correlation-Id: fd2339ed-d34c-41ab-14ab-08d59ea42ef1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BN6PR16MB0066; x-ms-traffictypediagnostic: BN6PR16MB0066: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(18271650672692)(123452027830198)(15185016700835); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231221)(944501327)(52105095)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123560045)(20161123562045)(6072148)(201708071742011); SRVR:BN6PR16MB0066; BCL:0; PCL:0; RULEID:; SRVR:BN6PR16MB0066; x-forefront-prvs: 0638FD5066 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39860400002)(376002)(39380400002)(366004)(396003)(55784002)(32952001)(199004)(189003)(13464003)(106356001)(229853002)(186003)(11346002)(14454004)(68736007)(2201001)(446003)(8676002)(2900100001)(105586002)(2501003)(7696005)(5250100002)(81156014)(97736004)(81166006)(93886005)(99286004)(53546011)(8936002)(86362001)(110136005)(316002)(80792005)(26005)(72206003)(966005)(102836004)(2906002)(25786009)(3846002)(55016002)(6116002)(305945005)(6436002)(6246003)(486006)(6506007)(7736002)(76176011)(476003)(59450400001)(478600001)(74316002)(3280700002)(33656002)(6306002)(5660300001)(53936002)(9686003)(66066001)(3660700001)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR16MB0066; H:BN6PR16MB1425.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: DVE5ANg3ais9as0+iZpx88njanYKW5YyYiMwWVDfh0nmq3OKH5dGVGZ3qi28Kx3QeHHyvWzqnhOt7pGzplw0IWajoAJiI/J47xBukL9iRkWyO/6CstILzLzYlqI+ebqouBS/i0BsLPcSyFy5kkar1/b73dXC6o4Qz0mFR36arSE6nS7gA1snYkF8Z/hnvqL6H5hI4pdZFn4qI4VS1Mio/WpuMkbKvcFsEfeLHm8r/ycfjfqrVfWs73RCaeVXhJ6BEAv1LTnn/2neppbIhpLuXls1whRn8kgUdqbT4kH/He6He0A5lcNFkmSmMmfnr2XZznHBkHKpQvNyTbH5dxkPjd5dsV4J1Q9vMIiOXVe6KaSfHk0p5YG3/N3RsfF2Rx18nRypKDE5F4AsOjendEgfkGasDUCpCvDsJBE7z06TK4I= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: fd2339ed-d34c-41ab-14ab-08d59ea42ef1 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2018 05:30:33.9927 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR16MB0066 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6260> : inlines <6554> : streams <1783591> : uri <2622920> Archived-At: Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling 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, 10 Apr 2018 05:30:51 -0000 > -----Original Message----- > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > Sent: Tuesday, April 10, 2018 2:10 AM > To: mohamed.boucadair@orange.com; Konda, Tirumaleswar Reddy > ; dots@ietf.org > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling >=20 > Hi, >=20 > See inline [Jon] >=20 > Regards >=20 > Jon >=20 > -----Original Message----- > From: mohamed.boucadair@orange.com [mailto: > mohamed.boucadair@orange.com] > Sent: 09 April 2018 13:20 > To: Konda, Tirumaleswar Reddy; Jon Shallow; dots@ietf.org > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling >=20 > Re-, >=20 > Glad to see that we both agree to get out from the DNS comparison. >=20 > [Jon] Also agree. Perhaps 'ttl' should be renamed 'alt-server-ttl'. >=20 > Please see inline. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Konda, Tirumaleswar Reddy > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > Envoy=E9=A0: lundi 9 avril 2018 13:48 > > =C0=A0: BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet=A0:= RE: > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > -----Original Message----- > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of > > > mohamed.boucadair@orange.com > > > Sent: Monday, April 9, 2018 5:12 PM > > > To: Konda, Tirumaleswar Reddy ; > > > Jon Shallow ; dots@ietf.org > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > Re-, > > > > > > Please see inline. > > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Konda, > > > > Tirumaleswar Reddy Envoy=E9=A0: lundi 9 avril 2018 13:29 =C0=A0: BO= UCADAIR > > > > Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet=A0: Re: [Dots] > > > > Signal Channel - 300 Redirected Signaling > > > > > > > > > -----Original Message----- > > > > > From: mohamed.boucadair@orange.com > > > > > [mailto:mohamed.boucadair@orange.com] > > > > > Sent: Monday, April 9, 2018 4:49 PM > > > > > To: Konda, Tirumaleswar Reddy > > > > > ; > > > > > Jon Shallow ; dots@ietf.org > > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > Re-, > > > > > > > > > > Focusing on this part of your answer: > > > > > > > > > > "No, DNS TTL lifetime does not mean existing session has to be > > > > disconnected > > > > > after the TTL expires." > > > > > > > > > > This is exactly the disconnect. We are not discussing **DNS > > > > > TTL** but the validity time of a an alternate server as provided > > > > > in a DOTS redirect > > > > signal. > > > > > > > > When the server can explicitly re-direct the client, why provide > > > > the validity time of an alternate server ? > > > > > > [Med] Involving the alternate server is one deployment mode among > others. > > > The current text allows for these two modes: > > > > > > (1) redirect upon an explicit signal > > > (2) automatic fallback upon ttl expiry > > > > > > Which one to pick is deployment-specific. > > > > > > TTL makes sense only for (2). > > > > I don't think (2) is required, HTTP does not support (2) for Temporary > > re- direct (see https://tools.ietf.org/html/rfc7285#section-8.5.3). > > >=20 > [Jon] in the general potential overloading case of a specific DOTS server= , > to redirect a DOTS client to an alternative DOTS server for a period of t= ime > makes sense to me - and then the DOTS client can then come back again. S= o, > to me, [2] is a valid option. >=20 > [Med] The comparison with 307 is not accurate because that code assumes t= he > following: >=20 > The 307 (Temporary Redirect) status code indicates that the target > resource resides temporarily under a different URI and the user agent > MUST NOT change the request method if it performs an automatic > redirection to that URI. Since the redirection can change over time, > the client ought to continue using the original effective request URI >=20 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > ^^^^ > for future requests. > ^^^^^^^^^^^^^^^^^^^ >=20 > Supplying the TTL is the only way to master the automatic fall back while > avoiding contacting the "normal" server during the "temporary redirect'. >=20 > [Jon] Agreed. If TTL expires, DOTS client cannot be re-directed when DDOS attack is activ= e. If a DOTS client does not honor the TTL value and continues to use the alte= rnate server, the server should explicitly re-direct the client and if the = client still continues to use the DOTS server, it should disconnect the (D)= TLS session.=20 -Tiru From nobody Mon Apr 9 22:43:13 2018 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 9982912D94F for ; Mon, 9 Apr 2018 22:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 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, T_DKIMWL_WL_HIGH=-0.01, 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 XKdk86igK5c8 for ; Mon, 9 Apr 2018 22:43:05 -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 322C712751F for ; Mon, 9 Apr 2018 22:43:05 -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=1523338984; 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: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-microsoft-antispam: x-ms-traffictypediagnostic:x-microsoft-antispam-prvs: x-exchange-antispam-report-test:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Office365-Filtering-Correlation-Id: X-MS-Exchange-CrossTenant-Network-Message-Id: 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=5 x0wxihI5MzKDWIco8ZRrFxdm4qxlCm2xPj4AUNssL o=; b=GvHDMXNH10uHy7XMOsccR7H2jkCqIvUILrupq8ymi+Aq wgusMVregMSzWd3dp/YAEFipqHX5XdG0D4FtWpgxucDKWoE3t6 gbq9/sc9ijYs0PbZMIXDvTsadl49oNfgRlO+knO9tz2O74EQje Iy/WxFmOMVpYGwc9sxmkgID2tNQ= Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 5812_12d4_e8488400_036e_4c56_98f3_484db33838c2; Tue, 10 Apr 2018 00:43:03 -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; Mon, 9 Apr 2018 23:43:02 -0600 Received: from DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) by DNVEXUSR1N11.corpzone.internalzone.com (10.44.48.84) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 9 Apr 2018 23:43:01 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Mon, 9 Apr 2018 23:43:01 -0600 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 9 Apr 2018 23:42:55 -0600 Received: from BN6PR16MB1425.namprd16.prod.outlook.com (10.172.207.19) by BN6PR16MB0001.namprd16.prod.outlook.com (10.172.111.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.675.9; Tue, 10 Apr 2018 05:42:58 +0000 Received: from BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d]) by BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d%2]) with mapi id 15.20.0653.015; Tue, 10 Apr 2018 05:42:57 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: [Dots] IETF 101 Presentation Data Channel Issue #4 Thread-Index: AdPE/QAkDtOD9YeqSAaov9+szxQnSQAoMdfAAAKPC+AAA+QiAAAEVj7wAfiJ0YAAA7+48AABBD0AAByNZ3AAbRM0AAABj4SQAALuHIAAAB7MkAAUhSeAABEJfQA= Date: Tue, 10 Apr 2018 05:42:57 +0000 Message-ID: References: <008401d3c4fd$216d0840$644718c0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF1067@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <014801d3c5b7$94c67f00$be537d00$@jpshallow.com> <009a01d3cdab$150b4c40$3f21e4c0$@jpshallow.com> <00cf01d3cdbe$24876650$6d9632f0$@jpshallow.com> <01fd01d3cfe4$a71b6580$f5523080$@jpshallow.com> <024901d3cff6$9d4beea0$d7e3cbe0$@jpshallow.com> <02c301d3d049$2f60cf20$8e226d60$@jpshallow.com> In-Reply-To: <02c301d3d049$2f60cf20$8e226d60$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [122.172.69.219] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR16MB0001; 7:jNvx/Z7h4oRsFptIvYpA/Ybzk9B8JVEOXZ/RaDZ/IwapcrP9Wazoatn+mRbhd6UczbhaPbH1FEqMaSXeRM9IxsVS4xQ7Bzou7HYidO6iZTu3QdiqHJthhy41vO7r7L/oyq/yQzxlo594O/ABPiHfv6CfX2NhzDY2Z2eZ6dDUuUvqbKrvBkYtS7i0y41X2AJiIBhtClp/aq3bXEJNBM3scmmd8n0OnLF/YLAzxGsvJTZf6PQ3e12DL0kOW2/XObxB x-ms-exchange-antispam-srfa-diagnostics: SOS; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BN6PR16MB0001; x-ms-traffictypediagnostic: BN6PR16MB0001: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(192374486261705)(18271650672692)(21748063052155)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231221)(944501327)(52105095)(3002001)(10201501046)(93006095)(93001095)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(20161123560045)(20161123558120)(6072148)(201708071742011); SRVR:BN6PR16MB0001; BCL:0; PCL:0; RULEID:; SRVR:BN6PR16MB0001; x-forefront-prvs: 0638FD5066 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39380400002)(39860400002)(376002)(346002)(396003)(366004)(32952001)(199004)(189003)(5383002)(478600001)(5660300001)(6506007)(53546011)(26005)(59450400001)(68736007)(7736002)(102836004)(33656002)(790700001)(3846002)(6116002)(93886005)(229853002)(80792005)(66066001)(345774005)(6436002)(3280700002)(72206003)(74316002)(3660700001)(2906002)(99286004)(14454004)(8676002)(7696005)(76176011)(8936002)(97736004)(81156014)(81166006)(316002)(236005)(105586002)(106356001)(2201001)(2900100001)(5250100002)(9686003)(2501003)(25786009)(486006)(110136005)(53936002)(86362001)(6246003)(53946003)(11346002)(55016002)(19609705001)(446003)(6306002)(54896002)(476003)(186003)(91024005)(85282002)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR16MB0001; H:BN6PR16MB1425.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: BCO9QgeR80vmwwJvtTJn5XU2CR5YTON2gjlep+ESENshxJpgGU7/338aTWeoozF/kWeApWYxCTQFrFevaE1hwBQ7W1hASO82SSs07ojvFYKjHPnCm06Jyrg0dYZNcjb/q300To4NFFosHdO/NAhL42A68LjU1yjlRnxKNQFYTZ9cy96gsu65AOSytmDxJPKFzKDkDE6lWwO92wjrmeALH0CqUVVYXZn/GorFhVVzWGlkdWkdX+H5e/xgl74qUDAbN8FBELIX8SKKBrLgfk0O9kzuSACl/JzbGfuPT9KfXMos7vpXWFSdcINio/7F2YL3vvuhgIVQ0MQis72u+RFbMCrGAwvWzmJ7ngnw2golyUdrGBJyaQz+SuQsdPnL951L3lIijGETbQZMBQ5IhHb6ffGliBU++ATUCFY+M2Typ1Q= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR16MB142574680C8B83B5FDD71A47EABE0BN6PR16MB1425namp_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: bc4f9fb2-2418-4bfd-ab93-08d59ea5ea41 X-MS-Exchange-CrossTenant-Network-Message-Id: bc4f9fb2-2418-4bfd-ab93-08d59ea5ea41 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2018 05:42:57.8637 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR16MB0001 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 <6260> : inlines <6554> : streams <1783592> : uri <2622926> Archived-At: Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 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, 10 Apr 2018 05:43:12 -0000 --_000_BN6PR16MB142574680C8B83B5FDD71A47EABE0BN6PR16MB1425namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Please see inline [TR3] From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Tuesday, April 10, 2018 2:55 AM To: Konda, Tirumaleswar Reddy ; mohamed= .boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 Hi Tiru, See inline [Jon2] Regards Jon From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Monday, April 9, 2018 2:55 PM To: Konda, Tirumaleswar Reddy >; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 Hi Tiru, If a DOTS client knows the full scope of the Networks that it is allowed to= use in a ACL or mitigate request, and the DOTS server limits any update fr= om that client to the scope of Networks (with any unexpected side effects t= hat may have), then there is no difference in my mind as to whether the DOT= S clients fills in the destination-network, or the DOTS server does so on t= he DOTS client's behalf before ACL instantiation if destination-network is = not defined. [TR] The above model only works when the DOTS server and DOTS client are di= rectly communicating with each other (In the above, the DOTS server knows t= he DOTS client identity to enforce the scope but will not the DOTS client i= dentity in the presence of a client-domain DOTS gateway). [Jon1] The last para of "10. Security Considerations" states DOTS servers MUST verify that requesting DOTS clients are entitled to trigger actions on a given IP prefix. That is, only actions on IP resources that belong to the DOTS client' domain MUST be authorized by a DOTS server. The exact mechanism for the DOTS servers to validate that the target prefixes are within the scope of the DOTS client's domain is deployment-specific. [Jon1] So it makes no difference if the DOTS client happens to be an agent = part of a client-domain DOTS gateway. If the client-domain DOTS gateway is= hiding all the 'behind' clients and presenting as single client, there is = no issue. However, if the 'behind' clients are presented as 2 or more 'cui= d's by the DOTS gateway, then either the scope is per 'cuid', or if 'cdid's= are being applied by the upstream server domain DOTS gateway then on a per= 'cdid' basis if wanted. For a client behind a client domain DOTS gateway, there may be non public I= P addresses that the (DMS) client is responsible for, but these should neve= r be sent out through the DOTS gateway (and should be rejected by the DOTS = server as out of scope). There does have to be a common agreement between = DOTS client & DOTS server as to what Networks are in scope, but the DOTS cl= ient currently cannot request this from the DOTS server and has to be agree= d out of band. [TR] I don't see a new problem, even when a DOTS client sends a mitigation = request it needs to know if the targets conveyed in the mitigation request = are in its scope or not. [Jon1] but again, the DOTS server MUST verify the IP prefix is valid, so ha= s to know scope. I agree that the DOTS client (or client domain DOTS gatew= ay) needs to know (today out of band) what is the scope of what is valid to= request. The challenge comes when the DOTS server's scope is reconfigured= , but not yet updated on the DOTS client. [TR2] The scope would be first updated on the DOTS client domain and then o= n the DOTS server (e.g. IP prefix re-numbering). [Jon2] I was more thinking of a DOTS client that got missed off a list when= the DOTS server was updated. Normally though, they should be kept in sync= but which one gets updated first is uncertain to me. [TR3] If the DOTS client missed update, it will have various other problems= ; any network policy based on destination network IP/prefix will fail. DOTS= client should support mechanisms to receive the latest network configurati= on after missing critical updates because it was offline or its connectivity was lost. There is no reason as to why the DOTS server cannot maintain a valid scope = of Networks that the client domain DOTS gateway is allowed to request for v= alidity checking - unless I am missing something? [TR] You are partially right, the DOTS server does not know the valid scope= of prefixes that a DOTS client behind client-domain DOTS gateway is allowe= d to request. [Jon1] Again, the last para of 10. stands here, and so the scope has to be = known by the DOTS server. [TR] Yes, but it may not know the scope of a DOTS client behind a client-do= main DOTS gateway. [Jon2] But it will know what the client-domain DOTS gateway is allowed to p= ass through in terms of Destination Network. The client-domain DOTS gatewa= y will separately need to know what Destination networks are allowed to get= out through the gateway. Troubleshooting has kept me in a job for more years than I care to remember= , anything to aid troubleshooting is what I am interested in and so totally= agree that rogue DOTS client's capabilities need to be kept under control = with suitable logging to aid diagnosis is a major plus. However in this ca= se, the implicit rule is no different to the DOTS client requesting the ful= l Networks scope in an ACL request. [TR] If the client is not authorized to request the full network scope, it = can detected by the client-domain DOTS gateway and rejects the filtering ru= le by comparing the destination-networks specified in the ACE. [Jon1] Agreed, it is the responsibility of the client domain DOTS gateway t= o only allow out valid networks that are valid within the DOTS server's sco= pe. [Jon1] Should we support a way for the client domain DOTS gateway (i.e. DO= TS client agent) to programmatically get the current valid network scope fr= om the DOTS server? [TR2] It will not solve the above problem of detecting and rejecting a roug= e (or misconfigured) DOTS client behind client domain DOTS gateway sending = ACL without specifying destination-network. [Jon2] Hmm. If the client-domain DOTS gateway is restricted in scope as to= what it is allowed to request, and a rogue client behind the gateway does = not specify a destination-network, then when the request passes through the= gateway the upstream DOTS server will only use the scope allowed for that = specific client-domain DOTS gateway. Again, it is exactly the same as if t= he rogue client was to specify the full set of allowed scope as a set of de= stination networks in terms of damage capabilities. [TR3] No, the client-domain DOTS gateway can detect and reject the ACL beca= use the rouge DOTS client has specified destination-network not under its s= cope. -Tiru ~jon1 -Tiru Regards Jon From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Konda@mcafee.com= ] Sent: 07 April 2018 06:48 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 Hi Jon, DOTS clients (intelligent DDoS mitigation system, application server) will = know the destination networks, what kind of DOTS clients will not know the = destination networks they are allowed to use ? DOTS clients could be behind client-domain DOTS gateway, DOTS server will h= ave no way to validate the DOTS client identity sending the ACE request to = determine the destination IP addresses in its scope, it will only know the = destination IP addresses in the DOTS client domain scope. Further, the implicit rule can be misused by compromised DOTS clients (e.g.= black-list good traffic to the entire DOTS client domain) and it's a trou= bleshooting nightmare to find the culprit device adversely impacting the en= tire network. Cheers, -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Friday, April 6, 2018 9:14 PM To: Konda, Tirumaleswar Reddy >; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 Hi Tiru, The DOTS server is likely to have a scope of IP addresses that are valid fo= r the client to ask for protection for based on the cuid or cdid. The DOTS client may have some knowledge of the scope IPs by some out of ban= d method, but programmatically cannot ask the server what they are. If a client specifies a destination network that is out of the valid scope = of IP addresses, then the ACE request will get rejected. The client may th= en have a challenge to work out what destination networks it is allowed to = use. How does a client set up a blacklist for all the IPS within his allowed sco= pe if it does not know what the scope is? If the client has not provided a destination network, then the DOTS server = can auto-fill in the missing information at the time of the ACE instantiati= on - and this then handles if the scope of IP addresses change. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 06 April 2018 16:19 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 I don't understand how the DOTS server/mitigation will fill it in at time o= f ACE instantiation, and why can't the DOTS client fill the destination net= work details ? -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Friday, April 6, 2018 6:58 PM To: Konda, Tirumaleswar Reddy >; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 Hi there, There is no current way to request of a DOTS Server as to what is the set o= f IP networks that a DOTS client can use either within a mitigation request= or to set up an ACL other than by "testing for ok or not ok" with lots of = different IP addresses. There is a reasonable likelihood of the scope of valid IPs from the Server'= s perspective will change over time. So, unless a DOTS client wants to con= trol a specific destination network, then my suggestion would be to leave t= he ACE destination network empty and for the DOTS Server / DOTS mitigator (= how is out of scope) to fill it in at time of ACE instantiation. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 27 March 2018 13:49 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 Please see inline [TR] From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Tuesday, March 27, 2018 4:07 PM To: Konda, Tirumaleswar Reddy >; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 Hi Tiru / Med See inline [Jon] Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 27 March 2018 09:47 To: mohamed.boucadair@orange.com; Jon = Shallow; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 I also support to mandate destination-network for immediately enforced filt= ering rules. [Jon] This can be enforced / inserted by the DOTS Server for all the destin= ation networks of the domain that the DOTS client 'belongs' to. That said,= it would be good to always have the destination network in an ACL as it ca= n be validated and cross-checked whenever the legitimate set of domain prot= ected IPs are updated. [Jon] However, what happens to the Destination network in the case of a cal= l home DOTS client that becomes a quasi DOTS server and the Destination net= works are somewhere out on the Internet? [TR] DDOS is a targeted attack, so the DOTS client can specify the destinat= ion network targeted by devices in the DOTS server domain and the DOTS serv= er can validate if the destination network is indeed targeted by its device= s. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.....boucadai= r@orange.com Sent: Tuesday, March 27, 2018 1:09 PM To: Jon Shallow >; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 Hi Jon, Thank you for the comments. Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : lundi 26 mars 2018 14:23 =C0 : dots@ietf.org Objet : [Dots] IETF 101 Presentation Data Channel Issue #4 Hi there, As per Med's presentation to the IETF 101 Issue #4: Per-Domain or Per-client Filters? * Conclusion - Filters that are activated only during mitigation time are on a per-clien= t basis * Filters are per-domain when are immediately applied "Filters are per-domain when are immediately applied" is what I have an cha= llenge with. If we have a compromised or rogue DOTS client, the simple use of something = like curl, along with the client certificates etc. can be used to generate = any ACL with activation-type :=3D 'immediate' which is then immediately app= lied for all traffic within the domain as per the above. [Med] Yes. FWIW, this attack is called out in the security considerations s= ection: "Nevertheless, an attacker who can access a DOTS client is technically capable of launching various attacks, such as: ..; o Set invalid ACL entries, which may prevent legitimate traffic from being forwarded. Likewise, invalid ACL entries may lead to forward DDoS traffic. " [Jon] Agreed that the attack is covered off in the Security section, but we= should be limiting the possibility / scope of the attack vector by enforci= ng some rules as to what is / is not allowed. Allowing a DOTS client to be= able to affect all the traffic within the domain is a huge risk to me and = should not be allowed. So, a ACL that blacklists the DNS server, or drops all port 443 traffic etc= . can easily cause all of the other clients / devices within the domain to = be taken off air. Putting the intelligence into the DOTS server to not all= ow this to happen could be a challenge. [The signal channel is much harder to compromise and affect traffic flows t= o other areas within the domain] I believe that an ACL instantiated by a DOTS client (immediate or when-miti= gating) should only apply to the DOTS client's traffic which means that the= destination-network has to be a part of the ACL, whether implicitly added = by the DOTS server, or by the DOTS client and suitably validated. [Med] Putting aside that I don't parse "DOTS client's traffic", [Jon] I was referring to all the traffic flows that a DOTS client can legit= imately request control of to the DOTS server that are within the scope of = what the DOTS client is protecting (which may or may not be the DOTS client= 's IP address). I interpret your answer as a support to this question raised for issue #4: * "Should we mandate destination-network to be present for immediate= ly enforced filters?" [Jon] See response to Tiru's Agreement above. ~Jon There is nothing to stop the DOTS server or DOTS mitigator merging common A= CLs to reduce the number of ACLs within the mitigation device. As a side note "mitigation-time" is perhaps a bad name as it implies a time= period - something like "when-mitigating" to me is clearer. [Med] Fixed in my local copy. Thank you. Regards Jon --_000_BN6PR16MB142574680C8B83B5FDD71A47EABE0BN6PR16MB1425namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Please se= e inline [TR3]

 

From:<= /span> Jon Shallow [mailto:s= upjps-ietf@jpshallow.com]
Sent: Tuesday, April 10, 2018 2:55 AM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; mohamed.boucadair@orange.com; dots@ietf.org
Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Hi Tiru= ,

&n= bsp;

See inl= ine [Jon2]

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

&nbs= p;

From:<= /span> Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Monday, April 9, 2018 2:55 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; mohamed.boucadair@orange.co= m; dots@ietf.org
Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Hi Tiru= ,

&n= bsp;

If a DO= TS client knows the full scope of the Networks that it is allowed to use in= a ACL or mitigate request, and the DOTS server limits any update from that= client to the scope of Networks (with any unexpected side effects that may have), then there is no difference in= my mind as to whether the DOTS clients fills in the destination-network, o= r the DOTS server does so on the DOTS client’s behalf before ACL inst= antiation if destination-network is not defined.

 

[TR] The above model only works= when the DOTS server and DOTS client are directly communicating with each = other (In the above, the DOTS server knows the DOTS client identity to enfo= rce the scope but will not the DOTS client identity in the presence of a client-domain DOTS gateway).

&n= bsp;

[Jon1] = The last para of “10. Security Considerations” states

   DOTS servers MUST verify that requesting= DOTS clients are entitled to

   trigger actions on a given IP prefix.&nb= sp; That is, only actions on IP

   resources that belong to the DOTS client= ' domain MUST be authorized

   by a DOTS server.  The exact mechan= ism for the DOTS servers to

   validate that the target prefixes are wi= thin the scope of the DOTS

 &= nbsp; client's domain is deployment-specific.

 

[Jon1] = So it makes no difference if the DOTS client happens to be an agent part of= a client-domain DOTS gateway.  If the client-domain DOTS gateway is h= iding all the ‘behind’ clients and presenting as single client, there is no issue.  However, if the ‘behind&#= 8217; clients are presented as 2 or more ‘cuid’s by the DOTS ga= teway, then either the scope is per ‘cuid’, or if ‘cdid&#= 8217;s are being applied by the upstream server domain DOTS gateway then on= a per ‘cdid’ basis if wanted.

&n= bsp;

For a c= lient behind a client domain DOTS gateway, there may be non public IP addre= sses that the (DMS) client is responsible for, but these should never be se= nt out through the DOTS gateway (and should be rejected by the DOTS server as out of scope).  There does have to = be a common agreement between DOTS client & DOTS server as to what Netw= orks are in scope, but the DOTS client currently cannot request this from t= he DOTS server and has to be agreed out of band.

 

[TR] I don’t see a new pr= oblem, even when a DOTS client sends a mitigation request it needs to know = if the targets conveyed in the mitigation request are in its scope or not.<= o:p>

&n= bsp;

[Jon1] = but again, the DOTS server MUST verify the IP prefix is valid, so has to kn= ow scope.  I agree that the DOTS client (or client domain DOTS gateway= ) needs to know (today out of band) what is the scope of what is valid to request.  The challenge comes when the = DOTS server’s scope is reconfigured, but not yet updated on the DOTS = client. 

 

[TR2] The scope would be first = updated on the DOTS client domain and then on the DOTS server (e.g. IP pref= ix re-numbering).

&n= bsp;

[Jon2] = I was more thinking of a DOTS client that got missed off a list when the DO= TS server was updated.  Normally though, they should be kept in sync b= ut which one gets updated first is uncertain to me.

 

[TR3] If the DOTS client missed= update, it will have various other problems; any network policy based on d= estination network IP/prefix will fail. DOTS client should support mechanis= ms to receive the latest network configuration after missing critical updates because it was offline or its

     &= nbsp;    connectivity was lost.

 

There i= s no reason as to why the DOTS server cannot maintain a valid scope of Netw= orks that the client domain DOTS gateway is allowed to request for validity= checking – unless I am missing something?

 

[TR] You are partially right, t= he DOTS server does not know the valid scope of prefixes that a DOTS client= behind client-domain DOTS gateway is allowed to request.=

&n= bsp;

[Jon1] = Again, the last para of 10. stands here, and so the scope has to be known b= y the DOTS server.

 

[TR] Yes, but it may not know t= he scope of a DOTS client behind a client-domain DOTS gateway.

&n= bsp;

[Jon2] = But it will know what the client-domain DOTS gateway is allowed to pass thr= ough in terms of Destination Network.  The client-domain DOTS gateway = will separately need to know what Destination networks are allowed to get out through the gateway.

&n= bsp;

Trouble= shooting has kept me in a job for more years than I care to remember, anyth= ing to aid troubleshooting is what I am interested in and so totally agree = that rogue DOTS client’s capabilities need to be kept under control with suitable logging to aid diagnosis is a = major plus.  However in this case, the implicit rule is no different t= o the DOTS client requesting the full Networks scope in an ACL request.

 

[TR] If the client is not autho= rized to request the full network scope, it can detected by the client-doma= in DOTS gateway and rejects the filtering rule by comparing the destination= -networks

     &= nbsp;  specified in the ACE.

[Jon1] = Agreed, it is the responsibility of the client domain DOTS gateway to only = allow out valid networks that are valid within the DOTS server’s scop= e.

&n= bsp;

[Jon1] = Should we support a way for the client domain DOTS gateway  (i.e. DOTS= client agent) to programmatically get the current valid network scope from= the DOTS server?

 

[TR2] It will not solve the abo= ve problem of detecting and rejecting a rouge (or misconfigured) DOTS clien= t behind client domain DOTS gateway sending ACL without specifying destinat= ion-network.

&n= bsp;

[Jon2] = Hmm.  If the client-domain DOTS gateway is restricted in scope as to w= hat it is allowed to request, and a rogue client behind the gateway does no= t specify a destination-network, then when the request passes through the gateway the upstream DOTS server will only = use the scope allowed for that specific client-domain DOTS gateway.  A= gain, it is exactly the same as if the rogue client was to specify the full= set of allowed scope as a set of destination networks in terms of damage capabilities.

 

[TR3] No, the client-domain DOT= S gateway can detect and reject the ACL because the rouge DOTS client has s= pecified destination-network not under its scope.

 

-Tiru

 

~jon1

 

-Tiru

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Kon= da@mcafee.com]
Sent: 07 April 2018 06:48
To: Jon Shallow; moh= amed.boucadair@orange.com; dots@ietf.org
Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Hi Jon,

&nbs= p;

DOTS clie= nts (intelligent DDoS mitigation system, application server) will know the = destination networks, what kind of DOTS clients will not know the destinati= on networks they are allowed to use ?

DOTS clie= nts could be behind client-domain DOTS gateway, DOTS server will have no wa= y to validate the DOTS client identity sending the ACE request to determine= the destination IP addresses in its scope, it will only know the destination IP addresses in the DOTS client d= omain scope.

Further, = the implicit rule can be misused by compromised DOTS clients (e.g. black-li= st good traffic to the entire DOTS client domain) and it’s a  tr= oubleshooting nightmare to find the culprit device adversely impacting the entire network.

&nbs= p;

Cheers,

-Tiru

&nbs= p;

From:<= /span> Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Friday, April 6, 2018 9:14 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; mohamed.boucadair@orange.co= m; dots@ietf.org
Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Hi Tiru= ,

&n= bsp;

The DOT= S server is likely to have a scope of IP addresses that are valid for the c= lient to ask for protection for based on the cuid or cdid.

&n= bsp;

The DOT= S client may have some knowledge of the scope IPs by some out of band metho= d, but programmatically cannot ask the server what they are.

&n= bsp;

If a cl= ient specifies a destination network that is out of the valid scope of IP a= ddresses, then the ACE request will get rejected.  The client may then= have a challenge to work out what destination networks it is allowed to use.

&n= bsp;

How doe= s a client set up a blacklist for all the IPS within his allowed scope if i= t does not know what the scope is?

&n= bsp;

If the = client has not provided a destination network, then the DOTS server can aut= o-fill in the missing information at the time of the ACE instantiation R= 11; and this then handles if the scope of IP addresses change.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 06 April 2018 16:19
To: Jon Shallow; moh= amed.boucadair@orange.com; dots@ietf.org
Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

I donR= 17;t understand how the DOTS server/mitigation will fill it in at time of A= CE instantiation, and why can’t the DOTS client fill the destination = network details ?

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Friday, April 6, 2018 6:58 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; mohamed.boucadair@orange.co= m; dots@ietf.org
Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Hi ther= e,

&n= bsp;

There i= s no current way to request of a DOTS Server as to what is the set of IP ne= tworks that a DOTS client can use either within a mitigation request or to = set up an ACL other than by “testing for ok or not ok” with lots of different IP addresses.=

&n= bsp;

There i= s a reasonable likelihood of the scope of valid IPs from the Server’s= perspective will change over time.  So, unless a DOTS client wants to= control a specific destination network, then my suggestion would be to leave the ACE destination network empty and for the= DOTS Server / DOTS mitigator (how is out of scope) to fill it in at time o= f ACE instantiation.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 27 March 2018 13:49
To: Jon Shallow; moh= amed.boucadair@orange.com; dots@ietf.org
Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Please se= e inline [TR]

&nbs= p;

From:<= /span> Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Tuesday, March 27, 2018 4:07 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; mohamed.boucadair@orange.co= m; dots@ietf.org
Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Hi Tiru= / Med

&n= bsp;

See inl= ine [Jon]

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 27 March 2018 09:47
To: mohamed.boucadai= r@orange.com; Jon Shallow; dots@ietf.org
Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

I also su= pport to mandate destination-network for immediately enforced filtering rul= es.

[Jon] This can be enforced / inserted by the DOTS Server for all the d= estination networks of the domain that the DOTS client ‘belongs’= ; to.  That said, it would be good to always have the destination network in an ACL as it can be validated and cross-checked= whenever the legitimate set of domain protected IPs are updated.

[Jon] However, what happens to the Destination network in the case of = a call home DOTS client that becomes a quasi DOTS server and the Destinatio= n networks are somewhere out on the Internet?

&nbs= p;

[TR] DDOS= is a targeted attack, so the DOTS client can specify the destination netwo= rk targeted by devices in the DOTS server domain and the DOTS server can va= lidate if the destination network is indeed targeted by its devices.

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed= .....boucadair@orange.com
Sent: Tuesday, March 27, 2018 1:09 PM
To: Jon Shallow <sup= jps-ietf@jpshallow.com>; dots@ietf.org
Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Hi Jon,

 

Thank you for the comments.<= /p>

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow
Envoy=E9 : lundi 26 mars 2018 14:23
=C0 : dots@ietf.org
Objet : [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Hi there,

 

As per Med’s presentation= to the IETF 101

 

Issue #4: Per-Domain or Per-cli= ent Filters?

 

• Conclusion

– Filters that are activa= ted only during mitigation time are on a per-client basis=

   • Filters ar= e per-domain when are immediately applied

 

“Filters are per-domain w= hen are immediately applied” is what I have an challenge with.

 

If we have a compromised or rog= ue DOTS client, the simple use of something like curl, along with the clien= t certificates etc. can be used to generate any ACL with activation-type := =3D ‘immediate’ which is then immediately applied for all traffic within the domain as per the above.

 

[Med] Yes. FWIW, this attack is= called out in the security considerations section:

 

“Nevertheless,=
 an

   attacker who can acce= ss a DOTS client is technically capable of

   launching various att= acks, such as:

 

..;

 

   o  Set invalid ACL entries, which may prevent legiti=
mate traffic from
      being forwarded.  Likewise, invali=
d ACL entries may lead to
      forward DDoS traffic.=

“

[Jon] A= greed that the attack is covered off in the Security section, but we should= be limiting the possibility / scope of the attack vector by enforcing some= rules as to what is / is not allowed.  Allowing a DOTS client to be able to affect all the traffic within the dom= ain is a huge risk to me and should not be allowed.

 

So, a ACL that blacklists the D= NS server, or drops all port 443 traffic etc. can easily cause all of the o= ther clients / devices within the domain to be taken off air.  Putting= the intelligence into the DOTS server to not allow this to happen could be a challenge.

[The signal channel is much har= der to compromise and affect traffic flows to other areas within the domain= ]

 

I believe that an ACL instantia= ted by a DOTS client (immediate or when-mitigating) should only apply to th= e DOTS client’s traffic which means that the destination-network has = to be a part of the ACL, whether implicitly added by the DOTS server, or by the DOTS client and suitably validated.

 

[Med] Putting aside that I don&= #8217;t parse “DOTS client’s traffic”,

[Jon] I= was referring to all the traffic flows that a DOTS client can legitimately= request control of to the DOTS server that are within the scope of what th= e DOTS client is protecting (which may or may not be the DOTS client’s IP address).

I interpret your answer as a su= pport to this question raised for issue #4:

    • “Should we mandate destination-network to be present for immediately enforced filters?”

[Jon] S= ee response to Tiru’s Agreement above.

~Jon

There is nothing to stop the DO= TS server or DOTS mitigator merging common ACLs to reduce the number of ACL= s within the mitigation device.

 

As a side note “mitigatio= n-time” is perhaps a bad name as it implies a time period – som= ething like “when-mitigating” to me is clearer.

[Med] Fixed in my local copy. T= hank you.

 

Regards

 

Jon

--_000_BN6PR16MB142574680C8B83B5FDD71A47EABE0BN6PR16MB1425namp_-- From nobody Mon Apr 9 23:12:29 2018 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 2612E12D95D for ; Mon, 9 Apr 2018 23:12:28 -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, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-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 VmjY7gK2A2LU for ; Mon, 9 Apr 2018 23:12:26 -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 4A6DB120721 for ; Mon, 9 Apr 2018 23:12:26 -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=1523340745; 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: dlp-product:dlp-version:dlp-reaction: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-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: 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=n Vf5IO2XCHGBuZ1oqPNAZVZubDdMQqNrG1fIVxpZwg 8=; b=Ahw0M5rBDUvRa0Uwp4NUm9+2ASta1C03YrjxYsOmpKVD 90dTEu5OzURsZOl7nkrq56NoDZ7iNNLv9nFbRyn5po6pN/x0Nt xX624zOuEe/T22O5xbJubljWtFuB0JMAYL9j+291XEjVey0OHA x05bCDhbPm0A4vbAmyCCFAQyCBc= Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 5832_0f47_d8a5635b_12c6_462b_a204_a184e89fcb30; Tue, 10 Apr 2018 01:12:24 -0500 Received: from DNVEXUSR1N08.corpzone.internalzone.com (10.44.48.81) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 10 Apr 2018 00:10:17 -0600 Received: from DNVEXUSR1N13.corpzone.internalzone.com (10.44.48.86) by DNVEXUSR1N08.corpzone.internalzone.com (10.44.48.81) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 10 Apr 2018 00:10:16 -0600 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXUSR1N13.corpzone.internalzone.com (10.44.48.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Tue, 10 Apr 2018 00:10:16 -0600 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (10.44.176.242) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 10 Apr 2018 00:10:14 -0600 Received: from BN6PR16MB1425.namprd16.prod.outlook.com (10.172.207.19) by BN6PR16MB0068.namprd16.prod.outlook.com (10.172.111.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.675.9; Tue, 10 Apr 2018 06:10:14 +0000 Received: from BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d]) by BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d%2]) with mapi id 15.20.0653.015; Tue, 10 Apr 2018 06:10:14 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: [Dots] Data Channel ACL fragments Thread-Index: AdPMHAMfDWFlXvb3TSeAr5MVkYUzIgAA3pEAAAKPJoAAIuTfcAADWaQAAADopUAAyEgtgAACNjegABYTlwAAEYzK0A== Date: Tue, 10 Apr 2018 06:10:14 +0000 Message-ID: References: <016401d3cc1c$03321200$09963600$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7F97@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <01a701d3cc29$ba915b10$2fb41130$@jpshallow.com> <007501d3ccc2$b49f0b00$1ddd2100$@jpshallow.com> <021301d3cfe7$77e5cbe0$67b163a0$@jpshallow.com> <02b001d3d048$a2c68be0$e853a3a0$@jpshallow.com> In-Reply-To: <02b001d3d048$a2c68be0$e853a3a0$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [122.172.69.219] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR16MB0068; 7:aPMfJgTXY2s4QS2PWvH0Iq9VUZ89vWrcJBAU/37wLnsHIzOE9HMZ3vh74Gh5tBMl/1aTNQI520RFouGgybQQtTOBWhgaL/QeiXz29bZeJzYzb4lrAzAbZytFCWZ59V4Rd5CnwxrvN01vM6niEQU/7IfhzlVZZjMKAiM/qpN5lwkw3B9chTYXzjLMF6q58tL+FK6I6hsdQFudwhApR97Xx+KVuhhTQTAut/9O38HsKWvbKuEF1FWTt1Vef9eJF0y5 x-ms-exchange-antispam-srfa-diagnostics: SOS; X-MS-Office365-Filtering-Correlation-Id: db7ed241-a621-49f5-b3e5-08d59ea9b99c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BN6PR16MB0068; x-ms-traffictypediagnostic: BN6PR16MB0068: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231221)(944501327)(52105095)(10201501046)(93006095)(93001095)(3002001)(6041310)(20161123558120)(20161123560045)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:BN6PR16MB0068; BCL:0; PCL:0; RULEID:; SRVR:BN6PR16MB0068; x-forefront-prvs: 0638FD5066 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(39380400002)(346002)(366004)(376002)(199004)(189003)(32952001)(25786009)(6246003)(2501003)(5250100002)(97736004)(53936002)(9686003)(54896002)(6306002)(80792005)(478600001)(66066001)(2900100001)(7736002)(72206003)(55016002)(3660700001)(2201001)(33656002)(86362001)(3280700002)(229853002)(74316002)(6436002)(2906002)(5660300001)(68736007)(93886005)(790700001)(99286004)(26005)(6116002)(7696005)(3846002)(102836004)(486006)(76176011)(186003)(6506007)(14454004)(105586002)(8936002)(8676002)(81166006)(81156014)(446003)(476003)(11346002)(110136005)(316002)(106356001)(19609705001)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR16MB0068; H:BN6PR16MB1425.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: gigPP+BmsodqU61nneoK62gQihpT9dLy/eEFW/831dyoQKNkSRqcYQKKGYY9yhBsTfDeE09EWJOojGUsDZ3MIRPosLMSLAjcUMdpEQHlbFW7V5TTQ4riddDRsXfLOkwySTWox3xt+4IvQ6gXqo6IKurgVv4AvrGCtyf3MOnYPnfuPNFGTt6F5aPhUk6gAXg30Z4iT56I+gAUrc9PSFH1p39KikGj6Aur0n6uo4FBZbxo8/9Nfh1jaba6BLZC71z6htOfFHiuG5XXzhwxs3W7Xvjjf5I6DPpomdiFOM3tMYxLdrMq8e962zgi8ymznXP3TK/sjARGGWkQdf41V2hJiB7Bi/6DjjMmRRmAfVMvFIpMzksmLTm+tBn8Gdf9rEN9pL+Id1aKyPJTnYiiD6T8Ct4gNoyg1lXzuGzCnx57c8o= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR16MB1425D028388461917E44A9F4EABE0BN6PR16MB1425namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: db7ed241-a621-49f5-b3e5-08d59ea9b99c X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2018 06:10:14.3099 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR16MB0068 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 <6260> : inlines <6554> : streams <1783594> : uri <2622938> Archived-At: Subject: Re: [Dots] Data Channel ACL fragments 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, 10 Apr 2018 06:12:28 -0000 --_000_BN6PR16MB1425D028388461917E44A9F4EABE0BN6PR16MB1425namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [Jon2] The "flags->fragment" definition is ambiguous for an ACE (but valid = as to whether to allow a packet to get fragmented or not - is that really a= ACE?) which I would like to use. [TR] I don't get it. What purpose does it serve to create a ACE rule using = "fragment" bit ? "Flags->more" definition covers all fragments but the last fragment. "Offse= t" is unfortunately not a range, but otherwise would get used for the final= fragment. ~jon2 [TR] It looks like two ACE entries are required to drop all the fragments (= "flags->more" set to 1 in the first ACE and "flags->more" set to 0 in the s= econd ACE). How to use the "Offset" field for the final fragment ? -Tiru --_000_BN6PR16MB1425D028388461917E44A9F4EABE0BN6PR16MB1425namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

[Jon2] The “flag= s->fragment” definition is ambiguous for an ACE (but valid as to w= hether to allow a packet to get fragmented or not – is that really a = ACE?) which I would like to use. 

 

[TR] I don’t get= it. What purpose does it serve to create a ACE rule using “fragment&= #8221; bit ?

 

“Flags->more&= #8221; definition covers all fragments but the last fragment. “Offset= ” is unfortunately not a range, but otherwise would get used for the = final fragment.

~jon2

 

[TR] It looks like two= ACE entries are required to drop all the fragments (“flags->more&= #8221; set to 1 in the first ACE and “flags->more” set to 0 = in the second ACE). How to use the “Offset”  field for the= final fragment ?

 

-Tiru

--_000_BN6PR16MB1425D028388461917E44A9F4EABE0BN6PR16MB1425namp_-- From nobody Mon Apr 9 23:31:10 2018 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 5F14F1205F0 for ; Mon, 9 Apr 2018 23:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 u1bYEh-cLQ-C for ; Mon, 9 Apr 2018 23:31:06 -0700 (PDT) Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3687120454 for ; Mon, 9 Apr 2018 23:31:05 -0700 (PDT) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 599611206D6; Tue, 10 Apr 2018 08:31:04 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.17]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id 35ECB180072; Tue, 10 Apr 2018 08:31:04 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM24.corporate.adroot.infra.ftgroup ([fe80::a1e6:3e6a:1f68:5f7e%18]) with mapi id 14.03.0382.000; Tue, 10 Apr 2018 08:31:04 +0200 From: To: "Konda, Tirumaleswar Reddy" , "Jon Shallow" , "dots@ietf.org" Thread-Topic: [Dots] Signal Channel - 300 Redirected Signaling Thread-Index: AdPMGSyCaQQbv+vLSW+0gkDbU7HOEwAAo7xAAAH7T4AAARdqYAAhoxEAAAGQiwAAAKyNYAAF3e1QACUKCFAAAZEMQAAIeXTgAARcGhAAAoG7gAABGXwAAAAjBIAAAa5ZgAAAiReAAABpmzAAL32aAABWbPEwAAIv/gAAAPiKMAAA7T0AAACbH4AAAR48IAAD29GAAAAS23AAALmWgAAAGvzwAAE21AAAEXqFAAAR0YPwAAKsZsA= Date: Tue, 10 Apr 2018 06:31:02 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DEFB0C8@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93302DEFA4A0@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEFA561@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <029b01d3d042$fa319a10$ee94ce30$@jpshallow.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling 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, 10 Apr 2018 06:31:08 -0000 Hi all,=20 I think that we are converging.=20 Below a text proposal which reflects the outcome of the discussion: =3D=3D=3D=3D=3D=3D ttl: Time to live (TTL) of the alternate DOTS server, represented as an integer number of seconds. That is, the time interval that the alternate DOTS server may be cached for use by a DOTS client. A value of negative one (-1) indicates indefinite TTL. This value means that the alternate DOTS server is to be used until the alternate DOTS server redirects the traffic with another 3.00 response. If no 'ttl' is returned in a redirect response, this is equivalent to returning a 'ttl' parameter set to '-1'. If the alternate DOTS server TTL has expired, the DOTS client MUST use the DOTS server(s), that was provisioned using means discussed in Section 4.1. This fall back mechanism is triggered immediately upon expiry of the TTL except when a DDoS attack is active. Requests issued by misbehaving DOTS clients which do not honor the TTL or react to explicit re-direct messages can be rejected by DOTS servers. This is an optional attribute. =3D=3D=3D=3D=3D=3D=3D Cheers, Med > -----Message d'origine----- > De=A0: Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.c= om] > Envoy=E9=A0: mardi 10 avril 2018 07:31 > =C0=A0: Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org > Objet=A0: RE: [Dots] Signal Channel - 300 Redirected Signaling >=20 > > -----Original Message----- > > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > Sent: Tuesday, April 10, 2018 2:10 AM > > To: mohamed.boucadair@orange.com; Konda, Tirumaleswar Reddy > > ; dots@ietf.org > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > Hi, > > > > See inline [Jon] > > > > Regards > > > > Jon > > > > -----Original Message----- > > From: mohamed.boucadair@orange.com [mailto: > > mohamed.boucadair@orange.com] > > Sent: 09 April 2018 13:20 > > To: Konda, Tirumaleswar Reddy; Jon Shallow; dots@ietf.org > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > Re-, > > > > Glad to see that we both agree to get out from the DNS comparison. > > > > [Jon] Also agree. Perhaps 'ttl' should be renamed 'alt-server-ttl'. > > > > Please see inline. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: Konda, Tirumaleswar Reddy > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > Envoy=E9=A0: lundi 9 avril 2018 13:48 > > > =C0=A0: BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet= =A0: RE: > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > -----Original Message----- > > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of > > > > mohamed.boucadair@orange.com > > > > Sent: Monday, April 9, 2018 5:12 PM > > > > To: Konda, Tirumaleswar Reddy ; > > > > Jon Shallow ; dots@ietf.org > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > Re-, > > > > > > > > Please see inline. > > > > > > > > Cheers, > > > > Med > > > > > > > > > -----Message d'origine----- > > > > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Konda, > > > > > Tirumaleswar Reddy Envoy=E9=A0: lundi 9 avril 2018 13:29 =C0=A0: = BOUCADAIR > > > > > Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet=A0: Re: [Dots] > > > > > Signal Channel - 300 Redirected Signaling > > > > > > > > > > > -----Original Message----- > > > > > > From: mohamed.boucadair@orange.com > > > > > > [mailto:mohamed.boucadair@orange.com] > > > > > > Sent: Monday, April 9, 2018 4:49 PM > > > > > > To: Konda, Tirumaleswar Reddy > > > > > > ; > > > > > > Jon Shallow ; dots@ietf.org > > > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > Re-, > > > > > > > > > > > > Focusing on this part of your answer: > > > > > > > > > > > > "No, DNS TTL lifetime does not mean existing session has to be > > > > > disconnected > > > > > > after the TTL expires." > > > > > > > > > > > > This is exactly the disconnect. We are not discussing **DNS > > > > > > TTL** but the validity time of a an alternate server as provide= d > > > > > > in a DOTS redirect > > > > > signal. > > > > > > > > > > When the server can explicitly re-direct the client, why provide > > > > > the validity time of an alternate server ? > > > > > > > > [Med] Involving the alternate server is one deployment mode among > > others. > > > > The current text allows for these two modes: > > > > > > > > (1) redirect upon an explicit signal > > > > (2) automatic fallback upon ttl expiry > > > > > > > > Which one to pick is deployment-specific. > > > > > > > > TTL makes sense only for (2). > > > > > > I don't think (2) is required, HTTP does not support (2) for Temporar= y > > > re- direct (see https://tools.ietf.org/html/rfc7285#section-8.5.3). > > > > > > > [Jon] in the general potential overloading case of a specific DOTS serv= er, > > to redirect a DOTS client to an alternative DOTS server for a period of > time > > makes sense to me - and then the DOTS client can then come back again. = So, > > to me, [2] is a valid option. > > > > [Med] The comparison with 307 is not accurate because that code assumes= the > > following: > > > > The 307 (Temporary Redirect) status code indicates that the target > > resource resides temporarily under a different URI and the user agen= t > > MUST NOT change the request method if it performs an automatic > > redirection to that URI. Since the redirection can change over time= , > > the client ought to continue using the original effective request UR= I > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > ^^^^ > > for future requests. > > ^^^^^^^^^^^^^^^^^^^ > > > > Supplying the TTL is the only way to master the automatic fall back whi= le > > avoiding contacting the "normal" server during the "temporary redirect'= . > > > > [Jon] Agreed. >=20 > If TTL expires, DOTS client cannot be re-directed when DDOS attack is act= ive. > If a DOTS client does not honor the TTL value and continues to use the > alternate server, the server should explicitly re-direct the client and i= f > the client still continues to use the DOTS server, it should disconnect t= he > (D)TLS session. >=20 > -Tiru From nobody Mon Apr 9 23:46:31 2018 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 3C157120454 for ; Mon, 9 Apr 2018 23:46:30 -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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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 meD6Pj400ezx for ; Mon, 9 Apr 2018 23:46:27 -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 93B18124F57 for ; Mon, 9 Apr 2018 23:46:27 -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=1523342786; 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: dlp-product:dlp-version:dlp-reaction: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-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-Network-Message-Id: 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=DQ1uwkOwtmePE3DlQ2tSj+dMAammkKytFlNboN daEcM=; b=dt6v7ttCyNbUOfHK1QhFE3kRuHlUoikSHCd1ehOa F/2uTjZ2p6Q3k/HeZFXsyt/fdEBpYuKVJgOrTJmxU8f8SAgTh3 F56gyAmTX/LXN9WIgEtGn9kZyAMgUdLjx6U1gqS3s9lk5+ksf0 FPpgaXFp/wlOhtafu7GxHQABoVofgn8= Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 5812_22b5_49b6744a_5e02_4fb9_b313_bf9915737a6f; Tue, 10 Apr 2018 01:46:25 -0500 Received: from DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 10 Apr 2018 00:46:14 -0600 Received: from DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) by DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 10 Apr 2018 00:46:13 -0600 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Tue, 10 Apr 2018 00:46:12 -0600 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (10.44.176.241) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 10 Apr 2018 00:46:11 -0600 Received: from BN6PR16MB1425.namprd16.prod.outlook.com (10.172.207.19) by BN6PR16MB0036.namprd16.prod.outlook.com (10.172.111.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.675.9; Tue, 10 Apr 2018 06:46:10 +0000 Received: from BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d]) by BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d%2]) with mapi id 15.20.0653.015; Tue, 10 Apr 2018 06:46:10 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Signal Channel - 300 Redirected Signaling Thread-Index: AdPMGSyCaQQbv+vLSW+0gkDbU7HOEwAAo7xAAAH7T4AAARdqYAAhoxEAAAGQiwAAAKyNYAAF3e1QACUKCFAAAZEMQAAIeXTgAARcGhAAAoG7gAABGXwAAAAjBIAAAa5ZgAAAiReAAABpmzAAL32aAABWbPEwAAIv/gAAAPiKMAAA7T0AAACbH4AAAR48IAAD29GAAAAS23AAALmWgAAAGvzwAAE21AAAEXqFAAAR0YPwAAKsZsAAAI9wIA== Date: Tue, 10 Apr 2018 06:46:10 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93302DEFA4A0@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEFA561@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <029b01d3d042$fa319a10$ee94ce30$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEFB0C8@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DEFB0C8@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [185.221.69.46] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR16MB0036; 7:DdeirhJEpkZT03tGTwTsGJWzLGRjdo/FFMlOMN/1E8pT/7I5+DxEhV+bDkBTA98D/Vl0OX5oVZelEbxIX9poVYGui2K3rsaO9oAwk+OpI4yqUN7Jp6RyLWRAGjoX+Op4GrC/I0esEUiteJP1VKyV+OWUh7ejiBEOoW0AsDeu4J2agokmHYhSH9xvcsUvaugGD6evbU9LXSwm/pytpam+EIUUDQYL8Jy+QzrACIGA8fDhZVU/vhGOiceeFhg2kkbY x-ms-exchange-antispam-srfa-diagnostics: SOS; X-MS-Office365-Filtering-Correlation-Id: a9e1f4b5-b545-4e66-469e-08d59eaebec8 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BN6PR16MB0036; x-ms-traffictypediagnostic: BN6PR16MB0036: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(15185016700835)(18271650672692)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(3231221)(944501327)(52105095)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(20161123560045)(20161123558120)(6072148)(201708071742011); SRVR:BN6PR16MB0036; BCL:0; PCL:0; RULEID:; SRVR:BN6PR16MB0036; x-forefront-prvs: 0638FD5066 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39380400002)(396003)(39860400002)(376002)(346002)(55784002)(53754006)(199004)(189003)(13464003)(32952001)(51444003)(305945005)(99286004)(7696005)(53936002)(93886005)(2501003)(53546011)(6506007)(6246003)(25786009)(316002)(106356001)(76176011)(105586002)(186003)(59450400001)(2900100001)(229853002)(81166006)(8676002)(81156014)(6436002)(8936002)(5660300001)(74316002)(7736002)(68736007)(80792005)(6306002)(9686003)(97736004)(55016002)(66066001)(5250100002)(72206003)(3280700002)(33656002)(561944003)(486006)(446003)(3660700001)(478600001)(102836004)(966005)(476003)(26005)(86362001)(110136005)(11346002)(14454004)(6116002)(3846002)(2906002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR16MB0036; H:BN6PR16MB1425.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 5Zk/k4Q4ppxMCe0bD3bjMJJnh85CDOAFz8xl5wFYJYT0Lh5qmWAH82jTtTAO4ipQKnBVh7edeB8PWgYG6aise8TkLUEUj0upUbmgLPOaP/e3n98OS1YP2a3QZj3nIhm26NF+4TkjIfCquEZeC7nTiLa/0O6Ay52dvruexA5itW0J3FP3UCADOAZgGXjkZjAXYpMx5lnWWvWvwA+PZBjQRTbdoIcqUe9sTIgJQ41scEisapG9BdXxtqKgy82Ll+tYl1pMVqb5tFkKG2YTenTLWzRpzHK/rQA2f0qGQ/aKpp8iT2E3z8oVd95DP3Jbg/xh8CBNkl2q/CFejPI5SgEBOHdpTy3J1OGcUhsv/j5dMVSt5VczgIgv329txG+TIPzYifFTvYsvYtf7ztqjMHt7jUXXN7UtSDs55AKYBtY5hy4= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: a9e1f4b5-b545-4e66-469e-08d59eaebec8 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2018 06:46:10.2765 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR16MB0036 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6260> : inlines <6554> : streams <1783596> : uri <2622953> Archived-At: Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling 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, 10 Apr 2018 06:46:30 -0000 > -----Original Message----- > From: mohamed.boucadair@orange.com > [mailto:mohamed.boucadair@orange.com] > Sent: Tuesday, April 10, 2018 12:01 PM > To: Konda, Tirumaleswar Reddy ; > Jon Shallow ; dots@ietf.org > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling >=20 > Hi all, >=20 > I think that we are converging. >=20 > Below a text proposal which reflects the outcome of the discussion: >=20 > =3D=3D=3D=3D=3D=3D > ttl: Time to live (TTL) of the alternate DOTS server, represented as > an integer number of seconds. That is, the time interval that the > alternate DOTS server may be cached for use by a DOTS client. >=20 > A value of negative one (-1) indicates indefinite TTL. This value > means that the alternate DOTS server is to be used until the > alternate DOTS server redirects the traffic with another 3.00 > response. >=20 > If no 'ttl' is returned in a redirect response, this is equivalent > to returning a 'ttl' parameter set to '-1'. >=20 > If the alternate DOTS server TTL has expired, the DOTS client MUST > use the DOTS server(s), that was provisioned using means discussed > in Section 4.1. This fall back mechanism is triggered immediately > upon expiry of the TTL except when a DDoS attack is active. >=20 > Requests issued by misbehaving DOTS clients which do not honor the > TTL or react to explicit re-direct messages can be rejected by > DOTS servers. >=20 > This is an optional attribute. Looks good. We may also want to say that 0 or too small value for ttl shoul= d be avoided. -Tiru > =3D=3D=3D=3D=3D=3D=3D >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Konda, Tirumaleswar Reddy > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > Envoy=E9=A0: mardi 10 avril 2018 07:31 > > =C0=A0: Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet=A0:= RE: > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > -----Original Message----- > > > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > Sent: Tuesday, April 10, 2018 2:10 AM > > > To: mohamed.boucadair@orange.com; Konda, Tirumaleswar Reddy > > > ; dots@ietf.org > > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > Hi, > > > > > > See inline [Jon] > > > > > > Regards > > > > > > Jon > > > > > > -----Original Message----- > > > From: mohamed.boucadair@orange.com [mailto: > > > mohamed.boucadair@orange.com] > > > Sent: 09 April 2018 13:20 > > > To: Konda, Tirumaleswar Reddy; Jon Shallow; dots@ietf.org > > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > Re-, > > > > > > Glad to see that we both agree to get out from the DNS comparison. > > > > > > [Jon] Also agree. Perhaps 'ttl' should be renamed 'alt-server-ttl'. > > > > > > Please see inline. > > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De=A0: Konda, Tirumaleswar Reddy > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > Envoy=E9=A0: lundi 9 avril 2018 13:48 > > > > =C0=A0: BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet= =A0: RE: > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > -----Original Message----- > > > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of > > > > > mohamed.boucadair@orange.com > > > > > Sent: Monday, April 9, 2018 5:12 PM > > > > > To: Konda, Tirumaleswar Reddy > > > > > ; > > > > > Jon Shallow ; dots@ietf.org > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > Re-, > > > > > > > > > > Please see inline. > > > > > > > > > > Cheers, > > > > > Med > > > > > > > > > > > -----Message d'origine----- > > > > > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Konda, > > > > > > Tirumaleswar Reddy Envoy=E9=A0: lundi 9 avril 2018 13:29 =C0=A0= : > > > > > > BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet=A0: > > > > > > Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: mohamed.boucadair@orange.com > > > > > > > [mailto:mohamed.boucadair@orange.com] > > > > > > > Sent: Monday, April 9, 2018 4:49 PM > > > > > > > To: Konda, Tirumaleswar Reddy > > > > > > > ; > > > > > > > Jon Shallow ; dots@ietf.org > > > > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected > > > > > > > Signaling > > > > > > > > > > > > > > Re-, > > > > > > > > > > > > > > Focusing on this part of your answer: > > > > > > > > > > > > > > "No, DNS TTL lifetime does not mean existing session has to > > > > > > > be > > > > > > disconnected > > > > > > > after the TTL expires." > > > > > > > > > > > > > > This is exactly the disconnect. We are not discussing **DNS > > > > > > > TTL** but the validity time of a an alternate server as > > > > > > > provided in a DOTS redirect > > > > > > signal. > > > > > > > > > > > > When the server can explicitly re-direct the client, why > > > > > > provide the validity time of an alternate server ? > > > > > > > > > > [Med] Involving the alternate server is one deployment mode > > > > > among > > > others. > > > > > The current text allows for these two modes: > > > > > > > > > > (1) redirect upon an explicit signal > > > > > (2) automatic fallback upon ttl expiry > > > > > > > > > > Which one to pick is deployment-specific. > > > > > > > > > > TTL makes sense only for (2). > > > > > > > > I don't think (2) is required, HTTP does not support (2) for > > > > Temporary > > > > re- direct (see https://tools.ietf.org/html/rfc7285#section-8.5.3). > > > > > > > > > > [Jon] in the general potential overloading case of a specific DOTS > > > server, to redirect a DOTS client to an alternative DOTS server for > > > a period of > > time > > > makes sense to me - and then the DOTS client can then come back > > > again. So, to me, [2] is a valid option. > > > > > > [Med] The comparison with 307 is not accurate because that code > > > assumes the > > > following: > > > > > > The 307 (Temporary Redirect) status code indicates that the target > > > resource resides temporarily under a different URI and the user ag= ent > > > MUST NOT change the request method if it performs an automatic > > > redirection to that URI. Since the redirection can change over ti= me, > > > the client ought to continue using the original effective request > > > URI > > > > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > ^^^^ > > > for future requests. > > > ^^^^^^^^^^^^^^^^^^^ > > > > > > Supplying the TTL is the only way to master the automatic fall back > > > while avoiding contacting the "normal" server during the "temporary > redirect'. > > > > > > [Jon] Agreed. > > > > If TTL expires, DOTS client cannot be re-directed when DDOS attack is a= ctive. > > If a DOTS client does not honor the TTL value and continues to use the > > alternate server, the server should explicitly re-direct the client > > and if the client still continues to use the DOTS server, it should > > disconnect the (D)TLS session. > > > > -Tiru From nobody Tue Apr 10 00:04:06 2018 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 DE924124F57 for ; Tue, 10 Apr 2018 00:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 UaRdHQRfDcgG for ; Tue, 10 Apr 2018 00:04:02 -0700 (PDT) Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D92BD120454 for ; Tue, 10 Apr 2018 00:04:01 -0700 (PDT) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id E2C5B406ED; Tue, 10 Apr 2018 09:03:59 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.41]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id C3DD01C0074; Tue, 10 Apr 2018 09:03:59 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM31.corporate.adroot.infra.ftgroup ([fe80::2cc9:4bac:7b7d:229d%19]) with mapi id 14.03.0382.000; Tue, 10 Apr 2018 09:03:59 +0200 From: To: "Konda, Tirumaleswar Reddy" , "Jon Shallow" , "dots@ietf.org" Thread-Topic: [Dots] Signal Channel - 300 Redirected Signaling Thread-Index: AdPMGSyCaQQbv+vLSW+0gkDbU7HOEwAAo7xAAAH7T4AAARdqYAAhoxEAAAGQiwAAAKyNYAAF3e1QACUKCFAAAZEMQAAIeXTgAARcGhAAAoG7gAABGXwAAAAjBIAAAa5ZgAAAiReAAABpmzAAL32aAABWbPEwAAIv/gAAAPiKMAAA7T0AAACbH4AAAR48IAAD29GAAAAS23AAALmWgAAAGvzwAAE21AAAEXqFAAAR0YPwAAKsZsAAAI9wIAAAfxxQ Date: Tue, 10 Apr 2018 07:03:58 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DEFB132@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93302DEFA4A0@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEFA561@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <029b01d3d042$fa319a10$ee94ce30$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEFB0C8@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling 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, 10 Apr 2018 07:04:05 -0000 Re-, The exact value to return is on the deployment side. If a server/provider d= ecides that 0 or small value is to be returned (that is, redirect applies o= nly for the ongoing request), why should the spec care about this? Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumales= war > Reddy > Envoy=E9=A0: mardi 10 avril 2018 08:46 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org > Objet=A0: Re: [Dots] Signal Channel - 300 Redirected Signaling >=20 > > -----Original Message----- > > From: mohamed.boucadair@orange.com > > [mailto:mohamed.boucadair@orange.com] > > Sent: Tuesday, April 10, 2018 12:01 PM > > To: Konda, Tirumaleswar Reddy ; > > Jon Shallow ; dots@ietf.org > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > Hi all, > > > > I think that we are converging. > > > > Below a text proposal which reflects the outcome of the discussion: > > > > =3D=3D=3D=3D=3D=3D > > ttl: Time to live (TTL) of the alternate DOTS server, represented a= s > > an integer number of seconds. That is, the time interval that th= e > > alternate DOTS server may be cached for use by a DOTS client. > > > > A value of negative one (-1) indicates indefinite TTL. This valu= e > > means that the alternate DOTS server is to be used until the > > alternate DOTS server redirects the traffic with another 3.00 > > response. > > > > If no 'ttl' is returned in a redirect response, this is equivalen= t > > to returning a 'ttl' parameter set to '-1'. > > > > If the alternate DOTS server TTL has expired, the DOTS client MUS= T > > use the DOTS server(s), that was provisioned using means discusse= d > > in Section 4.1. This fall back mechanism is triggered immediatel= y > > upon expiry of the TTL except when a DDoS attack is active. > > > > Requests issued by misbehaving DOTS clients which do not honor th= e > > TTL or react to explicit re-direct messages can be rejected by > > DOTS servers. > > > > This is an optional attribute. >=20 > Looks good. We may also want to say that 0 or too small value for ttl sho= uld > be avoided. >=20 > -Tiru >=20 > > =3D=3D=3D=3D=3D=3D=3D > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: Konda, Tirumaleswar Reddy > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > Envoy=E9=A0: mardi 10 avril 2018 07:31 > > > =C0=A0: Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet= =A0: RE: > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > -----Original Message----- > > > > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > Sent: Tuesday, April 10, 2018 2:10 AM > > > > To: mohamed.boucadair@orange.com; Konda, Tirumaleswar Reddy > > > > ; dots@ietf.org > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > Hi, > > > > > > > > See inline [Jon] > > > > > > > > Regards > > > > > > > > Jon > > > > > > > > -----Original Message----- > > > > From: mohamed.boucadair@orange.com [mailto: > > > > mohamed.boucadair@orange.com] > > > > Sent: 09 April 2018 13:20 > > > > To: Konda, Tirumaleswar Reddy; Jon Shallow; dots@ietf.org > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > Re-, > > > > > > > > Glad to see that we both agree to get out from the DNS comparison. > > > > > > > > [Jon] Also agree. Perhaps 'ttl' should be renamed 'alt-server-ttl'= . > > > > > > > > Please see inline. > > > > > > > > Cheers, > > > > Med > > > > > > > > > -----Message d'origine----- > > > > > De=A0: Konda, Tirumaleswar Reddy > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > Envoy=E9=A0: lundi 9 avril 2018 13:48 > > > > > =C0=A0: BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Obj= et=A0: RE: > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > -----Original Message----- > > > > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of > > > > > > mohamed.boucadair@orange.com > > > > > > Sent: Monday, April 9, 2018 5:12 PM > > > > > > To: Konda, Tirumaleswar Reddy > > > > > > ; > > > > > > Jon Shallow ; dots@ietf.org > > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > Re-, > > > > > > > > > > > > Please see inline. > > > > > > > > > > > > Cheers, > > > > > > Med > > > > > > > > > > > > > -----Message d'origine----- > > > > > > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Kond= a, > > > > > > > Tirumaleswar Reddy Envoy=E9=A0: lundi 9 avril 2018 13:29 =C0= =A0: > > > > > > > BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet= =A0: > > > > > > > Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: mohamed.boucadair@orange.com > > > > > > > > [mailto:mohamed.boucadair@orange.com] > > > > > > > > Sent: Monday, April 9, 2018 4:49 PM > > > > > > > > To: Konda, Tirumaleswar Reddy > > > > > > > > ; > > > > > > > > Jon Shallow ; dots@ietf.org > > > > > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected > > > > > > > > Signaling > > > > > > > > > > > > > > > > Re-, > > > > > > > > > > > > > > > > Focusing on this part of your answer: > > > > > > > > > > > > > > > > "No, DNS TTL lifetime does not mean existing session has t= o > > > > > > > > be > > > > > > > disconnected > > > > > > > > after the TTL expires." > > > > > > > > > > > > > > > > This is exactly the disconnect. We are not discussing **DNS > > > > > > > > TTL** but the validity time of a an alternate server as > > > > > > > > provided in a DOTS redirect > > > > > > > signal. > > > > > > > > > > > > > > When the server can explicitly re-direct the client, why > > > > > > > provide the validity time of an alternate server ? > > > > > > > > > > > > [Med] Involving the alternate server is one deployment mode > > > > > > among > > > > others. > > > > > > The current text allows for these two modes: > > > > > > > > > > > > (1) redirect upon an explicit signal > > > > > > (2) automatic fallback upon ttl expiry > > > > > > > > > > > > Which one to pick is deployment-specific. > > > > > > > > > > > > TTL makes sense only for (2). > > > > > > > > > > I don't think (2) is required, HTTP does not support (2) for > > > > > Temporary > > > > > re- direct (see https://tools.ietf.org/html/rfc7285#section-8.5.3= ). > > > > > > > > > > > > > [Jon] in the general potential overloading case of a specific DOTS > > > > server, to redirect a DOTS client to an alternative DOTS server for > > > > a period of > > > time > > > > makes sense to me - and then the DOTS client can then come back > > > > again. So, to me, [2] is a valid option. > > > > > > > > [Med] The comparison with 307 is not accurate because that code > > > > assumes the > > > > following: > > > > > > > > The 307 (Temporary Redirect) status code indicates that the targ= et > > > > resource resides temporarily under a different URI and the user > agent > > > > MUST NOT change the request method if it performs an automatic > > > > redirection to that URI. Since the redirection can change over > time, > > > > the client ought to continue using the original effective reques= t > > > > URI > > > > > > > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > ^^^^ > > > > for future requests. > > > > ^^^^^^^^^^^^^^^^^^^ > > > > > > > > Supplying the TTL is the only way to master the automatic fall back > > > > while avoiding contacting the "normal" server during the "temporary > > redirect'. > > > > > > > > [Jon] Agreed. > > > > > > If TTL expires, DOTS client cannot be re-directed when DDOS attack is > active. > > > If a DOTS client does not honor the TTL value and continues to use th= e > > > alternate server, the server should explicitly re-direct the client > > > and if the client still continues to use the DOTS server, it should > > > disconnect the (D)TLS session. > > > > > > -Tiru >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Tue Apr 10 02:07:26 2018 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 0DBEC127599 for ; Tue, 10 Apr 2018 02:07:24 -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 W1Vtty58Cphh for ; Tue, 10 Apr 2018 02:07:22 -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 0ED44127522 for ; Tue, 10 Apr 2018 02:07:22 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.90_1) (envelope-from ) id 1f5pFG-0004EN-97; Tue, 10 Apr 2018 10:07:19 +0100 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , , References: <016401d3cc1c$03321200$09963600$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7F97@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <01a701d3cc29$ba915b10$2fb41130$@jpshallow.com> <007501d3ccc2$b49f0b00$1ddd2100$@jpshallow.com> <021301d3cfe7$77e5cbe0$67b163a0$@jpshallow.com> <02b001d3d048$a2c68be0$e853a3a0$@jpshallow.com> In-Reply-To: Date: Tue, 10 Apr 2018 10:07:17 +0100 Message-ID: <000001d3d0ab$547dec40$fd79c4c0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01D3D0B3.B6531D20" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEYhrWXRSNBek+fWBybzdJS41Z0KAI4GsKdAX18SvQDE9KikwNzyn9FAeCfBHcAmG/gMgGrGCDSAZ2/A+cCF5qWXaTfiKuQ Content-Language: en-gb Archived-At: Subject: Re: [Dots] Data Channel ACL fragments 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, 10 Apr 2018 09:07:24 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0001_01D3D0B3.B6531D20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Tiru, See inline Jon3] Regards Jon From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Konda@mcafee.com] Sent: 10 April 2018 07:10 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] Data Channel ACL fragments [Jon2] The "flags->fragment" definition is ambiguous for an ACE (but valid as to whether to allow a packet to get fragmented or not - is that really a ACE?) which I would like to use. [TR] I don't get it. What purpose does it serve to create a ACE rule using "fragment" bit ? [Jon3] Agreed - This definition has not been thought through for an ACE. I think they have just emulated the DF bit in RFC791 as this general flags definition is the same as for the flags in RFC791. "Flags->more" definition covers all fragments but the last fragment. "Offset" is unfortunately not a range, but otherwise would get used for the final fragment. ~jon2 [TR] It looks like two ACE entries are required to drop all the fragments ("flags->more" set to 1 in the first ACE and "flags->more" set to 0 in the second ACE). How to use the "Offset" field for the final fragment ? [Jon3] I read "flags-more" to refer to the IP_MF in the IP header (RFC791 MF or more-fragments flag). This is set for all fragments apart from the final (as in last part of packet, not the order in which they are sent - fortunately that early decision to send them in the wrong order was phased out, but still there in some legacy systems!) [Jon3] But as the final fragment of the sequence could have any offset, the use of the offset field is not that helpful here. Even if we do go with our DOTS fragments definition (but widened to cover all fragments), we still cannot generate a netmod-acl entry for onward processing by an upstream mitigator. [Jon3] FYI, for Juniper, you just need to set 'first-fragment' and 'is-fragment' in their ACL. BGP FlowSpec does support fragmentation detection properly (RFC5575 Type 12 Fragment). -Tiru ------=_NextPart_000_0001_01D3D0B3.B6531D20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

See inline = Jon3]

 

Regards

 

Jon

 

From: Konda, Tirumaleswar Reddy [mailto: = TirumaleswarReddy_Konda@mcafee.com]
Sent: 10 April 2018 = 07:10
To: Jon Shallow; mohamed.boucadair@orange.com; = dots@ietf.org
Subject: RE: [Dots] Data Channel ACL = fragments

 

[Jon2] The = “flags->fragment” definition is ambiguous for an ACE (but = valid as to whether to allow a packet to get fragmented or not – = is that really a ACE?) which I would like to use.  =

 

[TR] I = don’t get it. What purpose does it serve to create a ACE rule = using “fragment” bit ?

[Jon3] = Agreed – This definition has not been thought through for an = ACE.  I think they have just emulated the DF bit in RFC791 as this = general flags definition is the same as for the flags in = RFC791.

 

“Flags->more” definition covers = all fragments but the last fragment. “Offset” is = unfortunately not a range, but otherwise would get used for the final = fragment.

~jon2

 

[TR] It = looks like two ACE entries are required to drop all the fragments = (“flags->more” set to 1 in the first ACE and = “flags->more” set to 0 in the second ACE). How to use the = “Offset”  field for the final fragment = ?

 

[Jon3] I = read “flags-more” to refer to the IP_MF in the IP header = (RFC791 MF or more-fragments flag).  This is set for all fragments = apart from the final (as in last part of packet, not the order in which = they are sent – fortunately that early decision to send them in = the wrong order was phased out, but still there in some legacy = systems!)

 

[Jon3] But = as the final fragment of the sequence could have any offset, the use of = the offset field is not that helpful here.  Even if we do go with = our DOTS fragments definition (but widened to cover all fragments), we = still cannot generate a netmod-acl entry for onward processing by an = upstream mitigator.

 

[Jon3] FYI, = for Juniper, you just need to set ‘first-fragment’ and = ‘is-fragment’ in their ACL.  BGP FlowSpec does support = fragmentation detection properly (RFC5575 Type 12 = Fragment).

 

-Tiru

<= /html> ------=_NextPart_000_0001_01D3D0B3.B6531D20-- From nobody Tue Apr 10 02:07:38 2018 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 A926D12762F for ; Tue, 10 Apr 2018 02:07:30 -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 dYLuG1sh21fw for ; Tue, 10 Apr 2018 02:07:25 -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 025E1127522 for ; Tue, 10 Apr 2018 02:07:25 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.90_1) (envelope-from ) id 1f5pFI-0004EN-E3; Tue, 10 Apr 2018 10:07:23 +0100 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , , References: <008401d3c4fd$216d0840$644718c0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF1067@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <014801d3c5b7$94c67f00$be537d00$@jpshallow.com> <009a01d3cdab$150b4c40$3f21e4c0$@jpshallow.com> <00cf01d3cdbe$24876650$6d9632f0$@jpshallow.com> <01fd01d3cfe4$a71b6580$f5523080$@jpshallow.com> <024901d3cff6$9d4beea0$d7e3cbe0$@jpshallow.com> <02c301d3d049$2f60cf20$8e226d60$@jpshallow.com> In-Reply-To: Date: Tue, 10 Apr 2018 10:07:17 +0100 Message-ID: <000a01d3d0ab$55bef7c0$013ce740$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01D3D0B3.B7ACB9B0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGlexwLZckIYJuvKwEmwuQr1rXL6AKpdMHOAgMRKpIBsBKRFgKXgqsdAxHSSssB/GODugGyw551AT90vc8BfRxiYwGyPN+IAfZRzPoCBSpzvgLbmAm4Aljq/Xeja7QJ4A== Content-Language: en-gb Archived-At: Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 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, 10 Apr 2018 09:07:31 -0000 This is a multipart message in MIME format. ------=_NextPart_000_000B_01D3D0B3.B7ACB9B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Tiru, =20 See inline [Jon3] =20 Regards =20 Jon =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Monday, April 9, 2018 2:55 PM To: Konda, Tirumaleswar Reddy ; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 =20 Hi Tiru, =20 If a DOTS client knows the full scope of the Networks that it is allowed = to use in a ACL or mitigate request, and the DOTS server limits any update = from that client to the scope of Networks (with any unexpected side effects = that may have), then there is no difference in my mind as to whether the DOTS clients fills in the destination-network, or the DOTS server does so on = the DOTS client=92s behalf before ACL instantiation if destination-network = is not defined. =20 [TR] The above model only works when the DOTS server and DOTS client are directly communicating with each other (In the above, the DOTS server = knows the DOTS client identity to enforce the scope but will not the DOTS = client identity in the presence of a client-domain DOTS gateway).=20 =20 [Jon1] The last para of =9310. Security Considerations=94 states DOTS servers MUST verify that requesting DOTS clients are entitled to trigger actions on a given IP prefix. That is, only actions on IP resources that belong to the DOTS client' domain MUST be authorized by a DOTS server. The exact mechanism for the DOTS servers to validate that the target prefixes are within the scope of the DOTS client's domain is deployment-specific. =20 [Jon1] So it makes no difference if the DOTS client happens to be an = agent part of a client-domain DOTS gateway. If the client-domain DOTS gateway = is hiding all the =91behind=92 clients and presenting as single client, = there is no issue. However, if the =91behind=92 clients are presented as 2 or more = =91cuid=92s by the DOTS gateway, then either the scope is per =91cuid=92, or if = =91cdid=92s are being applied by the upstream server domain DOTS gateway then on a per =91cdid=92 basis if wanted. =20 For a client behind a client domain DOTS gateway, there may be non = public IP addresses that the (DMS) client is responsible for, but these should = never be sent out through the DOTS gateway (and should be rejected by the DOTS server as out of scope). There does have to be a common agreement = between DOTS client & DOTS server as to what Networks are in scope, but the DOTS client currently cannot request this from the DOTS server and has to be agreed out of band. =20 [TR] I don=92t see a new problem, even when a DOTS client sends a = mitigation request it needs to know if the targets conveyed in the mitigation = request are in its scope or not. =20 [Jon1] but again, the DOTS server MUST verify the IP prefix is valid, so = has to know scope. I agree that the DOTS client (or client domain DOTS = gateway) needs to know (today out of band) what is the scope of what is valid to request. The challenge comes when the DOTS server=92s scope is = reconfigured, but not yet updated on the DOTS client. =20 =20 [TR2] The scope would be first updated on the DOTS client domain and = then on the DOTS server (e.g. IP prefix re-numbering).=20 =20 [Jon2] I was more thinking of a DOTS client that got missed off a list = when the DOTS server was updated. Normally though, they should be kept in = sync but which one gets updated first is uncertain to me. =20 [TR3] If the DOTS client missed update, it will have various other = problems; any network policy based on destination network IP/prefix will fail. = DOTS client should support mechanisms to receive the latest network = configuration after missing critical updates because it was offline or its=20 connectivity was lost. =20 [Jon3] So to me, we need to add in something to the data channel = protocol so that a DOTS client can request as to what is the network current scope = it is allowed to ask for ACL/Mitigation for. =20 There is no reason as to why the DOTS server cannot maintain a valid = scope of Networks that the client domain DOTS gateway is allowed to request = for validity checking =96 unless I am missing something? =20 [TR] You are partially right, the DOTS server does not know the valid = scope of prefixes that a DOTS client behind client-domain DOTS gateway is = allowed to request. =20 [Jon1] Again, the last para of 10. stands here, and so the scope has to = be known by the DOTS server. =20 [TR] Yes, but it may not know the scope of a DOTS client behind a client-domain DOTS gateway. =20 [Jon2] But it will know what the client-domain DOTS gateway is allowed = to pass through in terms of Destination Network. The client-domain DOTS gateway will separately need to know what Destination networks are = allowed to get out through the gateway. =20 Troubleshooting has kept me in a job for more years than I care to = remember, anything to aid troubleshooting is what I am interested in and so = totally agree that rogue DOTS client=92s capabilities need to be kept under = control with suitable logging to aid diagnosis is a major plus. However in this case, the implicit rule is no different to the DOTS client requesting = the full Networks scope in an ACL request. =20 [TR] If the client is not authorized to request the full network scope, = it can detected by the client-domain DOTS gateway and rejects the filtering rule by comparing the destination-networks=20 specified in the ACE. [Jon1] Agreed, it is the responsibility of the client domain DOTS = gateway to only allow out valid networks that are valid within the DOTS server=92s = scope. =20 [Jon1] Should we support a way for the client domain DOTS gateway (i.e. DOTS client agent) to programmatically get the current valid network = scope from the DOTS server? =20 [TR2] It will not solve the above problem of detecting and rejecting a = rouge (or misconfigured) DOTS client behind client domain DOTS gateway sending = ACL without specifying destination-network. =20 [Jon2] Hmm. If the client-domain DOTS gateway is restricted in scope as = to what it is allowed to request, and a rogue client behind the gateway = does not specify a destination-network, then when the request passes through = the gateway the upstream DOTS server will only use the scope allowed for = that specific client-domain DOTS gateway. Again, it is exactly the same as = if the rogue client was to specify the full set of allowed scope as a set = of destination networks in terms of damage capabilities. =20 [TR3] No, the client-domain DOTS gateway can detect and reject the ACL because the rouge DOTS client has specified destination-network not = under its scope.=20 =20 [Jon3] You are missing my point. Agreed that the client-domain DOTS = gateway must sanity check what is passed through. However, there will be a set = of Networks that are allowed through the DOTS gateway which are within the defined scope of what the DOTS server allows. This =93allowed through networks=94 can legitimately be set by the DOTS client in = destination-network, or the DOTS server can fill in the same set of networks in the ACL instantiation if destination-networks was empty and the potential side effects damage caused will be the same. ~jon2 =20 -Tiru =20 ~jon1 =20 -Tiru =20 Regards =20 Jon =20 From: Konda, Tirumaleswar Reddy [mailto: = TirumaleswarReddy_Konda@mcafee.com] Sent: 07 April 2018 06:48 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 =20 Hi Jon, =20 DOTS clients (intelligent DDoS mitigation system, application server) = will know the destination networks, what kind of DOTS clients will not know = the destination networks they are allowed to use ? DOTS clients could be behind client-domain DOTS gateway, DOTS server = will have no way to validate the DOTS client identity sending the ACE request = to determine the destination IP addresses in its scope, it will only know = the destination IP addresses in the DOTS client domain scope.=20 Further, the implicit rule can be misused by compromised DOTS clients = (e.g. black-list good traffic to the entire DOTS client domain) and it=92s a troubleshooting nightmare to find the culprit device adversely impacting = the entire network. =20 Cheers, -Tiru =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Friday, April 6, 2018 9:14 PM To: Konda, Tirumaleswar Reddy ; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 =20 Hi Tiru, =20 The DOTS server is likely to have a scope of IP addresses that are valid = for the client to ask for protection for based on the cuid or cdid. =20 The DOTS client may have some knowledge of the scope IPs by some out of = band method, but programmatically cannot ask the server what they are.=20 =20 If a client specifies a destination network that is out of the valid = scope of IP addresses, then the ACE request will get rejected. The client may then have a challenge to work out what destination networks it is = allowed to use. =20 How does a client set up a blacklist for all the IPS within his allowed scope if it does not know what the scope is? =20 If the client has not provided a destination network, then the DOTS = server can auto-fill in the missing information at the time of the ACE instantiation =96 and this then handles if the scope of IP addresses = change. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 06 April 2018 16:19 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 =20 I don=92t understand how the DOTS server/mitigation will fill it in at = time of ACE instantiation, and why can=92t the DOTS client fill the destination network details ? =20 -Tiru =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Friday, April 6, 2018 6:58 PM To: Konda, Tirumaleswar Reddy ; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 =20 Hi there, =20 There is no current way to request of a DOTS Server as to what is the = set of IP networks that a DOTS client can use either within a mitigation = request or to set up an ACL other than by =93testing for ok or not ok=94 with lots = of different IP addresses. =20 There is a reasonable likelihood of the scope of valid IPs from the = Server=92s perspective will change over time. So, unless a DOTS client wants to control a specific destination network, then my suggestion would be to = leave the ACE destination network empty and for the DOTS Server / DOTS = mitigator (how is out of scope) to fill it in at time of ACE instantiation. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 27 March 2018 13:49 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 =20 Please see inline [TR] =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Tuesday, March 27, 2018 4:07 PM To: Konda, Tirumaleswar Reddy ; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 =20 Hi Tiru / Med =20 See inline [Jon] =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 27 March 2018 09:47 To: mohamed.boucadair@orange.com; Jon Shallow; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 =20 I also support to mandate destination-network for immediately enforced filtering rules. [Jon] This can be enforced / inserted by the DOTS Server for all the destination networks of the domain that the DOTS client =91belongs=92 = to. That said, it would be good to always have the destination network in an ACL = as it can be validated and cross-checked whenever the legitimate set of = domain protected IPs are updated. [Jon] However, what happens to the Destination network in the case of a = call home DOTS client that becomes a quasi DOTS server and the Destination networks are somewhere out on the Internet? =20 [TR] DDOS is a targeted attack, so the DOTS client can specify the destination network targeted by devices in the DOTS server domain and = the DOTS server can validate if the destination network is indeed targeted = by its devices. =20 -Tiru =20 From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed......boucadair@orange.com =20 Sent: Tuesday, March 27, 2018 1:09 PM To: Jon Shallow ; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 =20 Hi Jon,=20 =20 Thank you for the comments. =20 Please see inline. =20 Cheers, Med =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : lundi 26 mars 2018 14:23 =C0 : dots@ietf.org Objet : [Dots] IETF 101 Presentation Data Channel Issue #4 =20 Hi there, =20 As per Med=92s presentation to the IETF 101 =20 Issue #4: Per-Domain or Per-client Filters? =20 =95 Conclusion =96 Filters that are activated only during mitigation time are on a = per-client basis =95 Filters are per-domain when are immediately applied =20 =93Filters are per-domain when are immediately applied=94 is what I have = an challenge with. =20 If we have a compromised or rogue DOTS client, the simple use of = something like curl, along with the client certificates etc. can be used to = generate any ACL with activation-type :=3D =91immediate=92 which is then = immediately applied for all traffic within the domain as per the above. =20 [Med] Yes. FWIW, this attack is called out in the security = considerations section:=20 =20 =93Nevertheless, an attacker who can access a DOTS client is technically capable of launching various attacks, such as: =20 ..; =20 o Set invalid ACL entries, which may prevent legitimate traffic from being forwarded. Likewise, invalid ACL entries may lead to forward DDoS traffic. =93 [Jon] Agreed that the attack is covered off in the Security section, but = we should be limiting the possibility / scope of the attack vector by = enforcing some rules as to what is / is not allowed. Allowing a DOTS client to be able to affect all the traffic within the domain is a huge risk to me = and should not be allowed. =20 So, a ACL that blacklists the DNS server, or drops all port 443 traffic = etc. can easily cause all of the other clients / devices within the domain to = be taken off air. Putting the intelligence into the DOTS server to not = allow this to happen could be a challenge. [The signal channel is much harder to compromise and affect traffic = flows to other areas within the domain] =20 I believe that an ACL instantiated by a DOTS client (immediate or when-mitigating) should only apply to the DOTS client=92s traffic which = means that the destination-network has to be a part of the ACL, whether = implicitly added by the DOTS server, or by the DOTS client and suitably validated. =20 [Med] Putting aside that I don=92t parse =93DOTS client=92s traffic=94, [Jon] I was referring to all the traffic flows that a DOTS client can legitimately request control of to the DOTS server that are within the = scope of what the DOTS client is protecting (which may or may not be the DOTS client=92s IP address). I interpret your answer as a support to this question raised for issue = #4: * =93Should we mandate destination-network to be present for immediately enforced filters?=94 [Jon] See response to Tiru=92s Agreement above. ~Jon There is nothing to stop the DOTS server or DOTS mitigator merging = common ACLs to reduce the number of ACLs within the mitigation device. =20 As a side note =93mitigation-time=94 is perhaps a bad name as it implies = a time period =96 something like =93when-mitigating=94 to me is clearer. [Med] Fixed in my local copy. Thank you. =20 Regards =20 Jon ------=_NextPart_000_000B_01D3D0B3.B7ACB9B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

See inline = [Jon3]

 

Regards

 

Jon

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Monday, April 9, 2018 2:55 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: RE: = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

Hi Tiru,

 

If a DOTS client knows = the full scope of the Networks that it is allowed to use in a ACL or = mitigate request, and the DOTS server limits any update from that client = to the scope of Networks (with any unexpected side effects that may = have), then there is no difference in my mind as to whether the DOTS = clients fills in the destination-network, or the DOTS server does so on = the DOTS client’s behalf before ACL instantiation if = destination-network is not defined.

 

[TR] The = above model only works when the DOTS server and DOTS client are directly = communicating with each other (In the above, the DOTS server knows the = DOTS client identity to enforce the scope but will not the DOTS client = identity in the presence of a client-domain DOTS gateway). =

 

[Jon1] The last para of = “10. Security Considerations” states

   DOTS servers MUST verify that = requesting DOTS clients are entitled to

   trigger actions on a given IP = prefix.  That is, only actions on IP

   resources that belong to the DOTS = client' domain MUST be authorized

   by a DOTS server.  The exact = mechanism for the DOTS servers to

   validate that the target prefixes = are within the scope of the DOTS

   client's = domain is deployment-specific.

 

[Jon1] So it makes no difference if the DOTS = client happens to be an agent part of a client-domain DOTS = gateway.  If the client-domain DOTS gateway is hiding all the = ‘behind’ clients and presenting as single client, there is = no issue.  However, if the ‘behind’ clients are = presented as 2 or more ‘cuid’s by the DOTS gateway, then = either the scope is per ‘cuid’, or if ‘cdid’s = are being applied by the upstream server domain DOTS gateway then on a = per ‘cdid’ basis if wanted.

 

For a client behind a = client domain DOTS gateway, there may be non public IP addresses that = the (DMS) client is responsible for, but these should never be sent out = through the DOTS gateway (and should be rejected by the DOTS server as = out of scope).  There does have to be a common agreement between = DOTS client & DOTS server as to what Networks are in scope, but the = DOTS client currently cannot request this from the DOTS server and has = to be agreed out of band.

 

[TR] I = don’t see a new problem, even when a DOTS client sends a = mitigation request it needs to know if the targets conveyed in the = mitigation request are in its scope or not.

 

[Jon1] but again, the = DOTS server MUST verify the IP prefix is valid, so has to know = scope.  I agree that the DOTS client (or client domain DOTS = gateway) needs to know (today out of band) what is the scope of what is = valid to request.  The challenge comes when the DOTS server’s = scope is reconfigured, but not yet updated on the DOTS client.  =

 

[TR2] The scope would be first updated on the DOTS = client domain and then on the DOTS server (e.g. IP prefix re-numbering). =

 

[Jon2] I was more = thinking of a DOTS client that got missed off a list when the DOTS = server was updated.  Normally though, they should be kept in sync = but which one gets updated first is uncertain to = me.

 

[TR3] If the DOTS client missed update, it will have = various other problems; any network policy based on destination network = IP/prefix will fail. DOTS client should support mechanisms to receive = the latest network configuration after missing critical updates because = it was offline or its

         &= nbsp;connectivity was lost.

 

[Jon3] So to me, we need = to add in something to the data channel protocol so that a DOTS client = can request as to what is the network current scope it is allowed to ask = for ACL/Mitigation for.

 

There is no reason as to why the DOTS server = cannot maintain a valid scope of Networks that the client domain DOTS = gateway is allowed to request for validity checking – unless I am = missing something?

 

[TR] You are = partially right, the DOTS server does not know the valid scope of = prefixes that a DOTS client behind client-domain DOTS gateway is allowed = to request.

 

[Jon1] Again, the last = para of 10. stands here, and so the scope has to be known by the DOTS = server.

 

[TR] Yes, = but it may not know the scope of a DOTS client behind a client-domain = DOTS gateway.

 

[Jon2] But it will know = what the client-domain DOTS gateway is allowed to pass through in terms = of Destination Network.  The client-domain DOTS gateway will = separately need to know what Destination networks are allowed to get out = through the gateway.

 

Troubleshooting has kept = me in a job for more years than I care to remember, anything to aid = troubleshooting is what I am interested in and so totally agree that = rogue DOTS client’s capabilities need to be kept under control = with suitable logging to aid diagnosis is a major plus.  However in = this case, the implicit rule is no different to the DOTS client = requesting the full Networks scope in an ACL = request.

 

[TR] If the = client is not authorized to request the full network scope, it can = detected by the client-domain DOTS gateway and rejects the filtering = rule by comparing the destination-networks

        specifi= ed in the ACE.

[Jon1] Agreed, it is the = responsibility of the client domain DOTS gateway to only allow out valid = networks that are valid within the DOTS server’s = scope.

 

[Jon1] Should we support = a way for the client domain DOTS gateway  (i.e. DOTS client agent) = to programmatically get the current valid network scope from the DOTS = server?

 

[TR2] It = will not solve the above problem of detecting and rejecting a rouge (or = misconfigured) DOTS client behind client domain DOTS gateway sending ACL = without specifying destination-network.

 

[Jon2] Hmm.  If the = client-domain DOTS gateway is restricted in scope as to what it is = allowed to request, and a rogue client behind the gateway does not = specify a destination-network, then when the request passes through the = gateway the upstream DOTS server will only use the scope allowed for = that specific client-domain DOTS gateway.  Again, it is exactly the = same as if the rogue client was to specify the full set of allowed scope = as a set of destination networks in terms of damage = capabilities.

 

[TR3] No, = the client-domain DOTS gateway can detect and reject the ACL because the = rouge DOTS client has specified destination-network not under its scope. =

 

[Jon3] You are missing = my point.=A0 Agreed that the client-domain DOTS gateway must sanity = check what is passed through.=A0 However, there will be a set of = Networks that are allowed through the DOTS gateway which are within the = defined scope of what the DOTS server allows.=A0 This “allowed = through networks” can legitimately be set by the DOTS client in = destination-network, or the DOTS server can fill in the same set of = networks in the ACL instantiation if destination-networks was empty and = the potential side effects damage caused will be the = same.

~jon2

 

-Tiru

 

~jon1

 

-Tiru

 

Regards

 

Jon

 

From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Kond= a@mcafee.com]
Sent: 07 April 2018 06:48
To: Jon = Shallow; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: RE: = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

Hi = Jon,

 

DOTS clients (intelligent DDoS = mitigation system, application server) will know the destination = networks, what kind of DOTS clients will not know the destination = networks they are allowed to use ?

DOTS clients could be behind = client-domain DOTS gateway, DOTS server will have no way to validate the = DOTS client identity sending the ACE request to determine the = destination IP addresses in its scope, it will only know the destination = IP addresses in the DOTS client domain scope.

Further, the implicit rule can be = misused by compromised DOTS clients (e.g. black-list good traffic to the = entire DOTS client domain) and it’s a  troubleshooting = nightmare to find the culprit device adversely impacting the entire = network.

 

Cheers,

-Tiru

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Friday, April 6, 2018 9:14 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: RE: = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

Hi Tiru,

 

The DOTS server is = likely to have a scope of IP addresses that are valid for the client to = ask for protection for based on the cuid or = cdid.

 

The DOTS client may have = some knowledge of the scope IPs by some out of band method, but = programmatically cannot ask the server what they are. =

 

If a client specifies a = destination network that is out of the valid scope of IP addresses, then = the ACE request will get rejected.  The client may then have a = challenge to work out what destination networks it is allowed to = use.

 

How does a client set up = a blacklist for all the IPS within his allowed scope if it does not know = what the scope is?

 

If the client has not = provided a destination network, then the DOTS server can auto-fill in = the missing information at the time of the ACE instantiation – and = this then handles if the scope of IP addresses = change.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 06 April 2018 = 16:19
To: Jon Shallow; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: Re: = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

I don’t = understand how the DOTS server/mitigation will fill it in at time of ACE = instantiation, and why can’t the DOTS client fill the destination = network details ?

 

-Tiru

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Friday, April 6, 2018 6:58 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: RE: = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

Hi there,

 

There is no current way = to request of a DOTS Server as to what is the set of IP networks that a = DOTS client can use either within a mitigation request or to set up an = ACL other than by “testing for ok or not ok” with lots of = different IP addresses.

 

There is a reasonable = likelihood of the scope of valid IPs from the Server’s perspective = will change over time.  So, unless a DOTS client wants to control a = specific destination network, then my suggestion would be to leave the = ACE destination network empty and for the DOTS Server / DOTS mitigator = (how is out of scope) to fill it in at time of ACE = instantiation.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 27 March 2018 = 13:49
To: Jon Shallow; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: Re: = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

Please see inline = [TR]

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Tuesday, March 27, 2018 4:07 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: RE: = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

Hi Tiru / Med

 

See inline = [Jon]

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 27 March 2018 = 09:47
To: mohamed.boucadair@orange.com= ; Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

I also support to = mandate destination-network for immediately enforced filtering = rules.

[Jon] This can be = enforced / inserted by the DOTS Server for all the destination networks = of the domain that the DOTS client ‘belongs’ to.  That = said, it would be good to always have the destination network in an ACL = as it can be validated and cross-checked whenever the legitimate set of = domain protected IPs are updated.

[Jon] However, what = happens to the Destination network in the case of a call home DOTS = client that becomes a quasi DOTS server and the Destination networks are = somewhere out on the Internet?

 

[TR] DDOS is a targeted attack, so = the DOTS client can specify the destination network targeted by devices = in the DOTS server domain and the DOTS server can validate if the = destination network is indeed targeted by its = devices.

 

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of mohamed......boucadair@orang= e.com
Sent: Tuesday, March 27, 2018 1:09 PM
To: = Jon Shallow <supjps-ietf@jpshallow.com&g= t;; dots@ietf.org
Subject: Re: = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

Hi Jon,

 

Thank you for the comments.

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] = De la part de Jon Shallow
Envoy=E9 : lundi 26 mars = 2018 14:23
=C0 : dots@ietf.org
Objet : = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

Hi = there,

 

As per Med’s presentation to the IETF = 101

 

Issue #4: Per-Domain or Per-client = Filters?

 

• Conclusion

– Filters that are activated only during = mitigation time are on a per-client basis

   • Filters are per-domain when are = immediately applied

 

“Filters are per-domain when are immediately = applied” is what I have an challenge with.

 

If we have a = compromised or rogue DOTS client, the simple use of something like curl, = along with the client certificates etc. can be used to generate any ACL = with activation-type :=3D ‘immediate’ which is then = immediately applied for all traffic within the domain as per the = above.

 

[Med] = Yes. FWIW, this attack is called out in the security considerations = section:

 

“Nevertheless, =
an

   attacker who can access a = DOTS client is technically capable of

   launching various attacks, = such as:

 

..;

 

   o  Set invalid ACL entries, which may =
prevent legitimate traffic from
      being forwarded.  =
Likewise, invalid ACL entries may lead =
to
      forward DDoS traffic.

“

[Jon] Agreed that the = attack is covered off in the Security section, but we should be limiting = the possibility / scope of the attack vector by enforcing some rules as = to what is / is not allowed.  Allowing a DOTS client to be able to = affect all the traffic within the domain is a huge risk to me and should = not be allowed.

 

So, a ACL = that blacklists the DNS server, or drops all port 443 traffic etc. can = easily cause all of the other clients / devices within the domain to be = taken off air.  Putting the intelligence into the DOTS server to = not allow this to happen could be a challenge.

[The signal channel is much harder to compromise and = affect traffic flows to other areas within the domain]

 

I believe = that an ACL instantiated by a DOTS client (immediate or when-mitigating) = should only apply to the DOTS client’s traffic which means that = the destination-network has to be a part of the ACL, whether implicitly = added by the DOTS server, or by the DOTS client and suitably = validated.

 

[Med] = Putting aside that I don’t parse “DOTS client’s = traffic”,

[Jon] I was referring to all the traffic flows = that a DOTS client can legitimately request control of to the DOTS = server that are within the scope of what the DOTS client is protecting = (which may or may not be the DOTS client’s IP = address).

I = interpret your answer as a support to this question raised for issue = #4:

    • “Should = we mandate destination-network to be present for immediately enforced = filters?”

[Jon] See response to = Tiru’s Agreement above.

~Jon

There is nothing to stop the DOTS server or DOTS = mitigator merging common ACLs to reduce the number of ACLs within the = mitigation device.

 

As a side = note “mitigation-time” is perhaps a bad name as it implies a = time period – something like “when-mitigating” to me = is clearer.

[Med] = Fixed in my local copy. Thank you.

 

Regards

 

Jon

<= /div>
------=_NextPart_000_000B_01D3D0B3.B7ACB9B0-- From nobody Tue Apr 10 02:17:11 2018 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 BE69E127369 for ; Tue, 10 Apr 2018 02:17:09 -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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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 n2YaQfeP7Hhv for ; Tue, 10 Apr 2018 02:17:07 -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 C669E12420B for ; Tue, 10 Apr 2018 02:17:06 -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=1523351825; 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: dlp-product:dlp-version:dlp-reaction: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-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-Network-Message-Id: 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 8VkCQxZEAflg0JKm/AAcY1sDmJloQRYwTJY7frK7u U=; b=J3SuggKfnUviavO1dF2veI5Ya7e3TGGaACCDkLtxzG3a dQ5AwuIuu2iK8ZFlS8o9vYCfoJBBgb4oxgU6XYr+eY97RcK6i7 e8neohJdcwjH8biVUtv7uV6U8lF+BZvzkGtFdB/MC/8O1pGrg1 sx0w1mLc3rE1RMIJ2BS2bU7gjtg= Received: from DNVEXAPP1N05.corpzone.internalzone.com (DNVEXAPP1N05.corpzone.internalzone.com [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 5812_5760_92d48dd0_7607_485e_ad37_1b4a20b9f336; Tue, 10 Apr 2018 04:17:04 -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; Tue, 10 Apr 2018 03:16:19 -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; Tue, 10 Apr 2018 03:16:19 -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; Tue, 10 Apr 2018 03:16:18 -0600 Received: from NAM02-BL2-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.1347.2; Tue, 10 Apr 2018 03:16:18 -0600 Received: from BN6PR16MB1425.namprd16.prod.outlook.com (10.172.207.19) by BN6PR16MB1425.namprd16.prod.outlook.com (10.172.207.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.653.12; Tue, 10 Apr 2018 09:16:16 +0000 Received: from BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d]) by BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d%2]) with mapi id 15.20.0653.015; Tue, 10 Apr 2018 09:16:16 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Signal Channel - 300 Redirected Signaling Thread-Index: AdPMGSyCaQQbv+vLSW+0gkDbU7HOEwAAo7xAAAH7T4AAARdqYAAhoxEAAAGQiwAAAKyNYAAF3e1QACUKCFAAAZEMQAAIeXTgAARcGhAAAoG7gAABGXwAAAAjBIAAAa5ZgAAAiReAAABpmzAAL32aAABWbPEwAAIv/gAAAPiKMAAA7T0AAACbH4AAAR48IAAD29GAAAAS23AAALmWgAAAGvzwAAE21AAAEXqFAAAR0YPwAAKsZsAAAI9wIAAAfxxQAARhbLA= Date: Tue, 10 Apr 2018 09:16:16 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93302DEFA4A0@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEFA561@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <029b01d3d042$fa319a10$ee94ce30$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEFB0C8@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEFB132@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DEFB132@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [185.221.69.46] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR16MB1425; 7:yyuwhDgSB1Z2++pZh8sMzqt2E+wy1h5Rl/Qy3DEn0uPHwHYcdSzi2A8TNlkTqGhd1/C7VR4BY+usrnE/aNlN8ZLQKWEMyoDmfKlQDdG2n2wLvPQaouO6nEvJhPMVovOj1G+xLoxq3UY0GsfaSSJVB0mqeWnQ9cluBbn4gPUCBDNYkAMcUoMqrLq6LMXQXe+pXbJKXXATwx8pWcOGOUkeipN9aNHxNrsGU35NOUv7x90Oq1tQEQ4K6gJ0UTesyRwS x-ms-exchange-antispam-srfa-diagnostics: SOS; X-MS-Office365-Filtering-Correlation-Id: 196ccf72-512c-4819-6d33-08d59ec3b702 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BN6PR16MB1425; x-ms-traffictypediagnostic: BN6PR16MB1425: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(18271650672692)(123452027830198)(15185016700835); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(3231221)(944501327)(52105095)(6041310)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(6072148)(201708071742011); SRVR:BN6PR16MB1425; BCL:0; PCL:0; RULEID:; SRVR:BN6PR16MB1425; x-forefront-prvs: 0638FD5066 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(39380400002)(376002)(39860400002)(396003)(199004)(13464003)(51444003)(32952001)(189003)(55784002)(53754006)(8936002)(14454004)(25786009)(3660700001)(33656002)(561944003)(6116002)(2900100001)(2906002)(110136005)(966005)(66066001)(316002)(3846002)(2501003)(478600001)(6506007)(105586002)(7696005)(72206003)(55016002)(9686003)(76176011)(3280700002)(53936002)(6246003)(81156014)(6436002)(68736007)(86362001)(8676002)(80792005)(305945005)(7736002)(53546011)(74316002)(106356001)(229853002)(5660300001)(97736004)(5250100002)(102836004)(11346002)(26005)(93886005)(476003)(186003)(81166006)(446003)(99286004)(59450400001)(486006)(6306002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR16MB1425; H:BN6PR16MB1425.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: tuCswCaUwA9SBmnMvz8CEzYiDmatKr4mlNbpAewIOVChLRKfVPgknz618261fAUM6Y6BSifYDNhKF6XJENDAyBWLq33jElIwq5aBG8cLe+foabjm07t2l1ERoURfxbGr0iX+36IsTD+cOqEyxYBZnjGLYSBHHnAM6wgp227XpGr2oKAPQoGhCuaaJf5guLyiO5gokWyv+SFt7O2Xt2qh9ldxRO1PFMgg4fM5kFkVoOah+fanGlRh4KUTzRYsdhlE0iuSlQKzSQcpu9T9Bd2VsNavCJAFFUudEs9rlPMF0x8Pt+i3YjGnnASYb1/a7hWSMxs6dPg2dg8Er2qmxK/EI9eBEODQe0Wr5INqA8awCPMi5LQOfY7KgNS8cwWSchzShWU5Vyfa7n95dGZDE3mdtpSzuYarHVOaJOzTmj4yYak= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 196ccf72-512c-4819-6d33-08d59ec3b702 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2018 09:16:16.6542 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR16MB1425 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 <6260> : inlines <6554> : streams <1783606> : uri <2623012> Archived-At: Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling 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, 10 Apr 2018 09:17:10 -0000 > -----Original Message----- > From: mohamed.boucadair@orange.com > [mailto:mohamed.boucadair@orange.com] > Sent: Tuesday, April 10, 2018 12:34 PM > To: Konda, Tirumaleswar Reddy ; > Jon Shallow ; dots@ietf.org > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling >=20 > Re-, >=20 > The exact value to return is on the deployment side. If a server/provider= decides > that 0 or small value is to be returned (that is, redirect applies only f= or the > ongoing request), why should the spec care about this? If 0 value is returned, and the client wants to send a requests to discover= and configure the DOTS session configuration before sending the mitigation= request, 0 value means the client does not get to send the mitigation request. We may want to clarify = that with 0 TTL value, re-direct applies only for the ongoing mitigation re= quest and not for other type of requests. Further, too small value will adv= ersely impact a DOTS client on slow links, e.g. TTL value expires by the ti= me the mitigation request reaches the DOTS server after multiple retries. = =20 -Tiru >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Konda, > > Tirumaleswar Reddy Envoy=E9=A0: mardi 10 avril 2018 08:46 =C0=A0: BOUCA= DAIR > > Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet=A0: Re: [Dots] Signal > > Channel - 300 Redirected Signaling > > > > > -----Original Message----- > > > From: mohamed.boucadair@orange.com > > > [mailto:mohamed.boucadair@orange.com] > > > Sent: Tuesday, April 10, 2018 12:01 PM > > > To: Konda, Tirumaleswar Reddy ; > > > Jon Shallow ; dots@ietf.org > > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > Hi all, > > > > > > I think that we are converging. > > > > > > Below a text proposal which reflects the outcome of the discussion: > > > > > > =3D=3D=3D=3D=3D=3D > > > ttl: Time to live (TTL) of the alternate DOTS server, represented= as > > > an integer number of seconds. That is, the time interval that = the > > > alternate DOTS server may be cached for use by a DOTS client. > > > > > > A value of negative one (-1) indicates indefinite TTL. This va= lue > > > means that the alternate DOTS server is to be used until the > > > alternate DOTS server redirects the traffic with another 3.00 > > > response. > > > > > > If no 'ttl' is returned in a redirect response, this is equival= ent > > > to returning a 'ttl' parameter set to '-1'. > > > > > > If the alternate DOTS server TTL has expired, the DOTS client M= UST > > > use the DOTS server(s), that was provisioned using means discus= sed > > > in Section 4.1. This fall back mechanism is triggered immediat= ely > > > upon expiry of the TTL except when a DDoS attack is active. > > > > > > Requests issued by misbehaving DOTS clients which do not honor = the > > > TTL or react to explicit re-direct messages can be rejected by > > > DOTS servers. > > > > > > This is an optional attribute. > > > > Looks good. We may also want to say that 0 or too small value for ttl > > should be avoided. > > > > -Tiru > > > > > =3D=3D=3D=3D=3D=3D=3D > > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De=A0: Konda, Tirumaleswar Reddy > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > Envoy=E9=A0: mardi 10 avril 2018 07:31 =C0=A0: Jon Shallow; BOUCADA= IR > > > > Mohamed IMT/OLN; dots@ietf.org Objet=A0: RE: > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > -----Original Message----- > > > > > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > > Sent: Tuesday, April 10, 2018 2:10 AM > > > > > To: mohamed.boucadair@orange.com; Konda, Tirumaleswar Reddy > > > > > ; dots@ietf.org > > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > Hi, > > > > > > > > > > See inline [Jon] > > > > > > > > > > Regards > > > > > > > > > > Jon > > > > > > > > > > -----Original Message----- > > > > > From: mohamed.boucadair@orange.com [mailto: > > > > > mohamed.boucadair@orange.com] > > > > > Sent: 09 April 2018 13:20 > > > > > To: Konda, Tirumaleswar Reddy; Jon Shallow; dots@ietf.org > > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > Re-, > > > > > > > > > > Glad to see that we both agree to get out from the DNS comparison= . > > > > > > > > > > [Jon] Also agree. Perhaps 'ttl' should be renamed 'alt-server-tt= l'. > > > > > > > > > > Please see inline. > > > > > > > > > > Cheers, > > > > > Med > > > > > > > > > > > -----Message d'origine----- > > > > > > De=A0: Konda, Tirumaleswar Reddy > > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > Envoy=E9=A0: lundi 9 avril 2018 13:48 =C0=A0: BOUCADAIR Mohamed > > > > > > IMT/OLN; Jon Shallow; dots@ietf.org Objet=A0: RE: > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of > > > > > > > mohamed.boucadair@orange.com > > > > > > > Sent: Monday, April 9, 2018 5:12 PM > > > > > > > To: Konda, Tirumaleswar Reddy > > > > > > > ; > > > > > > > Jon Shallow ; dots@ietf.org > > > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected > > > > > > > Signaling > > > > > > > > > > > > > > Re-, > > > > > > > > > > > > > > Please see inline. > > > > > > > > > > > > > > Cheers, > > > > > > > Med > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Dots > > > > > > > > [mailto:dots-bounces@ietf.org] De la part de Konda, > > > > > > > > Tirumaleswar Reddy Envoy=E9=A0: lundi 9 avril 2018 13:29 = =C0=A0: > > > > > > > > BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet= =A0: > > > > > > > > Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: mohamed.boucadair@orange.com > > > > > > > > > [mailto:mohamed.boucadair@orange.com] > > > > > > > > > Sent: Monday, April 9, 2018 4:49 PM > > > > > > > > > To: Konda, Tirumaleswar Reddy > > > > > > > > > ; > > > > > > > > > Jon Shallow ; dots@ietf.org > > > > > > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected > > > > > > > > > Signaling > > > > > > > > > > > > > > > > > > Re-, > > > > > > > > > > > > > > > > > > Focusing on this part of your answer: > > > > > > > > > > > > > > > > > > "No, DNS TTL lifetime does not mean existing session > > > > > > > > > has to be > > > > > > > > disconnected > > > > > > > > > after the TTL expires." > > > > > > > > > > > > > > > > > > This is exactly the disconnect. We are not discussing > > > > > > > > > **DNS > > > > > > > > > TTL** but the validity time of a an alternate server as > > > > > > > > > provided in a DOTS redirect > > > > > > > > signal. > > > > > > > > > > > > > > > > When the server can explicitly re-direct the client, why > > > > > > > > provide the validity time of an alternate server ? > > > > > > > > > > > > > > [Med] Involving the alternate server is one deployment mode > > > > > > > among > > > > > others. > > > > > > > The current text allows for these two modes: > > > > > > > > > > > > > > (1) redirect upon an explicit signal > > > > > > > (2) automatic fallback upon ttl expiry > > > > > > > > > > > > > > Which one to pick is deployment-specific. > > > > > > > > > > > > > > TTL makes sense only for (2). > > > > > > > > > > > > I don't think (2) is required, HTTP does not support (2) for > > > > > > Temporary > > > > > > re- direct (see https://tools.ietf.org/html/rfc7285#section-8.5= .3). > > > > > > > > > > > > > > > > [Jon] in the general potential overloading case of a specific > > > > > DOTS server, to redirect a DOTS client to an alternative DOTS > > > > > server for a period of > > > > time > > > > > makes sense to me - and then the DOTS client can then come back > > > > > again. So, to me, [2] is a valid option. > > > > > > > > > > [Med] The comparison with 307 is not accurate because that code > > > > > assumes the > > > > > following: > > > > > > > > > > The 307 (Temporary Redirect) status code indicates that the ta= rget > > > > > resource resides temporarily under a different URI and the > > > > > user > > agent > > > > > MUST NOT change the request method if it performs an automatic > > > > > redirection to that URI. Since the redirection can change > > > > > over > > time, > > > > > the client ought to continue using the original effective > > > > > request URI > > > > > > > > > > > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > > ^^^^ > > > > > for future requests. > > > > > ^^^^^^^^^^^^^^^^^^^ > > > > > > > > > > Supplying the TTL is the only way to master the automatic fall > > > > > back while avoiding contacting the "normal" server during the > > > > > "temporary > > > redirect'. > > > > > > > > > > [Jon] Agreed. > > > > > > > > If TTL expires, DOTS client cannot be re-directed when DDOS attack > > > > is > > active. > > > > If a DOTS client does not honor the TTL value and continues to use > > > > the alternate server, the server should explicitly re-direct the > > > > client and if the client still continues to use the DOTS server, > > > > it should disconnect the (D)TLS session. > > > > > > > > -Tiru > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots From nobody Tue Apr 10 02:22:00 2018 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 B7C4712D941 for ; Tue, 10 Apr 2018 02:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 PWdhM-RbcApQ for ; Tue, 10 Apr 2018 02:21:46 -0700 (PDT) Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B699B12E03E for ; Tue, 10 Apr 2018 02:21:44 -0700 (PDT) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 61AC1207D5; Tue, 10 Apr 2018 11:21:43 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.13]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 425B21A00A8; Tue, 10 Apr 2018 11:21:43 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6D.corporate.adroot.infra.ftgroup ([fe80::54f9:a6c3:c013:cbc7%19]) with mapi id 14.03.0382.000; Tue, 10 Apr 2018 11:21:43 +0200 From: To: Jon Shallow , "Konda, Tirumaleswar Reddy" , "dots@ietf.org" Thread-Topic: [Dots] Signal Channel - 300 Redirected Signaling Thread-Index: AQIamFCo/JtwOnwhldffQNYnbiNPYAIQjxxBAf1MOQMBSJYqjAHHGFsmAZdTXv0BiMwQpAGAwQaNow4kFOCAAA/BAA== Date: Tue, 10 Apr 2018 09:21:42 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DEFB382@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93302DEFA4A0@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEFA561@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <029b01d3d042$fa319a10$ee94ce30$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEFB0C8@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEFB132@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <001a01d3d0ab$5bd6dfb0$13849f10$@jpshallow.com> In-Reply-To: <001a01d3d0ab$5bd6dfb0$13849f10$@jpshallow.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling 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, 10 Apr 2018 09:21:51 -0000 Hi Jon, Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > Envoy=E9=A0: mardi 10 avril 2018 11:07 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; dots@ietf.o= rg > Objet=A0: RE: [Dots] Signal Channel - 300 Redirected Signaling >=20 > Hi Med, >=20 > We have this in place for ping-pong limitations >=20 > If the DOTS client has been redirected to a DOTS server to which it > has already communicated with within the last five (5) minutes, it > MUST ignore the redirection and try to contact other DOTS servers > listed in the local configuration or discovered using dynamic means > such as DHCP or SRV procedures. It is RECOMMENDED that DOTS clients > support means to alert administrators about redirect loops. >=20 [Med] This one is to avoid oscillation when explicit redirects are in use.= =20 > Which I think still needs to be there. So the use of something small for > ttl is questionable. A value of 0 could be used as a "one-shot" > redirection, but how often will that in reality get used? [Med] If TTL=3D0 is provided, this means that only the request in-progress = will need to be redirected to the alternate server unless an attack is acti= ve. For example, if the redirected request is a mitigation request, the cli= ent will maintain the session with the alternate server till the attack is = mitigated. Then, it will fall back to its normal server. This behavior appl= ies whatever finite value returned in the TTL. >=20 > Regards >=20 > Jon > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > mohamed.boucadair@orange.com > Sent: 10 April 2018 08:04 > To: Konda, Tirumaleswar Reddy; Jon Shallow; dots@ietf.org > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling >=20 > Re-, >=20 > The exact value to return is on the deployment side. If a server/provider > decides that 0 or small value is to be returned (that is, redirect applie= s > only for the ongoing request), why should the spec care about this? >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Konda, > > Tirumaleswar Reddy Envoy=E9=A0: mardi 10 avril 2018 08:46 =C0=A0: BOUCA= DAIR > > Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet=A0: Re: [Dots] Signal > > Channel - 300 Redirected Signaling > > > > > -----Original Message----- > > > From: mohamed.boucadair@orange.com > > > [mailto:mohamed.boucadair@orange.com] > > > Sent: Tuesday, April 10, 2018 12:01 PM > > > To: Konda, Tirumaleswar Reddy ; > > > Jon Shallow ; dots@ietf.org > > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > Hi all, > > > > > > I think that we are converging. > > > > > > Below a text proposal which reflects the outcome of the discussion: > > > > > > =3D=3D=3D=3D=3D=3D > > > ttl: Time to live (TTL) of the alternate DOTS server, represented= as > > > an integer number of seconds. That is, the time interval that = the > > > alternate DOTS server may be cached for use by a DOTS client. > > > > > > A value of negative one (-1) indicates indefinite TTL. This va= lue > > > means that the alternate DOTS server is to be used until the > > > alternate DOTS server redirects the traffic with another 3.00 > > > response. > > > > > > If no 'ttl' is returned in a redirect response, this is equival= ent > > > to returning a 'ttl' parameter set to '-1'. > > > > > > If the alternate DOTS server TTL has expired, the DOTS client M= UST > > > use the DOTS server(s), that was provisioned using means discus= sed > > > in Section 4.1. This fall back mechanism is triggered immediat= ely > > > upon expiry of the TTL except when a DDoS attack is active. > > > > > > Requests issued by misbehaving DOTS clients which do not honor = the > > > TTL or react to explicit re-direct messages can be rejected by > > > DOTS servers. > > > > > > This is an optional attribute. > > > > Looks good. We may also want to say that 0 or too small value for ttl > > should be avoided. > > > > -Tiru > > > > > =3D=3D=3D=3D=3D=3D=3D > > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De=A0: Konda, Tirumaleswar Reddy > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > Envoy=E9=A0: mardi 10 avril 2018 07:31 =C0=A0: Jon Shallow; BOUCADA= IR > > > > Mohamed IMT/OLN; dots@ietf.org Objet=A0: RE: > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > -----Original Message----- > > > > > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > > Sent: Tuesday, April 10, 2018 2:10 AM > > > > > To: mohamed.boucadair@orange.com; Konda, Tirumaleswar Reddy > > > > > ; dots@ietf.org > > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > Hi, > > > > > > > > > > See inline [Jon] > > > > > > > > > > Regards > > > > > > > > > > Jon > > > > > > > > > > -----Original Message----- > > > > > From: mohamed.boucadair@orange.com [mailto: > > > > > mohamed.boucadair@orange.com] > > > > > Sent: 09 April 2018 13:20 > > > > > To: Konda, Tirumaleswar Reddy; Jon Shallow; dots@ietf.org > > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > Re-, > > > > > > > > > > Glad to see that we both agree to get out from the DNS comparison= . > > > > > > > > > > [Jon] Also agree. Perhaps 'ttl' should be renamed 'alt-server-tt= l'. > > > > > > > > > > Please see inline. > > > > > > > > > > Cheers, > > > > > Med > > > > > > > > > > > -----Message d'origine----- > > > > > > De=A0: Konda, Tirumaleswar Reddy > > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > Envoy=E9=A0: lundi 9 avril 2018 13:48 =C0=A0: BOUCADAIR Mohamed > > > > > > IMT/OLN; Jon Shallow; dots@ietf.org Objet=A0: RE: > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of > > > > > > > mohamed.boucadair@orange.com > > > > > > > Sent: Monday, April 9, 2018 5:12 PM > > > > > > > To: Konda, Tirumaleswar Reddy > > > > > > > ; > > > > > > > Jon Shallow ; dots@ietf.org > > > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected > > > > > > > Signaling > > > > > > > > > > > > > > Re-, > > > > > > > > > > > > > > Please see inline. > > > > > > > > > > > > > > Cheers, > > > > > > > Med > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Dots > > > > > > > > [mailto:dots-bounces@ietf.org] De la part de Konda, > > > > > > > > Tirumaleswar Reddy Envoy=E9=A0: lundi 9 avril 2018 13:29 = =C0=A0: > > > > > > > > BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet= =A0: > > > > > > > > Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: mohamed.boucadair@orange.com > > > > > > > > > [mailto:mohamed.boucadair@orange.com] > > > > > > > > > Sent: Monday, April 9, 2018 4:49 PM > > > > > > > > > To: Konda, Tirumaleswar Reddy > > > > > > > > > ; > > > > > > > > > Jon Shallow ; dots@ietf.org > > > > > > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected > > > > > > > > > Signaling > > > > > > > > > > > > > > > > > > Re-, > > > > > > > > > > > > > > > > > > Focusing on this part of your answer: > > > > > > > > > > > > > > > > > > "No, DNS TTL lifetime does not mean existing session > > > > > > > > > has to be > > > > > > > > disconnected > > > > > > > > > after the TTL expires." > > > > > > > > > > > > > > > > > > This is exactly the disconnect. We are not discussing > > > > > > > > > **DNS > > > > > > > > > TTL** but the validity time of a an alternate server as > > > > > > > > > provided in a DOTS redirect > > > > > > > > signal. > > > > > > > > > > > > > > > > When the server can explicitly re-direct the client, why > > > > > > > > provide the validity time of an alternate server ? > > > > > > > > > > > > > > [Med] Involving the alternate server is one deployment mode > > > > > > > among > > > > > others. > > > > > > > The current text allows for these two modes: > > > > > > > > > > > > > > (1) redirect upon an explicit signal > > > > > > > (2) automatic fallback upon ttl expiry > > > > > > > > > > > > > > Which one to pick is deployment-specific. > > > > > > > > > > > > > > TTL makes sense only for (2). > > > > > > > > > > > > I don't think (2) is required, HTTP does not support (2) for > > > > > > Temporary > > > > > > re- direct (see > https://tools.ietf.org/html/rfc7285#section-8.5.3). > > > > > > > > > > > > > > > > [Jon] in the general potential overloading case of a specific > > > > > DOTS server, to redirect a DOTS client to an alternative DOTS > > > > > server for a period of > > > > time > > > > > makes sense to me - and then the DOTS client can then come back > > > > > again. So, to me, [2] is a valid option. > > > > > > > > > > [Med] The comparison with 307 is not accurate because that code > > > > > assumes the > > > > > following: > > > > > > > > > > The 307 (Temporary Redirect) status code indicates that the > target > > > > > resource resides temporarily under a different URI and the > > > > > user > > agent > > > > > MUST NOT change the request method if it performs an automatic > > > > > redirection to that URI. Since the redirection can change > > > > > over > > time, > > > > > the client ought to continue using the original effective > > > > > request URI > > > > > > > > > > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > > ^^^^ > > > > > for future requests. > > > > > ^^^^^^^^^^^^^^^^^^^ > > > > > > > > > > Supplying the TTL is the only way to master the automatic fall > > > > > back while avoiding contacting the "normal" server during the > > > > > "temporary > > > redirect'. > > > > > > > > > > [Jon] Agreed. > > > > > > > > If TTL expires, DOTS client cannot be re-directed when DDOS attack > > > > is > > active. > > > > If a DOTS client does not honor the TTL value and continues to use > > > > the alternate server, the server should explicitly re-direct the > > > > client and if the client still continues to use the DOTS server, > > > > it should disconnect the (D)TLS session. > > > > > > > > -Tiru > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Tue Apr 10 02:34:18 2018 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 8A5B8127369 for ; Tue, 10 Apr 2018 02:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 IcXY6aBsPCJ2 for ; Tue, 10 Apr 2018 02:34:14 -0700 (PDT) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A173E12420B for ; Tue, 10 Apr 2018 02:34:13 -0700 (PDT) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 40L278011tz2xRS; Tue, 10 Apr 2018 11:34:12 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.34]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id CE728C0084; Tue, 10 Apr 2018 11:34:11 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6F.corporate.adroot.infra.ftgroup ([fe80::bd00:88f8:8552:3349%17]) with mapi id 14.03.0382.000; Tue, 10 Apr 2018 11:34:11 +0200 From: To: "Konda, Tirumaleswar Reddy" , "Jon Shallow" , "dots@ietf.org" Thread-Topic: [Dots] Signal Channel - 300 Redirected Signaling Thread-Index: AdPMGSyCaQQbv+vLSW+0gkDbU7HOEwAAo7xAAAH7T4AAARdqYAAhoxEAAAGQiwAAAKyNYAAF3e1QACUKCFAAAZEMQAAIeXTgAARcGhAAAoG7gAABGXwAAAAjBIAAAa5ZgAAAiReAAABpmzAAL32aAABWbPEwAAIv/gAAAPiKMAAA7T0AAACbH4AAAR48IAAD29GAAAAS23AAALmWgAAAGvzwAAE21AAAEXqFAAAR0YPwAAKsZsAAAI9wIAAAfxxQAARhbLAAALPOYA== Date: Tue, 10 Apr 2018 09:34:10 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DEFB3A2@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93302DEFA4A0@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEFA561@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <029b01d3d042$fa319a10$ee94ce30$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEFB0C8@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEFB132@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling 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, 10 Apr 2018 09:34:16 -0000 Re-, Sounds reasonable. Below a text proposal:=20 A 'alt-server-ttl' parameter set to '0' may be returned for redirecting mitigation requests. Such value means that the redirection applies only for the mitigation request in progress. Returning short 'alt-server-ttl' may adversely impact DOTS clients on slow links. Returning short values should be avoided under such conditions. Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumales= war > Reddy > Envoy=E9=A0: mardi 10 avril 2018 11:16 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org > Objet=A0: Re: [Dots] Signal Channel - 300 Redirected Signaling >=20 >=20 >=20 > > -----Original Message----- > > From: mohamed.boucadair@orange.com > > [mailto:mohamed.boucadair@orange.com] > > Sent: Tuesday, April 10, 2018 12:34 PM > > To: Konda, Tirumaleswar Reddy ; > > Jon Shallow ; dots@ietf.org > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > Re-, > > > > The exact value to return is on the deployment side. If a server/provid= er > decides > > that 0 or small value is to be returned (that is, redirect applies only= for > the > > ongoing request), why should the spec care about this? >=20 > If 0 value is returned, and the client wants to send a requests to discov= er > and configure the DOTS session configuration before sending the mitigatio= n > request, 0 value means the > client does not get to send the mitigation request. We may want to clarif= y > that with 0 TTL value, re-direct applies only for the ongoing mitigation > request and not for other type of requests. Further, too small value will > adversely impact a DOTS client on slow links, e.g. TTL value expires by t= he > time the mitigation request reaches the DOTS server after multiple retrie= s. >=20 > -Tiru >=20 > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Konda, > > > Tirumaleswar Reddy Envoy=E9=A0: mardi 10 avril 2018 08:46 =C0=A0: BOU= CADAIR > > > Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet=A0: Re: [Dots] Sign= al > > > Channel - 300 Redirected Signaling > > > > > > > -----Original Message----- > > > > From: mohamed.boucadair@orange.com > > > > [mailto:mohamed.boucadair@orange.com] > > > > Sent: Tuesday, April 10, 2018 12:01 PM > > > > To: Konda, Tirumaleswar Reddy ; > > > > Jon Shallow ; dots@ietf.org > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > Hi all, > > > > > > > > I think that we are converging. > > > > > > > > Below a text proposal which reflects the outcome of the discussion: > > > > > > > > =3D=3D=3D=3D=3D=3D > > > > ttl: Time to live (TTL) of the alternate DOTS server, represent= ed > as > > > > an integer number of seconds. That is, the time interval tha= t > the > > > > alternate DOTS server may be cached for use by a DOTS client. > > > > > > > > A value of negative one (-1) indicates indefinite TTL. This > value > > > > means that the alternate DOTS server is to be used until the > > > > alternate DOTS server redirects the traffic with another 3.00 > > > > response. > > > > > > > > If no 'ttl' is returned in a redirect response, this is > equivalent > > > > to returning a 'ttl' parameter set to '-1'. > > > > > > > > If the alternate DOTS server TTL has expired, the DOTS client > MUST > > > > use the DOTS server(s), that was provisioned using means > discussed > > > > in Section 4.1. This fall back mechanism is triggered > immediately > > > > upon expiry of the TTL except when a DDoS attack is active. > > > > > > > > Requests issued by misbehaving DOTS clients which do not hono= r > the > > > > TTL or react to explicit re-direct messages can be rejected b= y > > > > DOTS servers. > > > > > > > > This is an optional attribute. > > > > > > Looks good. We may also want to say that 0 or too small value for ttl > > > should be avoided. > > > > > > -Tiru > > > > > > > =3D=3D=3D=3D=3D=3D=3D > > > > > > > > Cheers, > > > > Med > > > > > > > > > -----Message d'origine----- > > > > > De=A0: Konda, Tirumaleswar Reddy > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > Envoy=E9=A0: mardi 10 avril 2018 07:31 =C0=A0: Jon Shallow; BOUCA= DAIR > > > > > Mohamed IMT/OLN; dots@ietf.org Objet=A0: RE: > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > -----Original Message----- > > > > > > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > > > Sent: Tuesday, April 10, 2018 2:10 AM > > > > > > To: mohamed.boucadair@orange.com; Konda, Tirumaleswar Reddy > > > > > > ; dots@ietf.org > > > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > Hi, > > > > > > > > > > > > See inline [Jon] > > > > > > > > > > > > Regards > > > > > > > > > > > > Jon > > > > > > > > > > > > -----Original Message----- > > > > > > From: mohamed.boucadair@orange.com [mailto: > > > > > > mohamed.boucadair@orange.com] > > > > > > Sent: 09 April 2018 13:20 > > > > > > To: Konda, Tirumaleswar Reddy; Jon Shallow; dots@ietf.org > > > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > Re-, > > > > > > > > > > > > Glad to see that we both agree to get out from the DNS comparis= on. > > > > > > > > > > > > [Jon] Also agree. Perhaps 'ttl' should be renamed 'alt-server- > ttl'. > > > > > > > > > > > > Please see inline. > > > > > > > > > > > > Cheers, > > > > > > Med > > > > > > > > > > > > > -----Message d'origine----- > > > > > > > De=A0: Konda, Tirumaleswar Reddy > > > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > > Envoy=E9=A0: lundi 9 avril 2018 13:48 =C0=A0: BOUCADAIR Moham= ed > > > > > > > IMT/OLN; Jon Shallow; dots@ietf.org Objet=A0: RE: > > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of > > > > > > > > mohamed.boucadair@orange.com > > > > > > > > Sent: Monday, April 9, 2018 5:12 PM > > > > > > > > To: Konda, Tirumaleswar Reddy > > > > > > > > ; > > > > > > > > Jon Shallow ; dots@ietf.org > > > > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected > > > > > > > > Signaling > > > > > > > > > > > > > > > > Re-, > > > > > > > > > > > > > > > > Please see inline. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Med > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Dots > > > > > > > > > [mailto:dots-bounces@ietf.org] De la part de Konda, > > > > > > > > > Tirumaleswar Reddy Envoy=E9=A0: lundi 9 avril 2018 13:29 = =C0=A0: > > > > > > > > > BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Obj= et=A0: > > > > > > > > > Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: mohamed.boucadair@orange.com > > > > > > > > > > [mailto:mohamed.boucadair@orange.com] > > > > > > > > > > Sent: Monday, April 9, 2018 4:49 PM > > > > > > > > > > To: Konda, Tirumaleswar Reddy > > > > > > > > > > ; > > > > > > > > > > Jon Shallow ; dots@ietf.org > > > > > > > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected > > > > > > > > > > Signaling > > > > > > > > > > > > > > > > > > > > Re-, > > > > > > > > > > > > > > > > > > > > Focusing on this part of your answer: > > > > > > > > > > > > > > > > > > > > "No, DNS TTL lifetime does not mean existing session > > > > > > > > > > has to be > > > > > > > > > disconnected > > > > > > > > > > after the TTL expires." > > > > > > > > > > > > > > > > > > > > This is exactly the disconnect. We are not discussing > > > > > > > > > > **DNS > > > > > > > > > > TTL** but the validity time of a an alternate server as > > > > > > > > > > provided in a DOTS redirect > > > > > > > > > signal. > > > > > > > > > > > > > > > > > > When the server can explicitly re-direct the client, why > > > > > > > > > provide the validity time of an alternate server ? > > > > > > > > > > > > > > > > [Med] Involving the alternate server is one deployment mode > > > > > > > > among > > > > > > others. > > > > > > > > The current text allows for these two modes: > > > > > > > > > > > > > > > > (1) redirect upon an explicit signal > > > > > > > > (2) automatic fallback upon ttl expiry > > > > > > > > > > > > > > > > Which one to pick is deployment-specific. > > > > > > > > > > > > > > > > TTL makes sense only for (2). > > > > > > > > > > > > > > I don't think (2) is required, HTTP does not support (2) for > > > > > > > Temporary > > > > > > > re- direct (see https://tools.ietf.org/html/rfc7285#section- > 8.5..3). > > > > > > > > > > > > > > > > > > > [Jon] in the general potential overloading case of a specific > > > > > > DOTS server, to redirect a DOTS client to an alternative DOTS > > > > > > server for a period of > > > > > time > > > > > > makes sense to me - and then the DOTS client can then come back > > > > > > again. So, to me, [2] is a valid option. > > > > > > > > > > > > [Med] The comparison with 307 is not accurate because that code > > > > > > assumes the > > > > > > following: > > > > > > > > > > > > The 307 (Temporary Redirect) status code indicates that the > target > > > > > > resource resides temporarily under a different URI and the > > > > > > user > > > agent > > > > > > MUST NOT change the request method if it performs an automat= ic > > > > > > redirection to that URI. Since the redirection can change > > > > > > over > > > time, > > > > > > the client ought to continue using the original effective > > > > > > request URI > > > > > > > > > > > > > > > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > > > ^^^^ > > > > > > for future requests. > > > > > > ^^^^^^^^^^^^^^^^^^^ > > > > > > > > > > > > Supplying the TTL is the only way to master the automatic fall > > > > > > back while avoiding contacting the "normal" server during the > > > > > > "temporary > > > > redirect'. > > > > > > > > > > > > [Jon] Agreed. > > > > > > > > > > If TTL expires, DOTS client cannot be re-directed when DDOS attac= k > > > > > is > > > active. > > > > > If a DOTS client does not honor the TTL value and continues to us= e > > > > > the alternate server, the server should explicitly re-direct the > > > > > client and if the client still continues to use the DOTS server, > > > > > it should disconnect the (D)TLS session. > > > > > > > > > > -Tiru > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Tue Apr 10 02:48:00 2018 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 683D6127369 for ; Tue, 10 Apr 2018 02:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 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, T_DKIMWL_WL_HIGH=-0.01, 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 9AqyOn2teV8v for ; Tue, 10 Apr 2018 02:47:54 -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 974B9124B18 for ; Tue, 10 Apr 2018 02:47: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=1523353673; 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: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-microsoft-antispam: x-ms-traffictypediagnostic:x-microsoft-antispam-prvs: x-exchange-antispam-report-test:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Office365-Filtering-Correlation-Id: X-MS-Exchange-CrossTenant-Network-Message-Id: 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=2 WT/n0NrulXEb+9mUJejEEKXBMpy3OEx0FPfpgjdX2 8=; b=HRcGS3SOJCt3JLCa6jLMlHkIFoLPzE8ofm9Cl6pLp0jG e/XGp/tcCqBiZ9GsqHPTGEUzSycKXCbyAdL07CXsI97YqG9Gg7 itS6jXfvWf6dxnvhe5riQ+Nn5IJJ+3K32ifunykm1I1eo3AHPa Gb1b9CIZDOuLmzFo0mCtd4YVGuM= Received: from DNVEXAPP1N05.corpzone.internalzone.com (DNVEXAPP1N05.corpzone.internalzone.com [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 5812_622a_5cac4422_1465_4f9f_a9ea_fb6797e71d42; Tue, 10 Apr 2018 04:47:53 -0500 Received: from DNVEXUSR1N10.corpzone.internalzone.com (10.44.48.83) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 10 Apr 2018 03:47:47 -0600 Received: from DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) by DNVEXUSR1N10.corpzone.internalzone.com (10.44.48.83) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 10 Apr 2018 03:47:46 -0600 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Tue, 10 Apr 2018 03:47:47 -0600 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 10 Apr 2018 03:47:46 -0600 Received: from DM5PR16MB1436.namprd16.prod.outlook.com (10.173.210.150) by DM5PR16MB1738.namprd16.prod.outlook.com (10.172.44.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.653.12; Tue, 10 Apr 2018 09:47:45 +0000 Received: from DM5PR16MB1436.namprd16.prod.outlook.com ([fe80::51c:2319:27b3:5250]) by DM5PR16MB1436.namprd16.prod.outlook.com ([fe80::51c:2319:27b3:5250%18]) with mapi id 15.20.0653.017; Tue, 10 Apr 2018 09:47:45 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: [Dots] Data Channel ACL fragments Thread-Index: AdPMHAMfDWFlXvb3TSeAr5MVkYUzIgAA3pEAAAKPJoAAIuTfcAADWaQAAADopUAAyEgtgAACNjegABYTlwAAEYzK0AAHIEOAAAC6rLA= Date: Tue, 10 Apr 2018 09:47:44 +0000 Message-ID: References: <016401d3cc1c$03321200$09963600$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7F97@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <01a701d3cc29$ba915b10$2fb41130$@jpshallow.com> <007501d3ccc2$b49f0b00$1ddd2100$@jpshallow.com> <021301d3cfe7$77e5cbe0$67b163a0$@jpshallow.com> <02b001d3d048$a2c68be0$e853a3a0$@jpshallow.com> <000001d3d0ab$547dec40$fd79c4c0$@jpshallow.com> In-Reply-To: <000001d3d0ab$547dec40$fd79c4c0$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [185.221.69.46] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1738; 7:lUJUln4UyFOxHyYHkKsCJBzQWhcfkjYJh2M8PMApq/ptY8Q++QPdmVwDO9p1btZb2ZrJol0h28owsDIqekjEkXQ0uPoqgA6DaFQSoMZZp6EuLOs96WeLBgW+DyeLWx6r6Nwqq8V8QwRWJEohUe7yJZZntfrNTH+VOoDpN/Bqxgm9CV06HlWoV4cRJWzHJ3BsE0Su3w25HlmMO2IejMLOO8v1goAvvv0xtdLasIQEY8OQJGlUQ505CDvlt3g9RVZY x-ms-exchange-antispam-srfa-diagnostics: SOS; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:DM5PR16MB1738; x-ms-traffictypediagnostic: DM5PR16MB1738: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(18271650672692)(21748063052155)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3002001)(3231221)(944501327)(52105095)(93006095)(93001095)(6041310)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(6072148)(201708071742011); SRVR:DM5PR16MB1738; BCL:0; PCL:0; RULEID:; SRVR:DM5PR16MB1738; x-forefront-prvs: 0638FD5066 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39860400002)(346002)(39380400002)(366004)(376002)(69234005)(32952001)(199004)(189003)(80792005)(105586002)(316002)(6506007)(2900100001)(6436002)(59450400001)(3280700002)(5250100002)(2906002)(5660300001)(102836004)(2501003)(26005)(66066001)(68736007)(106356001)(186003)(97736004)(76176011)(99286004)(14454004)(33656002)(7736002)(53936002)(54896002)(9686003)(8936002)(6116002)(790700001)(6306002)(236005)(478600001)(3846002)(486006)(7696005)(9326002)(446003)(93886005)(74316002)(11346002)(6246003)(25786009)(72206003)(110136005)(81166006)(81156014)(3660700001)(8676002)(86362001)(476003)(2201001)(55016002)(19609705001)(229853002)(53546011)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1738; H:DM5PR16MB1436.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: hNrLfNToi1xKlDlBenA9FBGY+24Q8GDKQt4rsQ9PO71uhhYI+rIDVWbq/hDqzf2L+K0E6cj+TErGn9Cj9UhLZ+CbiZCQkYyl/w8coqNlEeZU/zfaKxphFCTyZ641PKvckqKTz7lzjIp3Njd3Lg+cF+JMhj51FVg8AyU6qBx7V0718RqEGjUXYna4RgS27QUxcN6qq32kLHkpvDECYx7cendM0czR+E8PGUuQ9edBqzg+LnPVH4nj+1esh1h1+Ig0yGCxaAfw1GxlDgill7GSsetRbWskGkzG1F2WIuB601o7K+zHWDxpH99PuzKlKGeYYvd0e/lR9JTrnCDfnX1Yt4KjAwZbLs+8ZldVd/R5smIFHwnRUn95kc90AqpR7mdIZefz0q4xwiZqi6/PnMqUjS1Mk99sg6uTK1ZHzDN/YGc= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB14363A5B24501ED8ABFB0903EABE0DM5PR16MB1436namp_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: c1e703c9-d154-4afb-5752-08d59ec81c6f X-MS-Exchange-CrossTenant-Network-Message-Id: c1e703c9-d154-4afb-5752-08d59ec81c6f X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2018 09:47:44.9249 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1738 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 <6260> : inlines <6554> : streams <1783608> : uri <2623027> Archived-At: Subject: Re: [Dots] Data Channel ACL fragments 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, 10 Apr 2018 09:47:57 -0000 --_000_DM5PR16MB14363A5B24501ED8ABFB0903EABE0DM5PR16MB1436namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jon, Please see inline [TR2] From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Tuesday, April 10, 2018 2:37 PM To: Konda, Tirumaleswar Reddy ; mohamed= .boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] Data Channel ACL fragments Hi Tiru, See inline Jon3] Regards Jon From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Konda@mcafee.com= ] Sent: 10 April 2018 07:10 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] Data Channel ACL fragments [Jon2] The "flags->fragment" definition is ambiguous for an ACE (but valid = as to whether to allow a packet to get fragmented or not - is that really a= ACE?) which I would like to use. [TR] I don't get it. What purpose does it serve to create a ACE rule using = "fragment" bit ? [Jon3] Agreed - This definition has not been thought through for an ACE. I= think they have just emulated the DF bit in RFC791 as this general flags d= efinition is the same as for the flags in RFC791. [TR2] You may want to inform the authors of netmod-acl draft, surprisingly = BGP flowspec also uses "fragment" bit. "Flags->more" definition covers all fragments but the last fragment. "Offse= t" is unfortunately not a range, but otherwise would get used for the final= fragment. ~jon2 [TR] It looks like two ACE entries are required to drop all the fragments (= "flags->more" set to 1 in the first ACE and "flags->more" set to 0 in the s= econd ACE). How to use the "Offset" field for the final fragment ? [Jon3] I read "flags-more" to refer to the IP_MF in the IP header (RFC791 M= F or more-fragments flag). This is set for all fragments apart from the fi= nal (as in last part of packet, not the order in which they are sent - fort= unately that early decision to send them in the wrong order was phased out,= but still there in some legacy systems!) [TR2] Yes, why can't "flags->more" be set to 0 as one ACE entry to drop the= final fragment along with "flags->more" set to 1 to drop the first fragmen= t as another ACE entry so as to drop all fragments to the target ? -Tiru [Jon3] But as the final fragment of the sequence could have any offset, the= use of the offset field is not that helpful here. Even if we do go with o= ur DOTS fragments definition (but widened to cover all fragments), we still= cannot generate a netmod-acl entry for onward processing by an upstream mi= tigator. [Jon3] FYI, for Juniper, you just need to set 'first-fragment' and 'is-frag= ment' in their ACL. BGP FlowSpec does support fragmentation detection prop= erly (RFC5575 Type 12 Fragment). -Tiru --_000_DM5PR16MB14363A5B24501ED8ABFB0903EABE0DM5PR16MB1436namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jon,

&nbs= p;

Please se= e inline [TR2]

 

From:<= /span> Jon Shallow [mailto:s= upjps-ietf@jpshallow.com]
Sent: Tuesday, April 10, 2018 2:37 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; mohamed.boucadair@orange.com; dots@ietf.org
Subject: RE: [Dots] Data Channel ACL fragments

 

Hi Tiru= ,

&n= bsp;

See inl= ine Jon3]

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Kon= da@mcafee.com]
Sent: 10 April 2018 07:10
To: Jon Shallow; moh= amed.boucadair@orange.com; dots@ietf.org
Subject: RE: [Dots] Data Channel ACL fragments

 

[Jon2] The “flag= s->fragment” definition is ambiguous for an ACE (but valid as to w= hether to allow a packet to get fragmented or not – is that really a = ACE?) which I would like to use. 

 

[TR] I don’t get= it. What purpose does it serve to create a ACE rule using “fragment&= #8221; bit ?

[Jon3] Agreed – = This definition has not been thought through for an ACE.  I think they= have just emulated the DF bit in RFC791 as this general flags definition i= s the same as for the flags in RFC791.

 

[TR2] You may want to inform the authors of netmod-a= cl draft, surprisingly BGP flowspec also uses “fragment” bit.

 

“Flags->more&= #8221; definition covers all fragments but the last fragment. “Offset= ” is unfortunately not a range, but otherwise would get used for the = final fragment.

~jon2

 

[TR] It looks like two= ACE entries are required to drop all the fragments (“flags->more&= #8221; set to 1 in the first ACE and “flags->more” set to 0 = in the second ACE). How to use the “Offset”  field for the= final fragment ?

 

[Jon3] I read “f= lags-more” to refer to the IP_MF in the IP header (RFC791 MF or more-= fragments flag).  This is set for all fragments apart from the final (= as in last part of packet, not the order in which they are sent – fortunately that early decision to send them in the wrong= order was phased out, but still there in some legacy systems!)<= /span>

 

[TR2] Yes, why can’t “flags->moreR= 21; be set to 0 as one ACE entry to drop the final fragment along with R= 20;flags->more” set to 1 to drop the first fragment as another ACE= entry so as to drop all fragments to the target ?

 

-Tiru

 

[Jon3] But as the fina= l fragment of the sequence could have any offset, the use of the offset fie= ld is not that helpful here.  Even if we do go with our DOTS fragments= definition (but widened to cover all fragments), we still cannot generate a netmod-acl entry for onward processing by an up= stream mitigator.

 

[Jon3] FYI, for Junipe= r, you just need to set ‘first-fragment’ and ‘is-fragment= ’ in their ACL.  BGP FlowSpec does support fragmentation detecti= on properly (RFC5575 Type 12 Fragment).

 

 

-Tiru

--_000_DM5PR16MB14363A5B24501ED8ABFB0903EABE0DM5PR16MB1436namp_-- From nobody Tue Apr 10 02:50:57 2018 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 4E106127369 for ; Tue, 10 Apr 2018 02:50:55 -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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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 qJXQzN27G0O0 for ; Tue, 10 Apr 2018 02:50:52 -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 7CD22127599 for ; Tue, 10 Apr 2018 02:50:52 -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=1523353851; 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: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-microsoft-antispam: x-ms-traffictypediagnostic:x-microsoft-antispam-prvs: x-exchange-antispam-report-test:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Office365-Filtering-Correlation-Id:X-MS-Exchange-CrossTenant-Network-Message-Id: 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=5 92xUK+Lxufyxh+3X0iItAGHD1LV63NaqgCYgrcndo 8=; b=JlZlWeqpUQERzUR0srLY+sdxHlqLF0ij/lNbSVOkyI1r PEL26Eijc6UiXCHpTXcUS2VizOu5uUG55aAObhlJj73OadYsD3 MnpDtjf4q3dabRrETez2KTwxjfn962t2/wG3SqQH9ALwRQIBoR OzK7Wh6Z0KezyeqhHroxH4qXKlg= Received: from DNVEXAPP1N05.corpzone.internalzone.com (DNVEXAPP1N05.corpzone.internalzone.com [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 5837_17ed_27bef915_59e5_49b7_acf5_84ea5f775fdf; Tue, 10 Apr 2018 04:50:51 -0500 Received: from DNVEXUSR1N10.corpzone.internalzone.com (10.44.48.83) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 10 Apr 2018 03:50:35 -0600 Received: from DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) by DNVEXUSR1N10.corpzone.internalzone.com (10.44.48.83) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 10 Apr 2018 03:50:34 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Tue, 10 Apr 2018 03:50:34 -0600 Received: from NAM02-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.1347.2; Tue, 10 Apr 2018 03:50:33 -0600 Received: from DM5PR16MB1436.namprd16.prod.outlook.com (10.173.210.150) by DM5PR16MB1738.namprd16.prod.outlook.com (10.172.44.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.653.12; Tue, 10 Apr 2018 09:50:32 +0000 Received: from DM5PR16MB1436.namprd16.prod.outlook.com ([fe80::51c:2319:27b3:5250]) by DM5PR16MB1436.namprd16.prod.outlook.com ([fe80::51c:2319:27b3:5250%18]) with mapi id 15.20.0653.017; Tue, 10 Apr 2018 09:50:32 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Signal Channel - 300 Redirected Signaling Thread-Index: AdPMGSyCaQQbv+vLSW+0gkDbU7HOEwAAo7xAAAH7T4AAARdqYAAhoxEAAAGQiwAAAKyNYAAF3e1QACUKCFAAAZEMQAAIeXTgAARcGhAAAoG7gAABGXwAAAAjBIAAAa5ZgAAAiReAAABpmzAAL32aAABWbPEwAAIv/gAAAPiKMAAA7T0AAACbH4AAAR48IAAD29GAAAAS23AAALmWgAAAGvzwAAE21AAAEXqFAAAR0YPwAAKsZsAAAI9wIAAAfxxQAARhbLAAALPOYAAA4kMA Date: Tue, 10 Apr 2018 09:50:32 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93302DEFA4A0@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEFA561@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <029b01d3d042$fa319a10$ee94ce30$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEFB0C8@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEFB132@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEFB3A2@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DEFB3A2@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [185.221.69.46] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1738; 7:3ELd00yvpFkRmo3/6xc/8qmI1DRD3v0kDU496SsHJUlI3DUDZi0LwmAkQuUQVGh7eAFlYFpRb7x/tMqYxRNCRa+i064psIpWEFErlZb57nEyY3nOzTKQ+T9DB8mSYCF4F26nd4X6zkdZfi9f53VuGMBClPaDKScRrgnHCmh29io/IPKe2uqL0TEtZhBW2gDnjKFnnkVclkYnSi+HrBL/p4i3ANT0Jvl8y/Gb1ANFp5o7+ncc5jXOUDHu8X81eNy1 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:DM5PR16MB1738; x-ms-traffictypediagnostic: DM5PR16MB1738: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(18271650672692)(123452027830198)(15185016700835); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3002001)(3231221)(944501327)(52105095)(93006095)(93001095)(6041310)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(6072148)(201708071742011); SRVR:DM5PR16MB1738; BCL:0; PCL:0; RULEID:; SRVR:DM5PR16MB1738; x-forefront-prvs: 0638FD5066 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39860400002)(346002)(39380400002)(366004)(376002)(55784002)(53754006)(13464003)(32952001)(199004)(189003)(51444003)(80792005)(105586002)(316002)(6506007)(2900100001)(6436002)(59450400001)(3280700002)(5250100002)(2906002)(5660300001)(102836004)(2501003)(26005)(66066001)(68736007)(106356001)(186003)(97736004)(76176011)(99286004)(14454004)(33656002)(305945005)(7736002)(53936002)(9686003)(8936002)(6116002)(966005)(6306002)(478600001)(3846002)(486006)(7696005)(446003)(93886005)(74316002)(11346002)(6246003)(25786009)(561944003)(72206003)(110136005)(81166006)(81156014)(3660700001)(8676002)(86362001)(476003)(55016002)(229853002)(53546011)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1738; H:DM5PR16MB1436.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: dqnzU9SPxRPfBOqRY49egjq6RwfbiULAji3Ohfx05G1022JatIpACTTftAzbfOtC7lKtVDwHQm9pD2Kl3U8eCS89OtBR7K6qMxxCX19H1/Hgu687EUWaKz3jqxPESFc2qzGpAmZNK6gAo4NwRXBlSPkl4kKv153ski9c18JcZbNF++mDpFZI+g0g40e3H+UivTjMUYcgCEpFtr8BtRqfj2KuGc8oEb7MTFlpkz30KqlfR/jlWuboKMCbBAl22Kdr9BGOoWvktMn7drGBW3uoQwQML2fCW0LlZ07W8RLrAo3p8Hi2rwABB/g6F1qsfPOvePDkPuMFv1Y1YSnaCpB7924TH7jiB0DcA80KkYNHhY6ZV40Yl8k3N9gMZsEEOAD36k4/05zORSRx+YRpejpoChKf9tszKPOqBHY05Ypvpbk= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: b323bbfe-d2d5-4ce7-9ea8-08d59ec88062 X-MS-Exchange-CrossTenant-Network-Message-Id: b323bbfe-d2d5-4ce7-9ea8-08d59ec88062 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2018 09:50:32.6450 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1738 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 <6260> : inlines <6554> : streams <1783608> : uri <2623029> Archived-At: Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling 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, 10 Apr 2018 09:50:55 -0000 > -----Original Message----- > From: mohamed.boucadair@orange.com > [mailto:mohamed.boucadair@orange.com] > Sent: Tuesday, April 10, 2018 3:04 PM > To: Konda, Tirumaleswar Reddy ; > Jon Shallow ; dots@ietf.org > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling >=20 > Re-, >=20 > Sounds reasonable. Below a text proposal: >=20 > A 'alt-server-ttl' parameter set to '0' may be returned for > redirecting mitigation requests. Such value means that the > redirection applies only for the mitigation request in progress. > Returning short 'alt-server-ttl' may adversely impact DOTS clients > on slow links. Returning short values should be avoided under > such conditions. Thanks, Med. Update looks good. Cheers, -Tiru >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Konda, > > Tirumaleswar Reddy Envoy=E9=A0: mardi 10 avril 2018 11:16 =C0=A0: BOUCA= DAIR > > Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet=A0: Re: [Dots] Signal > > Channel - 300 Redirected Signaling > > > > > > > > > -----Original Message----- > > > From: mohamed.boucadair@orange.com > > > [mailto:mohamed.boucadair@orange.com] > > > Sent: Tuesday, April 10, 2018 12:34 PM > > > To: Konda, Tirumaleswar Reddy ; > > > Jon Shallow ; dots@ietf.org > > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > Re-, > > > > > > The exact value to return is on the deployment side. If a > > > server/provider > > decides > > > that 0 or small value is to be returned (that is, redirect applies > > > only for > > the > > > ongoing request), why should the spec care about this? > > > > If 0 value is returned, and the client wants to send a requests to > > discover and configure the DOTS session configuration before sending > > the mitigation request, 0 value means the client does not get to send > > the mitigation request. We may want to clarify that with 0 TTL value, > > re-direct applies only for the ongoing mitigation request and not for > > other type of requests. Further, too small value will adversely impact > > a DOTS client on slow links, e.g. TTL value expires by the time the > > mitigation request reaches the DOTS server after multiple retries. > > > > -Tiru > > > > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Konda, > > > > Tirumaleswar Reddy Envoy=E9=A0: mardi 10 avril 2018 08:46 =C0=A0: > > > > BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet=A0: Re: > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > -----Original Message----- > > > > > From: mohamed.boucadair@orange.com > > > > > [mailto:mohamed.boucadair@orange.com] > > > > > Sent: Tuesday, April 10, 2018 12:01 PM > > > > > To: Konda, Tirumaleswar Reddy > > > > > ; > > > > > Jon Shallow ; dots@ietf.org > > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > Hi all, > > > > > > > > > > I think that we are converging. > > > > > > > > > > Below a text proposal which reflects the outcome of the discussio= n: > > > > > > > > > > =3D=3D=3D=3D=3D=3D > > > > > ttl: Time to live (TTL) of the alternate DOTS server, > > > > > represented > > as > > > > > an integer number of seconds. That is, the time interval > > > > > that > > the > > > > > alternate DOTS server may be cached for use by a DOTS clien= t. > > > > > > > > > > A value of negative one (-1) indicates indefinite TTL. > > > > > This > > value > > > > > means that the alternate DOTS server is to be used until th= e > > > > > alternate DOTS server redirects the traffic with another 3.= 00 > > > > > response. > > > > > > > > > > If no 'ttl' is returned in a redirect response, this is > > equivalent > > > > > to returning a 'ttl' parameter set to '-1'. > > > > > > > > > > If the alternate DOTS server TTL has expired, the DOTS > > > > > client > > MUST > > > > > use the DOTS server(s), that was provisioned using means > > discussed > > > > > in Section 4.1. This fall back mechanism is triggered > > immediately > > > > > upon expiry of the TTL except when a DDoS attack is active. > > > > > > > > > > Requests issued by misbehaving DOTS clients which do not > > > > > honor > > the > > > > > TTL or react to explicit re-direct messages can be rejected= by > > > > > DOTS servers. > > > > > > > > > > This is an optional attribute. > > > > > > > > Looks good. We may also want to say that 0 or too small value for > > > > ttl should be avoided. > > > > > > > > -Tiru > > > > > > > > > =3D=3D=3D=3D=3D=3D=3D > > > > > > > > > > Cheers, > > > > > Med > > > > > > > > > > > -----Message d'origine----- > > > > > > De=A0: Konda, Tirumaleswar Reddy > > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > Envoy=E9=A0: mardi 10 avril 2018 07:31 =C0=A0: Jon Shallow; BOU= CADAIR > > > > > > Mohamed IMT/OLN; dots@ietf.org Objet=A0: RE: > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > > > > Sent: Tuesday, April 10, 2018 2:10 AM > > > > > > > To: mohamed.boucadair@orange.com; Konda, Tirumaleswar Reddy > > > > > > > ; dots@ietf.org > > > > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected > > > > > > > Signaling > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > See inline [Jon] > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: mohamed.boucadair@orange.com [mailto: > > > > > > > mohamed.boucadair@orange.com] > > > > > > > Sent: 09 April 2018 13:20 > > > > > > > To: Konda, Tirumaleswar Reddy; Jon Shallow; dots@ietf.org > > > > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected > > > > > > > Signaling > > > > > > > > > > > > > > Re-, > > > > > > > > > > > > > > Glad to see that we both agree to get out from the DNS compar= ison. > > > > > > > > > > > > > > [Jon] Also agree. Perhaps 'ttl' should be renamed > > > > > > > 'alt-server- > > ttl'. > > > > > > > > > > > > > > Please see inline. > > > > > > > > > > > > > > Cheers, > > > > > > > Med > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Konda, Tirumaleswar Redd= y > > > > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > > > Envoy=E9=A0: lundi 9 avril 2018 13:48 =C0=A0: BOUCADAIR Moh= amed > > > > > > > > IMT/OLN; Jon Shallow; dots@ietf.org Objet=A0: RE: > > > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of > > > > > > > > > mohamed.boucadair@orange.com > > > > > > > > > Sent: Monday, April 9, 2018 5:12 PM > > > > > > > > > To: Konda, Tirumaleswar Reddy > > > > > > > > > ; > > > > > > > > > Jon Shallow ; dots@ietf.org > > > > > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected > > > > > > > > > Signaling > > > > > > > > > > > > > > > > > > Re-, > > > > > > > > > > > > > > > > > > Please see inline. > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > Med > > > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Dots > > > > > > > > > > [mailto:dots-bounces@ietf.org] De la part de Konda, > > > > > > > > > > Tirumaleswar Reddy Envoy=E9=A0: lundi 9 avril 2018 13:2= 9 =C0=A0: > > > > > > > > > > BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org > Objet=A0: > > > > > > > > > > Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: mohamed.boucadair@orange.com > > > > > > > > > > > [mailto:mohamed.boucadair@orange.com] > > > > > > > > > > > Sent: Monday, April 9, 2018 4:49 PM > > > > > > > > > > > To: Konda, Tirumaleswar Reddy > > > > > > > > > > > ; > > > > > > > > > > > Jon Shallow ; > > > > > > > > > > > dots@ietf.org > > > > > > > > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected > > > > > > > > > > > Signaling > > > > > > > > > > > > > > > > > > > > > > Re-, > > > > > > > > > > > > > > > > > > > > > > Focusing on this part of your answer: > > > > > > > > > > > > > > > > > > > > > > "No, DNS TTL lifetime does not mean existing > > > > > > > > > > > session has to be > > > > > > > > > > disconnected > > > > > > > > > > > after the TTL expires." > > > > > > > > > > > > > > > > > > > > > > This is exactly the disconnect. We are not > > > > > > > > > > > discussing **DNS > > > > > > > > > > > TTL** but the validity time of a an alternate server > > > > > > > > > > > as provided in a DOTS redirect > > > > > > > > > > signal. > > > > > > > > > > > > > > > > > > > > When the server can explicitly re-direct the client, > > > > > > > > > > why provide the validity time of an alternate server ? > > > > > > > > > > > > > > > > > > [Med] Involving the alternate server is one deployment > > > > > > > > > mode among > > > > > > > others. > > > > > > > > > The current text allows for these two modes: > > > > > > > > > > > > > > > > > > (1) redirect upon an explicit signal > > > > > > > > > (2) automatic fallback upon ttl expiry > > > > > > > > > > > > > > > > > > Which one to pick is deployment-specific. > > > > > > > > > > > > > > > > > > TTL makes sense only for (2). > > > > > > > > > > > > > > > > I don't think (2) is required, HTTP does not support (2) > > > > > > > > for Temporary > > > > > > > > re- direct (see > > > > > > > > https://tools.ietf.org/html/rfc7285#section- > > 8.5..3). > > > > > > > > > > > > > > > > > > > > > > [Jon] in the general potential overloading case of a > > > > > > > specific DOTS server, to redirect a DOTS client to an > > > > > > > alternative DOTS server for a period of > > > > > > time > > > > > > > makes sense to me - and then the DOTS client can then come > > > > > > > back again. So, to me, [2] is a valid option. > > > > > > > > > > > > > > [Med] The comparison with 307 is not accurate because that > > > > > > > code assumes the > > > > > > > following: > > > > > > > > > > > > > > The 307 (Temporary Redirect) status code indicates that > > > > > > > the > > target > > > > > > > resource resides temporarily under a different URI and > > > > > > > the user > > > > agent > > > > > > > MUST NOT change the request method if it performs an autom= atic > > > > > > > redirection to that URI. Since the redirection can > > > > > > > change over > > > > time, > > > > > > > the client ought to continue using the original effective > > > > > > > request URI > > > > > > > > > > > > > > > > > > > > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > > > > ^^^^ > > > > > > > for future requests. > > > > > > > ^^^^^^^^^^^^^^^^^^^ > > > > > > > > > > > > > > Supplying the TTL is the only way to master the automatic > > > > > > > fall back while avoiding contacting the "normal" server > > > > > > > during the "temporary > > > > > redirect'. > > > > > > > > > > > > > > [Jon] Agreed. > > > > > > > > > > > > If TTL expires, DOTS client cannot be re-directed when DDOS > > > > > > attack is > > > > active. > > > > > > If a DOTS client does not honor the TTL value and continues to > > > > > > use the alternate server, the server should explicitly > > > > > > re-direct the client and if the client still continues to use > > > > > > the DOTS server, it should disconnect the (D)TLS session. > > > > > > > > > > > > -Tiru > > > > > > > > _______________________________________________ > > > > Dots mailing list > > > > Dots@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots From nobody Tue Apr 10 03:06:00 2018 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 A79D3124B18 for ; Tue, 10 Apr 2018 03:05:58 -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, 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 W_d8ZPC_iiPh for ; Tue, 10 Apr 2018 03:05:56 -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 35958124234 for ; Tue, 10 Apr 2018 03:05:56 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.90_1) (envelope-from ) id 1f5q9x-0004Hy-SE; Tue, 10 Apr 2018 11:05:54 +0100 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , , References: <787AE7BB302AE849A7480A190F8B93302DEFA4A0@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEFA561@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <029b01d3d042$fa319a10$ee94ce30$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEFB0C8@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEFB132@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEFB3A2@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Date: Tue, 10 Apr 2018 11:05:54 +0100 Message-ID: <005001d3d0b3$83e76620$8bb63260$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIamFCo/JtwOnwhldffQNYnbiNPYAIQjxxBAf1MOQMBSJYqjAHHGFsmAZdTXv0BiMwQpAGAwQaNAXiOSqoB8X1CYQJlDVUhot/KKpA= Content-Language: en-gb Archived-At: Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling 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, 10 Apr 2018 10:05:58 -0000 Looks good to me also. Regards Jon -----Original Message----- From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 10 April 2018 10:51 To: mohamed.boucadair@orange.com; Jon Shallow; dots@ietf.org Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling > -----Original Message----- > From: mohamed.boucadair@orange.com > [mailto:mohamed.boucadair@orange.com] > Sent: Tuesday, April 10, 2018 3:04 PM > To: Konda, Tirumaleswar Reddy ; > Jon Shallow ; dots@ietf.org > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling >=20 > Re-, >=20 > Sounds reasonable. Below a text proposal: >=20 > A 'alt-server-ttl' parameter set to '0' may be returned for > redirecting mitigation requests. Such value means that the > redirection applies only for the mitigation request in progress. > Returning short 'alt-server-ttl' may adversely impact DOTS = clients > on slow links. Returning short values should be avoided under > such conditions. Thanks, Med. Update looks good. Cheers, -Tiru >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Konda,=20 > > Tirumaleswar Reddy Envoy=E9=A0: mardi 10 avril 2018 11:16 =C0=A0: = BOUCADAIR=20 > > Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet=A0: Re: [Dots]=20 > > Signal Channel - 300 Redirected Signaling > > > > > > > > > -----Original Message----- > > > From: mohamed.boucadair@orange.com=20 > > > [mailto:mohamed.boucadair@orange.com] > > > Sent: Tuesday, April 10, 2018 12:34 PM > > > To: Konda, Tirumaleswar Reddy=20 > > > ; > > > Jon Shallow ; dots@ietf.org > > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > Re-, > > > > > > The exact value to return is on the deployment side. If a=20 > > > server/provider > > decides > > > that 0 or small value is to be returned (that is, redirect applies = > > > only for > > the > > > ongoing request), why should the spec care about this? > > > > If 0 value is returned, and the client wants to send a requests to=20 > > discover and configure the DOTS session configuration before sending = > > the mitigation request, 0 value means the client does not get to=20 > > send the mitigation request. We may want to clarify that with 0 TTL=20 > > value, re-direct applies only for the ongoing mitigation request and = > > not for other type of requests. Further, too small value will=20 > > adversely impact a DOTS client on slow links, e.g. TTL value expires = > > by the time the mitigation request reaches the DOTS server after multiple retries. > > > > -Tiru > > > > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Konda,=20 > > > > Tirumaleswar Reddy Envoy=E9=A0: mardi 10 avril 2018 08:46 = =C0=A0: > > > > BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet=A0: = Re: > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > -----Original Message----- > > > > > From: mohamed.boucadair@orange.com=20 > > > > > [mailto:mohamed.boucadair@orange.com] > > > > > Sent: Tuesday, April 10, 2018 12:01 PM > > > > > To: Konda, Tirumaleswar Reddy > > > > > ; > > > > > Jon Shallow ; dots@ietf.org > > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > Hi all, > > > > > > > > > > I think that we are converging. > > > > > > > > > > Below a text proposal which reflects the outcome of the discussion: > > > > > > > > > > =3D=3D=3D=3D=3D=3D > > > > > ttl: Time to live (TTL) of the alternate DOTS server,=20 > > > > > represented > > as > > > > > an integer number of seconds. That is, the time=20 > > > > > interval that > > the > > > > > alternate DOTS server may be cached for use by a DOTS client. > > > > > > > > > > A value of negative one (-1) indicates indefinite TTL. > > > > > This > > value > > > > > means that the alternate DOTS server is to be used until = the > > > > > alternate DOTS server redirects the traffic with another 3.00 > > > > > response. > > > > > > > > > > If no 'ttl' is returned in a redirect response, this is > > equivalent > > > > > to returning a 'ttl' parameter set to '-1'. > > > > > > > > > > If the alternate DOTS server TTL has expired, the DOTS=20 > > > > > client > > MUST > > > > > use the DOTS server(s), that was provisioned using means > > discussed > > > > > in Section 4.1. This fall back mechanism is triggered > > immediately > > > > > upon expiry of the TTL except when a DDoS attack is = active. > > > > > > > > > > Requests issued by misbehaving DOTS clients which do not = > > > > > honor > > the > > > > > TTL or react to explicit re-direct messages can be = rejected by > > > > > DOTS servers. > > > > > > > > > > This is an optional attribute. > > > > > > > > Looks good. We may also want to say that 0 or too small value=20 > > > > for ttl should be avoided. > > > > > > > > -Tiru > > > > > > > > > =3D=3D=3D=3D=3D=3D=3D > > > > > > > > > > Cheers, > > > > > Med > > > > > > > > > > > -----Message d'origine----- > > > > > > De=A0: Konda, Tirumaleswar Reddy=20 > > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > Envoy=E9=A0: mardi 10 avril 2018 07:31 =C0=A0: Jon Shallow;=20 > > > > > > BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet=A0: RE: > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > > > > Sent: Tuesday, April 10, 2018 2:10 AM > > > > > > > To: mohamed.boucadair@orange.com; Konda, Tirumaleswar=20 > > > > > > > Reddy ; dots@ietf.org > > > > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected=20 > > > > > > > Signaling > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > See inline [Jon] > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: mohamed.boucadair@orange.com [mailto: > > > > > > > mohamed.boucadair@orange.com] > > > > > > > Sent: 09 April 2018 13:20 > > > > > > > To: Konda, Tirumaleswar Reddy; Jon Shallow; dots@ietf.org > > > > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected=20 > > > > > > > Signaling > > > > > > > > > > > > > > Re-, > > > > > > > > > > > > > > Glad to see that we both agree to get out from the DNS comparison. > > > > > > > > > > > > > > [Jon] Also agree. Perhaps 'ttl' should be renamed > > > > > > > 'alt-server- > > ttl'. > > > > > > > > > > > > > > Please see inline. > > > > > > > > > > > > > > Cheers, > > > > > > > Med > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Konda, Tirumaleswar=20 > > > > > > > > Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > > > Envoy=E9=A0: lundi 9 avril 2018 13:48 =C0=A0: BOUCADAIR = Mohamed=20 > > > > > > > > IMT/OLN; Jon Shallow; dots@ietf.org Objet=A0: RE: > > > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of = > > > > > > > > > mohamed.boucadair@orange.com > > > > > > > > > Sent: Monday, April 9, 2018 5:12 PM > > > > > > > > > To: Konda, Tirumaleswar Reddy=20 > > > > > > > > > ; > > > > > > > > > Jon Shallow ; dots@ietf.org > > > > > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected=20 > > > > > > > > > Signaling > > > > > > > > > > > > > > > > > > Re-, > > > > > > > > > > > > > > > > > > Please see inline. > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > Med > > > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Dots=20 > > > > > > > > > > [mailto:dots-bounces@ietf.org] De la part de Konda,=20 > > > > > > > > > > Tirumaleswar Reddy Envoy=E9=A0: lundi 9 avril 2018 = 13:29 =C0=A0: > > > > > > > > > > BOUCADAIR Mohamed IMT/OLN; Jon Shallow;=20 > > > > > > > > > > dots@ietf.org > Objet=A0: > > > > > > > > > > Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: mohamed.boucadair@orange.com=20 > > > > > > > > > > > [mailto:mohamed.boucadair@orange.com] > > > > > > > > > > > Sent: Monday, April 9, 2018 4:49 PM > > > > > > > > > > > To: Konda, Tirumaleswar Reddy=20 > > > > > > > > > > > ; > > > > > > > > > > > Jon Shallow ;=20 > > > > > > > > > > > dots@ietf.org > > > > > > > > > > > Subject: RE: [Dots] Signal Channel - 300=20 > > > > > > > > > > > Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > Re-, > > > > > > > > > > > > > > > > > > > > > > Focusing on this part of your answer: > > > > > > > > > > > > > > > > > > > > > > "No, DNS TTL lifetime does not mean existing=20 > > > > > > > > > > > session has to be > > > > > > > > > > disconnected > > > > > > > > > > > after the TTL expires." > > > > > > > > > > > > > > > > > > > > > > This is exactly the disconnect. We are not=20 > > > > > > > > > > > discussing **DNS > > > > > > > > > > > TTL** but the validity time of a an alternate=20 > > > > > > > > > > > server as provided in a DOTS redirect > > > > > > > > > > signal. > > > > > > > > > > > > > > > > > > > > When the server can explicitly re-direct the client, = > > > > > > > > > > why provide the validity time of an alternate server = ? > > > > > > > > > > > > > > > > > > [Med] Involving the alternate server is one deployment = > > > > > > > > > mode among > > > > > > > others. > > > > > > > > > The current text allows for these two modes: > > > > > > > > > > > > > > > > > > (1) redirect upon an explicit signal > > > > > > > > > (2) automatic fallback upon ttl expiry > > > > > > > > > > > > > > > > > > Which one to pick is deployment-specific. > > > > > > > > > > > > > > > > > > TTL makes sense only for (2). > > > > > > > > > > > > > > > > I don't think (2) is required, HTTP does not support (2) = > > > > > > > > for Temporary > > > > > > > > re- direct (see > > > > > > > > https://tools.ietf.org/html/rfc7285#section- > > 8.5..3). > > > > > > > > > > > > > > > > > > > > > > [Jon] in the general potential overloading case of a=20 > > > > > > > specific DOTS server, to redirect a DOTS client to an=20 > > > > > > > alternative DOTS server for a period of > > > > > > time > > > > > > > makes sense to me - and then the DOTS client can then come = > > > > > > > back again. So, to me, [2] is a valid option. > > > > > > > > > > > > > > [Med] The comparison with 307 is not accurate because that = > > > > > > > code assumes the > > > > > > > following: > > > > > > > > > > > > > > The 307 (Temporary Redirect) status code indicates that = > > > > > > > the > > target > > > > > > > resource resides temporarily under a different URI and=20 > > > > > > > the user > > > > agent > > > > > > > MUST NOT change the request method if it performs an automatic > > > > > > > redirection to that URI. Since the redirection can=20 > > > > > > > change over > > > > time, > > > > > > > the client ought to continue using the original=20 > > > > > > > effective request URI > > > > > > > > > > > > > > > > > > > > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > > > > ^^^^ > > > > > > > for future requests. > > > > > > > ^^^^^^^^^^^^^^^^^^^ > > > > > > > > > > > > > > Supplying the TTL is the only way to master the automatic=20 > > > > > > > fall back while avoiding contacting the "normal" server=20 > > > > > > > during the "temporary > > > > > redirect'. > > > > > > > > > > > > > > [Jon] Agreed. > > > > > > > > > > > > If TTL expires, DOTS client cannot be re-directed when DDOS=20 > > > > > > attack is > > > > active. > > > > > > If a DOTS client does not honor the TTL value and continues=20 > > > > > > to use the alternate server, the server should explicitly=20 > > > > > > re-direct the client and if the client still continues to=20 > > > > > > use the DOTS server, it should disconnect the (D)TLS = session. > > > > > > > > > > > > -Tiru > > > > > > > > _______________________________________________ > > > > Dots mailing list > > > > Dots@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Tue Apr 10 03:09:28 2018 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 4F3CB127275 for ; Tue, 10 Apr 2018 03:09:27 -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, 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 RujPicbCMOpc for ; Tue, 10 Apr 2018 03:09:25 -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 DEF5F124B18 for ; Tue, 10 Apr 2018 03:09:24 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.90_1) (envelope-from ) id 1f5pFS-0004EN-8E; Tue, 10 Apr 2018 10:07:31 +0100 From: "Jon Shallow" To: , "Konda, Tirumaleswar Reddy" , References: <787AE7BB302AE849A7480A190F8B93302DEFA4A0@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEFA561@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <029b01d3d042$fa319a10$ee94ce30$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEFB0C8@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEFB132@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DEFB132@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Tue, 10 Apr 2018 10:07:18 +0100 Message-ID: <001a01d3d0ab$5bd6dfb0$13849f10$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIamFCo/JtwOnwhldffQNYnbiNPYAIQjxxBAf1MOQMBSJYqjAHHGFsmAZdTXv0BiMwQpAGAwQaNow4kFOA= Content-Language: en-gb Archived-At: Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling 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, 10 Apr 2018 10:09:27 -0000 Hi Med, We have this in place for ping-pong limitations=20 If the DOTS client has been redirected to a DOTS server to which it has already communicated with within the last five (5) minutes, it MUST ignore the redirection and try to contact other DOTS servers listed in the local configuration or discovered using dynamic means such as DHCP or SRV procedures. It is RECOMMENDED that DOTS clients support means to alert administrators about redirect loops. Which I think still needs to be there. So the use of something small = for ttl is questionable. A value of 0 could be used as a "one-shot" redirection, but how often will that in reality get used? Regards Jon -----Original Message----- From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 10 April 2018 08:04 To: Konda, Tirumaleswar Reddy; Jon Shallow; dots@ietf.org Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling Re-, The exact value to return is on the deployment side. If a = server/provider decides that 0 or small value is to be returned (that is, redirect = applies only for the ongoing request), why should the spec care about this? Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Konda,=20 > Tirumaleswar Reddy Envoy=E9=A0: mardi 10 avril 2018 08:46 =C0=A0: = BOUCADAIR=20 > Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet=A0: Re: [Dots] = Signal=20 > Channel - 300 Redirected Signaling >=20 > > -----Original Message----- > > From: mohamed.boucadair@orange.com > > [mailto:mohamed.boucadair@orange.com] > > Sent: Tuesday, April 10, 2018 12:01 PM > > To: Konda, Tirumaleswar Reddy ; > > Jon Shallow ; dots@ietf.org > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > Hi all, > > > > I think that we are converging. > > > > Below a text proposal which reflects the outcome of the discussion: > > > > =3D=3D=3D=3D=3D=3D > > ttl: Time to live (TTL) of the alternate DOTS server, = represented as > > an integer number of seconds. That is, the time interval that = the > > alternate DOTS server may be cached for use by a DOTS client. > > > > A value of negative one (-1) indicates indefinite TTL. This = value > > means that the alternate DOTS server is to be used until the > > alternate DOTS server redirects the traffic with another 3.00 > > response. > > > > If no 'ttl' is returned in a redirect response, this is = equivalent > > to returning a 'ttl' parameter set to '-1'. > > > > If the alternate DOTS server TTL has expired, the DOTS client = MUST > > use the DOTS server(s), that was provisioned using means = discussed > > in Section 4.1. This fall back mechanism is triggered = immediately > > upon expiry of the TTL except when a DDoS attack is active. > > > > Requests issued by misbehaving DOTS clients which do not honor = the > > TTL or react to explicit re-direct messages can be rejected by > > DOTS servers. > > > > This is an optional attribute. >=20 > Looks good. We may also want to say that 0 or too small value for ttl=20 > should be avoided. >=20 > -Tiru >=20 > > =3D=3D=3D=3D=3D=3D=3D > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: Konda, Tirumaleswar Reddy > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > Envoy=E9=A0: mardi 10 avril 2018 07:31 =C0=A0: Jon Shallow; = BOUCADAIR=20 > > > Mohamed IMT/OLN; dots@ietf.org Objet=A0: RE: > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > -----Original Message----- > > > > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > Sent: Tuesday, April 10, 2018 2:10 AM > > > > To: mohamed.boucadair@orange.com; Konda, Tirumaleswar Reddy=20 > > > > ; dots@ietf.org > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > Hi, > > > > > > > > See inline [Jon] > > > > > > > > Regards > > > > > > > > Jon > > > > > > > > -----Original Message----- > > > > From: mohamed.boucadair@orange.com [mailto: > > > > mohamed.boucadair@orange.com] > > > > Sent: 09 April 2018 13:20 > > > > To: Konda, Tirumaleswar Reddy; Jon Shallow; dots@ietf.org > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > Re-, > > > > > > > > Glad to see that we both agree to get out from the DNS = comparison. > > > > > > > > [Jon] Also agree. Perhaps 'ttl' should be renamed = 'alt-server-ttl'. > > > > > > > > Please see inline. > > > > > > > > Cheers, > > > > Med > > > > > > > > > -----Message d'origine----- > > > > > De=A0: Konda, Tirumaleswar Reddy=20 > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > Envoy=E9=A0: lundi 9 avril 2018 13:48 =C0=A0: BOUCADAIR = Mohamed=20 > > > > > IMT/OLN; Jon Shallow; dots@ietf.org Objet=A0: RE: > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > -----Original Message----- > > > > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of=20 > > > > > > mohamed.boucadair@orange.com > > > > > > Sent: Monday, April 9, 2018 5:12 PM > > > > > > To: Konda, Tirumaleswar Reddy=20 > > > > > > ; > > > > > > Jon Shallow ; dots@ietf.org > > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected=20 > > > > > > Signaling > > > > > > > > > > > > Re-, > > > > > > > > > > > > Please see inline. > > > > > > > > > > > > Cheers, > > > > > > Med > > > > > > > > > > > > > -----Message d'origine----- De=A0: Dots=20 > > > > > > > [mailto:dots-bounces@ietf.org] De la part de Konda,=20 > > > > > > > Tirumaleswar Reddy Envoy=E9=A0: lundi 9 avril 2018 13:29 = =C0=A0: > > > > > > > BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org = Objet=A0: > > > > > > > Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: mohamed.boucadair@orange.com=20 > > > > > > > > [mailto:mohamed.boucadair@orange.com] > > > > > > > > Sent: Monday, April 9, 2018 4:49 PM > > > > > > > > To: Konda, Tirumaleswar Reddy=20 > > > > > > > > ; > > > > > > > > Jon Shallow ; dots@ietf.org > > > > > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected=20 > > > > > > > > Signaling > > > > > > > > > > > > > > > > Re-, > > > > > > > > > > > > > > > > Focusing on this part of your answer: > > > > > > > > > > > > > > > > "No, DNS TTL lifetime does not mean existing session=20 > > > > > > > > has to be > > > > > > > disconnected > > > > > > > > after the TTL expires." > > > > > > > > > > > > > > > > This is exactly the disconnect. We are not discussing=20 > > > > > > > > **DNS > > > > > > > > TTL** but the validity time of a an alternate server as=20 > > > > > > > > provided in a DOTS redirect > > > > > > > signal. > > > > > > > > > > > > > > When the server can explicitly re-direct the client, why=20 > > > > > > > provide the validity time of an alternate server ? > > > > > > > > > > > > [Med] Involving the alternate server is one deployment mode=20 > > > > > > among > > > > others. > > > > > > The current text allows for these two modes: > > > > > > > > > > > > (1) redirect upon an explicit signal > > > > > > (2) automatic fallback upon ttl expiry > > > > > > > > > > > > Which one to pick is deployment-specific. > > > > > > > > > > > > TTL makes sense only for (2). > > > > > > > > > > I don't think (2) is required, HTTP does not support (2) for=20 > > > > > Temporary > > > > > re- direct (see https://tools.ietf.org/html/rfc7285#section-8.5.3). > > > > > > > > > > > > > [Jon] in the general potential overloading case of a specific=20 > > > > DOTS server, to redirect a DOTS client to an alternative DOTS=20 > > > > server for a period of > > > time > > > > makes sense to me - and then the DOTS client can then come back=20 > > > > again. So, to me, [2] is a valid option. > > > > > > > > [Med] The comparison with 307 is not accurate because that code=20 > > > > assumes the > > > > following: > > > > > > > > The 307 (Temporary Redirect) status code indicates that the target > > > > resource resides temporarily under a different URI and the=20 > > > > user > agent > > > > MUST NOT change the request method if it performs an = automatic > > > > redirection to that URI. Since the redirection can change=20 > > > > over > time, > > > > the client ought to continue using the original effective=20 > > > > request URI > > > > > > > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > ^^^^ > > > > for future requests. > > > > ^^^^^^^^^^^^^^^^^^^ > > > > > > > > Supplying the TTL is the only way to master the automatic fall=20 > > > > back while avoiding contacting the "normal" server during the=20 > > > > "temporary > > redirect'. > > > > > > > > [Jon] Agreed. > > > > > > If TTL expires, DOTS client cannot be re-directed when DDOS attack = > > > is > active. > > > If a DOTS client does not honor the TTL value and continues to use = > > > the alternate server, the server should explicitly re-direct the=20 > > > client and if the client still continues to use the DOTS server,=20 > > > it should disconnect the (D)TLS session. > > > > > > -Tiru >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Tue Apr 10 03:14:36 2018 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 22789124B18 for ; Tue, 10 Apr 2018 03:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 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, T_DKIMWL_WL_HIGH=-0.01, 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 lgY7Kro2nBoU for ; Tue, 10 Apr 2018 03:14:30 -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 860071243FE for ; Tue, 10 Apr 2018 03:14:30 -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=1523355269; 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: dlp-product:dlp-version:dlp-reaction: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-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: 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=T j+6tLmrjFLMSmxlKRq/FmC2N2ZQirYmVGEeuaNOp6 Y=; b=Z6QyOrx4Uov+4l8dPBWk62JoNTDplEnbRKpFsLvVjyOv KMSZlGA5ZE22UTKKgUObuISyrk7cB5vj+WkkGfPF/Bm4OwuuEi 89E5LFXMRPkW7uuglu04J1IZuwS5Z+YB3HGarS93rSyKVk3+W5 o9UWDWAR+s8noCPtvtsNhXRib0w= Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 5832_41d1_64adfaea_c33c_46b2_bfe0_491836edc253; Tue, 10 Apr 2018 05:14:28 -0500 Received: from DNVEXUSR1N12.corpzone.internalzone.com (10.44.48.85) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 10 Apr 2018 04:13:27 -0600 Received: from DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) by DNVEXUSR1N12.corpzone.internalzone.com (10.44.48.85) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 10 Apr 2018 04:13:26 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Tue, 10 Apr 2018 04:13:26 -0600 Received: from NAM02-CY1-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.1347.2; Tue, 10 Apr 2018 04:13:24 -0600 Received: from DM5PR16MB1436.namprd16.prod.outlook.com (10.173.210.150) by DM5PR16MB1849.namprd16.prod.outlook.com (10.172.45.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.653.12; Tue, 10 Apr 2018 10:13:23 +0000 Received: from DM5PR16MB1436.namprd16.prod.outlook.com ([fe80::51c:2319:27b3:5250]) by DM5PR16MB1436.namprd16.prod.outlook.com ([fe80::51c:2319:27b3:5250%18]) with mapi id 15.20.0653.017; Tue, 10 Apr 2018 10:13:23 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: [Dots] IETF 101 Presentation Data Channel Issue #4 Thread-Index: AdPE/QAkDtOD9YeqSAaov9+szxQnSQAoMdfAAAKPC+AAA+QiAAAEVj7wAfiJ0YAAA7+48AABBD0AAByNZ3AAbRM0AAABj4SQAALuHIAAAB7MkAAUhSeAABEJfQAAB3/zgAABjIUw Date: Tue, 10 Apr 2018 10:13:23 +0000 Message-ID: References: <008401d3c4fd$216d0840$644718c0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF1067@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <014801d3c5b7$94c67f00$be537d00$@jpshallow.com> <009a01d3cdab$150b4c40$3f21e4c0$@jpshallow.com> <00cf01d3cdbe$24876650$6d9632f0$@jpshallow.com> <01fd01d3cfe4$a71b6580$f5523080$@jpshallow.com> <024901d3cff6$9d4beea0$d7e3cbe0$@jpshallow.com> <02c301d3d049$2f60cf20$8e226d60$@jpshallow.com> <000a01d3d0ab$55bef7c0$013ce740$@jpshallow.com> In-Reply-To: <000a01d3d0ab$55bef7c0$013ce740$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [185.221.69.46] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1849; 7:CeiBt9N1kD96q58qW3pX9PxkBBQEYVyRWrsRjkYBx3ZVnEGdUmZ6jUGcHL/XOLry0Biwo0HAoGwKzrxHX93BdQvhyicZ/4MSuF60YOR1Tx8jVMgEorcm37E6aB7zPk2fNMKG/fZDHJke5yb4s1OKYGu/ASe2PLTYmJazo8UT0cMxG3rBNURZc6X5Sm4awPuuNYRiW3e9giSBI9RCzyj5O7BZzaTz45yDkAaqI4SP0PXTs1xIf8Q7lGDWyfXZkMSn x-ms-exchange-antispam-srfa-diagnostics: SOS; X-MS-Office365-Filtering-Correlation-Id: 89f661c6-b823-40d4-ebc3-08d59ecbb183 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:DM5PR16MB1849; x-ms-traffictypediagnostic: DM5PR16MB1849: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(192374486261705)(18271650672692)(21748063052155)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231221)(944501327)(52105095)(93006095)(93001095)(10201501046)(3002001)(6041310)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:DM5PR16MB1849; BCL:0; PCL:0; RULEID:; SRVR:DM5PR16MB1849; x-forefront-prvs: 0638FD5066 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(39380400002)(396003)(366004)(376002)(346002)(32952001)(5383002)(189003)(199004)(102836004)(5250100002)(55016002)(53546011)(9686003)(476003)(236005)(80792005)(97736004)(6436002)(14454004)(54896002)(53946003)(59450400001)(2501003)(6306002)(6506007)(66066001)(7696005)(2201001)(68736007)(33656002)(105586002)(53936002)(86362001)(72206003)(229853002)(76176011)(2900100001)(106356001)(25786009)(486006)(5660300001)(93886005)(74316002)(6246003)(8936002)(7736002)(26005)(2906002)(316002)(186003)(99286004)(11346002)(446003)(19609705001)(3280700002)(3846002)(6116002)(790700001)(81166006)(81156014)(345774005)(110136005)(478600001)(8676002)(3660700001)(91024005)(85282002)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1849; H:DM5PR16MB1436.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: cSEUNyGLnqJAtt62+0DgIaZxhqNiNptOA41wsgM/JrV9K3zZm9y5cgiETV6UYQT+QLccvsZj+plteP78R+tycfiFOluAY2p3cfqmR0A0ji6hduQfDbmPx2cm74rShahq/YssfLkMtJ1JPb0P+Cnr6k7KkXHlhcR+Ur+rtiph2B/rnqtH/iiMO57moPxp+z+AJor0NLHvLiTnIu7c7/zOVXjFQZTRYFtTgVb+F6ihY76TXzS2iNPOoQtHeH+1C1xjBYs2Ye5tvC2Xt5CuO7wzmX/Jfj6fIx1zbqlbiclkwQzd0WRFnZODGaywZeDb0crxDu/LEUm2osqd/i0hKZvDcRBwIovZ17XIs9HHyWhY3g/bUpMMfqYQ4OuNJjVqyw492FP8Ex2f5KAR0fsvLQZUnb2FtvastOVHj0IUzAExozo= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB14362593B3DE185A325681F5EABE0DM5PR16MB1436namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 89f661c6-b823-40d4-ebc3-08d59ecbb183 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2018 10:13:23.5774 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1849 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 <6260> : inlines <6554> : streams <1783610> : uri <2623040> Archived-At: Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 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, 10 Apr 2018 10:14:35 -0000 --_000_DM5PR16MB14362593B3DE185A325681F5EABE0DM5PR16MB1436namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Please see inline [TR4] From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Tuesday, April 10, 2018 2:37 PM To: Konda, Tirumaleswar Reddy ; mohamed= .boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 Hi Tiru, See inline [Jon3] Regards Jon From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Monday, April 9, 2018 2:55 PM To: Konda, Tirumaleswar Reddy >; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 Hi Tiru, If a DOTS client knows the full scope of the Networks that it is allowed to= use in a ACL or mitigate request, and the DOTS server limits any update fr= om that client to the scope of Networks (with any unexpected side effects t= hat may have), then there is no difference in my mind as to whether the DOT= S clients fills in the destination-network, or the DOTS server does so on t= he DOTS client's behalf before ACL instantiation if destination-network is = not defined. [TR] The above model only works when the DOTS server and DOTS client are di= rectly communicating with each other (In the above, the DOTS server knows t= he DOTS client identity to enforce the scope but will not the DOTS client i= dentity in the presence of a client-domain DOTS gateway). [Jon1] The last para of "10. Security Considerations" states DOTS servers MUST verify that requesting DOTS clients are entitled to trigger actions on a given IP prefix. That is, only actions on IP resources that belong to the DOTS client' domain MUST be authorized by a DOTS server. The exact mechanism for the DOTS servers to validate that the target prefixes are within the scope of the DOTS client's domain is deployment-specific. [Jon1] So it makes no difference if the DOTS client happens to be an agent = part of a client-domain DOTS gateway. If the client-domain DOTS gateway is= hiding all the 'behind' clients and presenting as single client, there is = no issue. However, if the 'behind' clients are presented as 2 or more 'cui= d's by the DOTS gateway, then either the scope is per 'cuid', or if 'cdid's= are being applied by the upstream server domain DOTS gateway then on a per= 'cdid' basis if wanted. For a client behind a client domain DOTS gateway, there may be non public I= P addresses that the (DMS) client is responsible for, but these should neve= r be sent out through the DOTS gateway (and should be rejected by the DOTS = server as out of scope). There does have to be a common agreement between = DOTS client & DOTS server as to what Networks are in scope, but the DOTS cl= ient currently cannot request this from the DOTS server and has to be agree= d out of band. [TR] I don't see a new problem, even when a DOTS client sends a mitigation = request it needs to know if the targets conveyed in the mitigation request = are in its scope or not. [Jon1] but again, the DOTS server MUST verify the IP prefix is valid, so ha= s to know scope. I agree that the DOTS client (or client domain DOTS gatew= ay) needs to know (today out of band) what is the scope of what is valid to= request. The challenge comes when the DOTS server's scope is reconfigured= , but not yet updated on the DOTS client. [TR2] The scope would be first updated on the DOTS client domain and then o= n the DOTS server (e.g. IP prefix re-numbering). [Jon2] I was more thinking of a DOTS client that got missed off a list when= the DOTS server was updated. Normally though, they should be kept in sync= but which one gets updated first is uncertain to me. [TR3] If the DOTS client missed update, it will have various other problems= ; any network policy based on destination network IP/prefix will fail. DOTS= client should support mechanisms to receive the latest network configurati= on after missing critical updates because it was offline or its connectivity was lost. [Jon3] So to me, we need to add in something to the data channel protocol s= o that a DOTS client can request as to what is the network current scope it= is allowed to ask for ACL/Mitigation for. [TR3] I don't think so, you may want to look into SIG-007 requirement, it s= ays "A DOTS client may obtain the mitigation scope through direct provision= ing or through implementation-specific methods of discovery." There is no reason as to why the DOTS server cannot maintain a valid scope = of Networks that the client domain DOTS gateway is allowed to request for v= alidity checking - unless I am missing something? [TR] You are partially right, the DOTS server does not know the valid scope= of prefixes that a DOTS client behind client-domain DOTS gateway is allowe= d to request. [Jon1] Again, the last para of 10. stands here, and so the scope has to be = known by the DOTS server. [TR] Yes, but it may not know the scope of a DOTS client behind a client-do= main DOTS gateway. [Jon2] But it will know what the client-domain DOTS gateway is allowed to p= ass through in terms of Destination Network. The client-domain DOTS gatewa= y will separately need to know what Destination networks are allowed to get= out through the gateway. Troubleshooting has kept me in a job for more years than I care to remember= , anything to aid troubleshooting is what I am interested in and so totally= agree that rogue DOTS client's capabilities need to be kept under control = with suitable logging to aid diagnosis is a major plus. However in this ca= se, the implicit rule is no different to the DOTS client requesting the ful= l Networks scope in an ACL request. [TR] If the client is not authorized to request the full network scope, it = can detected by the client-domain DOTS gateway and rejects the filtering ru= le by comparing the destination-networks specified in the ACE. [Jon1] Agreed, it is the responsibility of the client domain DOTS gateway t= o only allow out valid networks that are valid within the DOTS server's sco= pe. [Jon1] Should we support a way for the client domain DOTS gateway (i.e. DO= TS client agent) to programmatically get the current valid network scope fr= om the DOTS server? [TR2] It will not solve the above problem of detecting and rejecting a roug= e (or misconfigured) DOTS client behind client domain DOTS gateway sending = ACL without specifying destination-network. [Jon2] Hmm. If the client-domain DOTS gateway is restricted in scope as to= what it is allowed to request, and a rogue client behind the gateway does = not specify a destination-network, then when the request passes through the= gateway the upstream DOTS server will only use the scope allowed for that = specific client-domain DOTS gateway. Again, it is exactly the same as if t= he rogue client was to specify the full set of allowed scope as a set of de= stination networks in terms of damage capabilities. [TR3] No, the client-domain DOTS gateway can detect and reject the ACL beca= use the rouge DOTS client has specified destination-network not under its s= cope. [Jon3] You are missing my point. Agreed that the client-domain DOTS gatewa= y must sanity check what is passed through. However, there will be a set o= f Networks that are allowed through the DOTS gateway which are within the d= efined scope of what the DOTS server allows. This "allowed through network= s" can legitimately be set by the DOTS client in destination-network, or th= e DOTS server can fill in the same set of networks in the ACL instantiation= if destination-networks was empty and the potential side effects damage ca= used will be the same. [TR] I understand, you seem to be focusing on only DDoS detectors and IDMS = acting as DOTS clients . They will be authorized to enforce ACL for the ent= ire DOTS client domain, but an application server acting as a DOTS client w= ill only be authorized to enforce ACL for the IP addresses/prefixes used by= the it and not for the entire DOTS client domain. These type of DOTS clien= ts must fill the destination-network, so the client-domain DOTS gateway can= detect and reject ACL requests populated with destination IP addresses/pre= fixes the application server does not use. -Tiru ~jon2 -Tiru ~jon1 -Tiru Regards Jon From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Konda@mcafee.com= ] Sent: 07 April 2018 06:48 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 Hi Jon, DOTS clients (intelligent DDoS mitigation system, application server) will = know the destination networks, what kind of DOTS clients will not know the = destination networks they are allowed to use ? DOTS clients could be behind client-domain DOTS gateway, DOTS server will h= ave no way to validate the DOTS client identity sending the ACE request to = determine the destination IP addresses in its scope, it will only know the = destination IP addresses in the DOTS client domain scope. Further, the implicit rule can be misused by compromised DOTS clients (e.g.= black-list good traffic to the entire DOTS client domain) and it's a trou= bleshooting nightmare to find the culprit device adversely impacting the en= tire network. Cheers, -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Friday, April 6, 2018 9:14 PM To: Konda, Tirumaleswar Reddy >; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 Hi Tiru, The DOTS server is likely to have a scope of IP addresses that are valid fo= r the client to ask for protection for based on the cuid or cdid. The DOTS client may have some knowledge of the scope IPs by some out of ban= d method, but programmatically cannot ask the server what they are. If a client specifies a destination network that is out of the valid scope = of IP addresses, then the ACE request will get rejected. The client may th= en have a challenge to work out what destination networks it is allowed to = use. How does a client set up a blacklist for all the IPS within his allowed sco= pe if it does not know what the scope is? If the client has not provided a destination network, then the DOTS server = can auto-fill in the missing information at the time of the ACE instantiati= on - and this then handles if the scope of IP addresses change. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 06 April 2018 16:19 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 I don't understand how the DOTS server/mitigation will fill it in at time o= f ACE instantiation, and why can't the DOTS client fill the destination net= work details ? -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Friday, April 6, 2018 6:58 PM To: Konda, Tirumaleswar Reddy >; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 Hi there, There is no current way to request of a DOTS Server as to what is the set o= f IP networks that a DOTS client can use either within a mitigation request= or to set up an ACL other than by "testing for ok or not ok" with lots of = different IP addresses. There is a reasonable likelihood of the scope of valid IPs from the Server'= s perspective will change over time. So, unless a DOTS client wants to con= trol a specific destination network, then my suggestion would be to leave t= he ACE destination network empty and for the DOTS Server / DOTS mitigator (= how is out of scope) to fill it in at time of ACE instantiation. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 27 March 2018 13:49 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 Please see inline [TR] From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Tuesday, March 27, 2018 4:07 PM To: Konda, Tirumaleswar Reddy >; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 Hi Tiru / Med See inline [Jon] Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 27 March 2018 09:47 To: mohamed.boucadair@orange.com; Jon = Shallow; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 I also support to mandate destination-network for immediately enforced filt= ering rules. [Jon] This can be enforced / inserted by the DOTS Server for all the destin= ation networks of the domain that the DOTS client 'belongs' to. That said,= it would be good to always have the destination network in an ACL as it ca= n be validated and cross-checked whenever the legitimate set of domain prot= ected IPs are updated. [Jon] However, what happens to the Destination network in the case of a cal= l home DOTS client that becomes a quasi DOTS server and the Destination net= works are somewhere out on the Internet? [TR] DDOS is a targeted attack, so the DOTS client can specify the destinat= ion network targeted by devices in the DOTS server domain and the DOTS serv= er can validate if the destination network is indeed targeted by its device= s. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed......boucada= ir@orange.com Sent: Tuesday, March 27, 2018 1:09 PM To: Jon Shallow >; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 Hi Jon, Thank you for the comments. Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : lundi 26 mars 2018 14:23 =C0 : dots@ietf.org Objet : [Dots] IETF 101 Presentation Data Channel Issue #4 Hi there, As per Med's presentation to the IETF 101 Issue #4: Per-Domain or Per-client Filters? * Conclusion - Filters that are activated only during mitigation time are on a per-clien= t basis * Filters are per-domain when are immediately applied "Filters are per-domain when are immediately applied" is what I have an cha= llenge with. If we have a compromised or rogue DOTS client, the simple use of something = like curl, along with the client certificates etc. can be used to generate = any ACL with activation-type :=3D 'immediate' which is then immediately app= lied for all traffic within the domain as per the above. [Med] Yes. FWIW, this attack is called out in the security considerations s= ection: "Nevertheless, an attacker who can access a DOTS client is technically capable of launching various attacks, such as: ..; o Set invalid ACL entries, which may prevent legitimate traffic from being forwarded. Likewise, invalid ACL entries may lead to forward DDoS traffic. " [Jon] Agreed that the attack is covered off in the Security section, but we= should be limiting the possibility / scope of the attack vector by enforci= ng some rules as to what is / is not allowed. Allowing a DOTS client to be= able to affect all the traffic within the domain is a huge risk to me and = should not be allowed. So, a ACL that blacklists the DNS server, or drops all port 443 traffic etc= . can easily cause all of the other clients / devices within the domain to = be taken off air. Putting the intelligence into the DOTS server to not all= ow this to happen could be a challenge. [The signal channel is much harder to compromise and affect traffic flows t= o other areas within the domain] I believe that an ACL instantiated by a DOTS client (immediate or when-miti= gating) should only apply to the DOTS client's traffic which means that the= destination-network has to be a part of the ACL, whether implicitly added = by the DOTS server, or by the DOTS client and suitably validated. [Med] Putting aside that I don't parse "DOTS client's traffic", [Jon] I was referring to all the traffic flows that a DOTS client can legit= imately request control of to the DOTS server that are within the scope of = what the DOTS client is protecting (which may or may not be the DOTS client= 's IP address). I interpret your answer as a support to this question raised for issue #4: * "Should we mandate destination-network to be present for immediate= ly enforced filters?" [Jon] See response to Tiru's Agreement above. ~Jon There is nothing to stop the DOTS server or DOTS mitigator merging common A= CLs to reduce the number of ACLs within the mitigation device. As a side note "mitigation-time" is perhaps a bad name as it implies a time= period - something like "when-mitigating" to me is clearer. [Med] Fixed in my local copy. Thank you. Regards Jon --_000_DM5PR16MB14362593B3DE185A325681F5EABE0DM5PR16MB1436namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Please se= e inline [TR4]

 

From:<= /span> Dots [mailto:dots-bou= nces@ietf.org] On Behalf Of Jon Shallow
Sent: Tuesday, April 10, 2018 2:37 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; mohamed.boucadair@orange.com; dots@ietf.org
Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Hi Tiru= ,

&n= bsp;

See inl= ine [Jon3]

&n= bsp;

Regards=

&n= bsp;

Jon

&nbs= p;

From:<= /span> Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Monday, April 9, 2018 2:55 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; mohamed.boucadair@orange.co= m; dots@ietf.org
Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Hi Tiru= ,

&n= bsp;

If a DO= TS client knows the full scope of the Networks that it is allowed to use in= a ACL or mitigate request, and the DOTS server limits any update from that= client to the scope of Networks (with any unexpected side effects that may have), then there is no difference in= my mind as to whether the DOTS clients fills in the destination-network, o= r the DOTS server does so on the DOTS client’s behalf before ACL inst= antiation if destination-network is not defined.

 

[TR] The above model only works= when the DOTS server and DOTS client are directly communicating with each = other (In the above, the DOTS server knows the DOTS client identity to enfo= rce the scope but will not the DOTS client identity in the presence of a client-domain DOTS gateway).

&n= bsp;

[Jon1] = The last para of “10. Security Considerations” states

   DOTS servers MUST verify that requesting= DOTS clients are entitled to

   trigger actions on a given IP prefix.&nb= sp; That is, only actions on IP

   resources that belong to the DOTS client= ' domain MUST be authorized

   by a DOTS server.  The exact mechan= ism for the DOTS servers to

   validate that the target prefixes are wi= thin the scope of the DOTS

 &= nbsp; client's domain is deployment-specific.

 

[Jon1] = So it makes no difference if the DOTS client happens to be an agent part of= a client-domain DOTS gateway.  If the client-domain DOTS gateway is h= iding all the ‘behind’ clients and presenting as single client, there is no issue.  However, if the ‘behind&#= 8217; clients are presented as 2 or more ‘cuid’s by the DOTS ga= teway, then either the scope is per ‘cuid’, or if ‘cdid&#= 8217;s are being applied by the upstream server domain DOTS gateway then on= a per ‘cdid’ basis if wanted.

&n= bsp;

For a c= lient behind a client domain DOTS gateway, there may be non public IP addre= sses that the (DMS) client is responsible for, but these should never be se= nt out through the DOTS gateway (and should be rejected by the DOTS server as out of scope).  There does have to = be a common agreement between DOTS client & DOTS server as to what Netw= orks are in scope, but the DOTS client currently cannot request this from t= he DOTS server and has to be agreed out of band.

 

[TR] I don’t see a new pr= oblem, even when a DOTS client sends a mitigation request it needs to know = if the targets conveyed in the mitigation request are in its scope or not.<= o:p>

&n= bsp;

[Jon1] = but again, the DOTS server MUST verify the IP prefix is valid, so has to kn= ow scope.  I agree that the DOTS client (or client domain DOTS gateway= ) needs to know (today out of band) what is the scope of what is valid to request.  The challenge comes when the = DOTS server’s scope is reconfigured, but not yet updated on the DOTS = client. 

 

[TR2] The scope would be first = updated on the DOTS client domain and then on the DOTS server (e.g. IP pref= ix re-numbering).

&n= bsp;

[Jon2] = I was more thinking of a DOTS client that got missed off a list when the DO= TS server was updated.  Normally though, they should be kept in sync b= ut which one gets updated first is uncertain to me.

 

[TR3] If the DOTS client missed= update, it will have various other problems; any network policy based on d= estination network IP/prefix will fail. DOTS client should support mechanis= ms to receive the latest network configuration after missing critical updates because it was offline or its

     &= nbsp;    connectivity was lost.

&n= bsp;

[Jon3] = So to me, we need to add in something to the data channel protocol so that = a DOTS client can request as to what is the network current scope it is all= owed to ask for ACL/Mitigation for.

 

[TR3] I don’t think so, you may want to look into SIG-007 require=
ment, it says “A DOTS client may obtain the mitigation scope t=
hrough direct provisioning or through implementation-specific methods of di=
scovery.”
 

 

There i= s no reason as to why the DOTS server cannot maintain a valid scope of Netw= orks that the client domain DOTS gateway is allowed to request for validity= checking – unless I am missing something?

 

[TR] You are partially right, t= he DOTS server does not know the valid scope of prefixes that a DOTS client= behind client-domain DOTS gateway is allowed to request.=

&n= bsp;

[Jon1] = Again, the last para of 10. stands here, and so the scope has to be known b= y the DOTS server.

 

[TR] Yes, but it may not know t= he scope of a DOTS client behind a client-domain DOTS gateway.

&n= bsp;

[Jon2] = But it will know what the client-domain DOTS gateway is allowed to pass thr= ough in terms of Destination Network.  The client-domain DOTS gateway = will separately need to know what Destination networks are allowed to get out through the gateway.

&n= bsp;

Trouble= shooting has kept me in a job for more years than I care to remember, anyth= ing to aid troubleshooting is what I am interested in and so totally agree = that rogue DOTS client’s capabilities need to be kept under control with suitable logging to aid diagnosis is a = major plus.  However in this case, the implicit rule is no different t= o the DOTS client requesting the full Networks scope in an ACL request.

 

[TR] If the client is not autho= rized to request the full network scope, it can detected by the client-doma= in DOTS gateway and rejects the filtering rule by comparing the destination= -networks

     &= nbsp;  specified in the ACE.

[Jon1] = Agreed, it is the responsibility of the client domain DOTS gateway to only = allow out valid networks that are valid within the DOTS server’s scop= e.

&n= bsp;

[Jon1] = Should we support a way for the client domain DOTS gateway  (i.e. DOTS= client agent) to programmatically get the current valid network scope from= the DOTS server?

 

[TR2] It will not solve the abo= ve problem of detecting and rejecting a rouge (or misconfigured) DOTS clien= t behind client domain DOTS gateway sending ACL without specifying destinat= ion-network.

&n= bsp;

[Jon2] = Hmm.  If the client-domain DOTS gateway is restricted in scope as to w= hat it is allowed to request, and a rogue client behind the gateway does no= t specify a destination-network, then when the request passes through the gateway the upstream DOTS server will only = use the scope allowed for that specific client-domain DOTS gateway.  A= gain, it is exactly the same as if the rogue client was to specify the full= set of allowed scope as a set of destination networks in terms of damage capabilities.

 

[TR3] No, the client-domain DOT= S gateway can detect and reject the ACL because the rouge DOTS client has s= pecified destination-network not under its scope.

&n= bsp;

[Jon3] = You are missing my point.  Agreed that the client-domain DOTS gateway = must sanity check what is passed through.  However, there will be a se= t of Networks that are allowed through the DOTS gateway which are within the defined scope of what the DOTS server allows.=   This “allowed through networks” can legitimately be set = by the DOTS client in destination-network, or the DOTS server can fill in t= he same set of networks in the ACL instantiation if destination-networks was empty and the potential side effects damage ca= used will be the same.

 

[TR] I understand, you seem to = be focusing on only DDoS detectors and IDMS acting as DOTS clients . They w= ill be authorized to enforce ACL for the entire DOTS client domain, but an = application server acting as a DOTS client will only be authorized to enforce ACL for the IP addresses/prefixe= s used by the it and not for the entire DOTS client domain. These type of D= OTS clients must fill the destination-network, so the client-domain DOTS ga= teway can detect and reject ACL requests populated with destination IP addresses/prefixes the application = server does not use.

 

-Tiru

 

~jon2

 

-Tiru

 

~jon1

 

-Tiru

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Kon= da@mcafee.com]
Sent: 07 April 2018 06:48
To: Jon Shallow; moh= amed.boucadair@orange.com; dots@ietf.org
Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Hi Jon,

&nbs= p;

DOTS clie= nts (intelligent DDoS mitigation system, application server) will know the = destination networks, what kind of DOTS clients will not know the destinati= on networks they are allowed to use ?

DOTS clie= nts could be behind client-domain DOTS gateway, DOTS server will have no wa= y to validate the DOTS client identity sending the ACE request to determine= the destination IP addresses in its scope, it will only know the destination IP addresses in the DOTS client d= omain scope.

Further, = the implicit rule can be misused by compromised DOTS clients (e.g. black-li= st good traffic to the entire DOTS client domain) and it’s a  tr= oubleshooting nightmare to find the culprit device adversely impacting the entire network.

&nbs= p;

Cheers,

-Tiru

&nbs= p;

From:<= /span> Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Friday, April 6, 2018 9:14 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; mohamed.boucadair@orange.co= m; dots@ietf.org
Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Hi Tiru= ,

&n= bsp;

The DOT= S server is likely to have a scope of IP addresses that are valid for the c= lient to ask for protection for based on the cuid or cdid.

&n= bsp;

The DOT= S client may have some knowledge of the scope IPs by some out of band metho= d, but programmatically cannot ask the server what they are.

&n= bsp;

If a cl= ient specifies a destination network that is out of the valid scope of IP a= ddresses, then the ACE request will get rejected.  The client may then= have a challenge to work out what destination networks it is allowed to use.

&n= bsp;

How doe= s a client set up a blacklist for all the IPS within his allowed scope if i= t does not know what the scope is?

&n= bsp;

If the = client has not provided a destination network, then the DOTS server can aut= o-fill in the missing information at the time of the ACE instantiation R= 11; and this then handles if the scope of IP addresses change.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 06 April 2018 16:19
To: Jon Shallow; moh= amed.boucadair@orange.com; dots@ietf.org
Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

I donR= 17;t understand how the DOTS server/mitigation will fill it in at time of A= CE instantiation, and why can’t the DOTS client fill the destination = network details ?

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Friday, April 6, 2018 6:58 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; mohamed.boucadair@orange.co= m; dots@ietf.org
Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Hi ther= e,

&n= bsp;

There i= s no current way to request of a DOTS Server as to what is the set of IP ne= tworks that a DOTS client can use either within a mitigation request or to = set up an ACL other than by “testing for ok or not ok” with lots of different IP addresses.=

&n= bsp;

There i= s a reasonable likelihood of the scope of valid IPs from the Server’s= perspective will change over time.  So, unless a DOTS client wants to= control a specific destination network, then my suggestion would be to leave the ACE destination network empty and for the= DOTS Server / DOTS mitigator (how is out of scope) to fill it in at time o= f ACE instantiation.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 27 March 2018 13:49
To: Jon Shallow; moh= amed.boucadair@orange.com; dots@ietf.org
Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Please se= e inline [TR]

&nbs= p;

From:<= /span> Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Tuesday, March 27, 2018 4:07 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; mohamed.boucadair@orange.co= m; dots@ietf.org
Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Hi Tiru= / Med

&n= bsp;

See inl= ine [Jon]

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 27 March 2018 09:47
To: mohamed.boucadai= r@orange.com; Jon Shallow; dots@ietf.org
Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

I also su= pport to mandate destination-network for immediately enforced filtering rul= es.

[Jon] This can be enforced / inserted by the DOTS Server for all the d= estination networks of the domain that the DOTS client ‘belongs’= ; to.  That said, it would be good to always have the destination network in an ACL as it can be validated and cross-checked= whenever the legitimate set of domain protected IPs are updated.

[Jon] However, what happens to the Destination network in the case of = a call home DOTS client that becomes a quasi DOTS server and the Destinatio= n networks are somewhere out on the Internet?

&nbs= p;

[TR] DDOS= is a targeted attack, so the DOTS client can specify the destination netwo= rk targeted by devices in the DOTS server domain and the DOTS server can va= lidate if the destination network is indeed targeted by its devices.

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed= ......boucadair@orange.com
Sent: Tuesday, March 27, 2018 1:09 PM
To: Jon Shallow <sup= jps-ietf@jpshallow.com>; dots@ietf.org
Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Hi Jon,

 

Thank you for the comments.<= /p>

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow
Envoy=E9 : lundi 26 mars 2018 14:23
=C0 : dots@ietf.org
Objet : [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Hi there,

 

As per Med’s presentation= to the IETF 101

 

Issue #4: Per-Domain or Per-cli= ent Filters?

 

• Conclusion

– Filters that are activa= ted only during mitigation time are on a per-client basis=

   • Filters ar= e per-domain when are immediately applied

 

“Filters are per-domain w= hen are immediately applied” is what I have an challenge with.

 

If we have a compromised or rog= ue DOTS client, the simple use of something like curl, along with the clien= t certificates etc. can be used to generate any ACL with activation-type := =3D ‘immediate’ which is then immediately applied for all traffic within the domain as per the above.

 

[Med] Yes. FWIW, this attack is= called out in the security considerations section:

 

“Nevertheless,=
 an

   attacker who can acce= ss a DOTS client is technically capable of

   launching various att= acks, such as:

 

..;

 

   o  Set invalid ACL entries, which may prevent legiti=
mate traffic from
      being forwarded.  Likewise, invali=
d ACL entries may lead to
      forward DDoS traffic.=

“

[Jon] A= greed that the attack is covered off in the Security section, but we should= be limiting the possibility / scope of the attack vector by enforcing some= rules as to what is / is not allowed.  Allowing a DOTS client to be able to affect all the traffic within the dom= ain is a huge risk to me and should not be allowed.

 

So, a ACL that blacklists the D= NS server, or drops all port 443 traffic etc. can easily cause all of the o= ther clients / devices within the domain to be taken off air.  Putting= the intelligence into the DOTS server to not allow this to happen could be a challenge.

[The signal channel is much har= der to compromise and affect traffic flows to other areas within the domain= ]

 

I believe that an ACL instantia= ted by a DOTS client (immediate or when-mitigating) should only apply to th= e DOTS client’s traffic which means that the destination-network has = to be a part of the ACL, whether implicitly added by the DOTS server, or by the DOTS client and suitably validated.

 

[Med] Putting aside that I don&= #8217;t parse “DOTS client’s traffic”,

[Jon] I= was referring to all the traffic flows that a DOTS client can legitimately= request control of to the DOTS server that are within the scope of what th= e DOTS client is protecting (which may or may not be the DOTS client’s IP address).

I interpret your answer as a su= pport to this question raised for issue #4:

    • “Should we mandate destination-network to be present for immediately enforced filters?”

[Jon] S= ee response to Tiru’s Agreement above.

~Jon

There is nothing to stop the DO= TS server or DOTS mitigator merging common ACLs to reduce the number of ACL= s within the mitigation device.

 

As a side note “mitigatio= n-time” is perhaps a bad name as it implies a time period – som= ething like “when-mitigating” to me is clearer.

[Med] Fixed in my local copy. T= hank you.

 

Regards

 

Jon

--_000_DM5PR16MB14362593B3DE185A325681F5EABE0DM5PR16MB1436namp_-- From nobody Tue Apr 10 03:33:07 2018 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 75637127698 for ; Tue, 10 Apr 2018 03:33:05 -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 7mv-rt8q_p8Y for ; Tue, 10 Apr 2018 03:33:01 -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 5BD3B120724 for ; Tue, 10 Apr 2018 03:33:00 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.90_1) (envelope-from ) id 1f5qa8-0004Jm-Qm; Tue, 10 Apr 2018 11:32:58 +0100 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , , References: <008401d3c4fd$216d0840$644718c0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF1067@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <014801d3c5b7$94c67f00$be537d00$@jpshallow.com> <009a01d3cdab$150b4c40$3f21e4c0$@jpshallow.com> <00cf01d3cdbe$24876650$6d9632f0$@jpshallow.com> <01fd01d3cfe4$a71b6580$f5523080$@jpshallow.com> <024901d3cff6$9d4beea0$d7e3cbe0$@jpshallow.com> <02c301d3d049$2f60cf20$8e226d60$@jpshallow.com> <000a01d3d 0ab$55bef7c0$013ce740$@jpshallow.com> In-Reply-To: Date: Tue, 10 Apr 2018 11:32:57 +0100 Message-ID: <005e01d3d0b7$4b3d7db0$e1b87910$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005F_01D3D0BF.AD05DD50" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGlexwLZckIYJuvKwEmwuQr1rXL6AKpdMHOAgMRKpIBsBKRFgKXgqsdAxHSSssB/GODugGyw551AT90vc8BfRxiYwGyPN+IAfZRzPoCBSpzvgLbmAm4AZLY2IwBns4JVwD5zREko11Cf9A= Content-Language: en-gb Archived-At: Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 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, 10 Apr 2018 10:33:05 -0000 This is a multipart message in MIME format. ------=_NextPart_000_005F_01D3D0BF.AD05DD50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Tiru, =20 See inline [Jon4] =20 Regards =20 Jon =20 =20 =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Monday, April 9, 2018 2:55 PM To: Konda, Tirumaleswar Reddy ; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 =20 Hi Tiru, =20 If a DOTS client knows the full scope of the Networks that it is allowed = to use in a ACL or mitigate request, and the DOTS server limits any update = from that client to the scope of Networks (with any unexpected side effects = that may have), then there is no difference in my mind as to whether the DOTS clients fills in the destination-network, or the DOTS server does so on = the DOTS client=92s behalf before ACL instantiation if destination-network = is not defined. =20 [TR] The above model only works when the DOTS server and DOTS client are directly communicating with each other (In the above, the DOTS server = knows the DOTS client identity to enforce the scope but will not the DOTS = client identity in the presence of a client-domain DOTS gateway).=20 =20 [Jon1] The last para of =9310. Security Considerations=94 states DOTS servers MUST verify that requesting DOTS clients are entitled to trigger actions on a given IP prefix. That is, only actions on IP resources that belong to the DOTS client' domain MUST be authorized by a DOTS server. The exact mechanism for the DOTS servers to validate that the target prefixes are within the scope of the DOTS client's domain is deployment-specific. =20 [Jon1] So it makes no difference if the DOTS client happens to be an = agent part of a client-domain DOTS gateway. If the client-domain DOTS gateway = is hiding all the =91behind=92 clients and presenting as single client, = there is no issue. However, if the =91behind=92 clients are presented as 2 or more = =91cuid=92s by the DOTS gateway, then either the scope is per =91cuid=92, or if = =91cdid=92s are being applied by the upstream server domain DOTS gateway then on a per =91cdid=92 basis if wanted. =20 For a client behind a client domain DOTS gateway, there may be non = public IP addresses that the (DMS) client is responsible for, but these should = never be sent out through the DOTS gateway (and should be rejected by the DOTS server as out of scope). There does have to be a common agreement = between DOTS client & DOTS server as to what Networks are in scope, but the DOTS client currently cannot request this from the DOTS server and has to be agreed out of band. =20 [TR] I don=92t see a new problem, even when a DOTS client sends a = mitigation request it needs to know if the targets conveyed in the mitigation = request are in its scope or not. =20 [Jon1] but again, the DOTS server MUST verify the IP prefix is valid, so = has to know scope. I agree that the DOTS client (or client domain DOTS = gateway) needs to know (today out of band) what is the scope of what is valid to request. The challenge comes when the DOTS server=92s scope is = reconfigured, but not yet updated on the DOTS client. =20 =20 [TR2] The scope would be first updated on the DOTS client domain and = then on the DOTS server (e.g. IP prefix re-numbering).=20 =20 [Jon2] I was more thinking of a DOTS client that got missed off a list = when the DOTS server was updated. Normally though, they should be kept in = sync but which one gets updated first is uncertain to me. =20 [TR3] If the DOTS client missed update, it will have various other = problems; any network policy based on destination network IP/prefix will fail. = DOTS client should support mechanisms to receive the latest network = configuration after missing critical updates because it was offline or its=20 connectivity was lost. =20 [Jon3] So to me, we need to add in something to the data channel = protocol so that a DOTS client can request as to what is the network current scope = it is allowed to ask for ACL/Mitigation for. =20 [TR4] I don=92t think so, you may want to look into SIG-007 requirement, = it says =93A DOTS client may obtain the mitigation scope through direct provisioning or through implementation-specific methods of discovery.=94 =20 [Jon4] That does not preclude us adding it into the DOTS data protocol = YANG model. =20 There is no reason as to why the DOTS server cannot maintain a valid = scope of Networks that the client domain DOTS gateway is allowed to request = for validity checking =96 unless I am missing something? =20 [TR] You are partially right, the DOTS server does not know the valid = scope of prefixes that a DOTS client behind client-domain DOTS gateway is = allowed to request. =20 [Jon1] Again, the last para of 10. stands here, and so the scope has to = be known by the DOTS server. =20 [TR] Yes, but it may not know the scope of a DOTS client behind a client-domain DOTS gateway. =20 [Jon2] But it will know what the client-domain DOTS gateway is allowed = to pass through in terms of Destination Network. The client-domain DOTS gateway will separately need to know what Destination networks are = allowed to get out through the gateway. =20 Troubleshooting has kept me in a job for more years than I care to = remember, anything to aid troubleshooting is what I am interested in and so = totally agree that rogue DOTS client=92s capabilities need to be kept under = control with suitable logging to aid diagnosis is a major plus. However in this case, the implicit rule is no different to the DOTS client requesting = the full Networks scope in an ACL request. =20 [TR] If the client is not authorized to request the full network scope, = it can detected by the client-domain DOTS gateway and rejects the filtering rule by comparing the destination-networks=20 specified in the ACE. [Jon1] Agreed, it is the responsibility of the client domain DOTS = gateway to only allow out valid networks that are valid within the DOTS server=92s = scope. =20 [Jon1] Should we support a way for the client domain DOTS gateway (i.e. DOTS client agent) to programmatically get the current valid network = scope from the DOTS server? =20 [TR2] It will not solve the above problem of detecting and rejecting a = rouge (or misconfigured) DOTS client behind client domain DOTS gateway sending = ACL without specifying destination-network. =20 [Jon2] Hmm. If the client-domain DOTS gateway is restricted in scope as = to what it is allowed to request, and a rogue client behind the gateway = does not specify a destination-network, then when the request passes through = the gateway the upstream DOTS server will only use the scope allowed for = that specific client-domain DOTS gateway. Again, it is exactly the same as = if the rogue client was to specify the full set of allowed scope as a set = of destination networks in terms of damage capabilities. =20 [TR3] No, the client-domain DOTS gateway can detect and reject the ACL because the rouge DOTS client has specified destination-network not = under its scope.=20 =20 [Jon3] You are missing my point. Agreed that the client-domain DOTS = gateway must sanity check what is passed through. However, there will be a set = of Networks that are allowed through the DOTS gateway which are within the defined scope of what the DOTS server allows. This =93allowed through networks=94 can legitimately be set by the DOTS client in = destination-network, or the DOTS server can fill in the same set of networks in the ACL instantiation if destination-networks was empty and the potential side effects damage caused will be the same. =20 [TR4] I understand, you seem to be focusing on only DDoS detectors and = IDMS acting as DOTS clients . They will be authorized to enforce ACL for the entire DOTS client domain, but an application server acting as a DOTS = client will only be authorized to enforce ACL for the IP addresses/prefixes = used by the it and not for the entire DOTS client domain. These type of DOTS = clients must fill the destination-network, so the client-domain DOTS gateway can detect and reject ACL requests populated with destination IP addresses/prefixes the application server does not use.=20 =20 [Jon4] I agree that the client-domain DOTS gateway has to have a notion = of which client can request what =96 i.e. maintaining a scope of what the individual client can ask for. Not convinced that we clearly define = that a client-domain DOTS gateway must maintain a Destination scope though. = There is no reason as to why a client-domain DOTS gateway cannot fill in an = empty destination-network with the specifics for the requesting client though before passing it through upstream =96 but it does look tidier if the = client does specify the destination-network. =20 -Tiru =20 ~jon2 =20 -Tiru =20 ~jon1 =20 -Tiru =20 Regards =20 Jon =20 From: Konda, Tirumaleswar Reddy [mailto: = TirumaleswarReddy_Konda@mcafee.com] Sent: 07 April 2018 06:48 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 =20 Hi Jon, =20 DOTS clients (intelligent DDoS mitigation system, application server) = will know the destination networks, what kind of DOTS clients will not know = the destination networks they are allowed to use ? DOTS clients could be behind client-domain DOTS gateway, DOTS server = will have no way to validate the DOTS client identity sending the ACE request = to determine the destination IP addresses in its scope, it will only know = the destination IP addresses in the DOTS client domain scope.=20 Further, the implicit rule can be misused by compromised DOTS clients = (e.g. black-list good traffic to the entire DOTS client domain) and it=92s a troubleshooting nightmare to find the culprit device adversely impacting = the entire network. =20 Cheers, -Tiru =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Friday, April 6, 2018 9:14 PM To: Konda, Tirumaleswar Reddy ; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 =20 Hi Tiru, =20 The DOTS server is likely to have a scope of IP addresses that are valid = for the client to ask for protection for based on the cuid or cdid. =20 The DOTS client may have some knowledge of the scope IPs by some out of = band method, but programmatically cannot ask the server what they are.=20 =20 If a client specifies a destination network that is out of the valid = scope of IP addresses, then the ACE request will get rejected. The client may then have a challenge to work out what destination networks it is = allowed to use. =20 How does a client set up a blacklist for all the IPS within his allowed scope if it does not know what the scope is? =20 If the client has not provided a destination network, then the DOTS = server can auto-fill in the missing information at the time of the ACE instantiation =96 and this then handles if the scope of IP addresses = change. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 06 April 2018 16:19 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 =20 I don=92t understand how the DOTS server/mitigation will fill it in at = time of ACE instantiation, and why can=92t the DOTS client fill the destination network details ? =20 -Tiru =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Friday, April 6, 2018 6:58 PM To: Konda, Tirumaleswar Reddy ; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 =20 Hi there, =20 There is no current way to request of a DOTS Server as to what is the = set of IP networks that a DOTS client can use either within a mitigation = request or to set up an ACL other than by =93testing for ok or not ok=94 with lots = of different IP addresses. =20 There is a reasonable likelihood of the scope of valid IPs from the = Server=92s perspective will change over time. So, unless a DOTS client wants to control a specific destination network, then my suggestion would be to = leave the ACE destination network empty and for the DOTS Server / DOTS = mitigator (how is out of scope) to fill it in at time of ACE instantiation. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 27 March 2018 13:49 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 =20 Please see inline [TR] =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Tuesday, March 27, 2018 4:07 PM To: Konda, Tirumaleswar Reddy ; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 =20 Hi Tiru / Med =20 See inline [Jon] =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 27 March 2018 09:47 To: mohamed.boucadair@orange.com; Jon Shallow; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 =20 I also support to mandate destination-network for immediately enforced filtering rules. [Jon] This can be enforced / inserted by the DOTS Server for all the destination networks of the domain that the DOTS client =91belongs=92 = to. That said, it would be good to always have the destination network in an ACL = as it can be validated and cross-checked whenever the legitimate set of = domain protected IPs are updated. [Jon] However, what happens to the Destination network in the case of a = call home DOTS client that becomes a quasi DOTS server and the Destination networks are somewhere out on the Internet? =20 [TR] DDOS is a targeted attack, so the DOTS client can specify the destination network targeted by devices in the DOTS server domain and = the DOTS server can validate if the destination network is indeed targeted = by its devices. =20 -Tiru =20 From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.......boucadair@orange.com = Sent: Tuesday, March 27, 2018 1:09 PM To: Jon Shallow ; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 =20 Hi Jon,=20 =20 Thank you for the comments. =20 Please see inline. =20 Cheers, Med =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : lundi 26 mars 2018 14:23 =C0 : dots@ietf.org Objet : [Dots] IETF 101 Presentation Data Channel Issue #4 =20 Hi there, =20 As per Med=92s presentation to the IETF 101 =20 Issue #4: Per-Domain or Per-client Filters? =20 =95 Conclusion =96 Filters that are activated only during mitigation time are on a = per-client basis =95 Filters are per-domain when are immediately applied =20 =93Filters are per-domain when are immediately applied=94 is what I have = an challenge with. =20 If we have a compromised or rogue DOTS client, the simple use of = something like curl, along with the client certificates etc. can be used to = generate any ACL with activation-type :=3D =91immediate=92 which is then = immediately applied for all traffic within the domain as per the above. =20 [Med] Yes. FWIW, this attack is called out in the security = considerations section:=20 =20 =93Nevertheless, an attacker who can access a DOTS client is technically capable of launching various attacks, such as: =20 ..; =20 o Set invalid ACL entries, which may prevent legitimate traffic from being forwarded. Likewise, invalid ACL entries may lead to forward DDoS traffic. =93 [Jon] Agreed that the attack is covered off in the Security section, but = we should be limiting the possibility / scope of the attack vector by = enforcing some rules as to what is / is not allowed. Allowing a DOTS client to be able to affect all the traffic within the domain is a huge risk to me = and should not be allowed. =20 So, a ACL that blacklists the DNS server, or drops all port 443 traffic = etc. can easily cause all of the other clients / devices within the domain to = be taken off air. Putting the intelligence into the DOTS server to not = allow this to happen could be a challenge. [The signal channel is much harder to compromise and affect traffic = flows to other areas within the domain] =20 I believe that an ACL instantiated by a DOTS client (immediate or when-mitigating) should only apply to the DOTS client=92s traffic which = means that the destination-network has to be a part of the ACL, whether = implicitly added by the DOTS server, or by the DOTS client and suitably validated. =20 [Med] Putting aside that I don=92t parse =93DOTS client=92s traffic=94, [Jon] I was referring to all the traffic flows that a DOTS client can legitimately request control of to the DOTS server that are within the = scope of what the DOTS client is protecting (which may or may not be the DOTS client=92s IP address). I interpret your answer as a support to this question raised for issue = #4: * =93Should we mandate destination-network to be present for immediately enforced filters?=94 [Jon] See response to Tiru=92s Agreement above. ~Jon There is nothing to stop the DOTS server or DOTS mitigator merging = common ACLs to reduce the number of ACLs within the mitigation device. =20 As a side note =93mitigation-time=94 is perhaps a bad name as it implies = a time period =96 something like =93when-mitigating=94 to me is clearer. [Med] Fixed in my local copy. Thank you. =20 Regards =20 Jon ------=_NextPart_000_005F_01D3D0BF.AD05DD50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

See inline = [Jon4]

 

Regards

 

Jon

 

 

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Monday, April 9, 2018 2:55 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: RE: = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

Hi Tiru,

 

If a DOTS client knows = the full scope of the Networks that it is allowed to use in a ACL or = mitigate request, and the DOTS server limits any update from that client = to the scope of Networks (with any unexpected side effects that may = have), then there is no difference in my mind as to whether the DOTS = clients fills in the destination-network, or the DOTS server does so on = the DOTS client’s behalf before ACL instantiation if = destination-network is not defined.

 

[TR] The = above model only works when the DOTS server and DOTS client are directly = communicating with each other (In the above, the DOTS server knows the = DOTS client identity to enforce the scope but will not the DOTS client = identity in the presence of a client-domain DOTS gateway). =

 

[Jon1] The last para of = “10. Security Considerations” states

   DOTS servers MUST verify that = requesting DOTS clients are entitled to

   trigger actions on a given IP = prefix.  That is, only actions on IP

   resources that belong to the DOTS = client' domain MUST be authorized

   by a DOTS server.  The exact = mechanism for the DOTS servers to

   validate that the target prefixes = are within the scope of the DOTS

   client's = domain is deployment-specific.

 

[Jon1] So it makes no difference if the DOTS = client happens to be an agent part of a client-domain DOTS = gateway.  If the client-domain DOTS gateway is hiding all the = ‘behind’ clients and presenting as single client, there is = no issue.  However, if the ‘behind’ clients are = presented as 2 or more ‘cuid’s by the DOTS gateway, then = either the scope is per ‘cuid’, or if ‘cdid’s = are being applied by the upstream server domain DOTS gateway then on a = per ‘cdid’ basis if wanted.

 

For a client behind a = client domain DOTS gateway, there may be non public IP addresses that = the (DMS) client is responsible for, but these should never be sent out = through the DOTS gateway (and should be rejected by the DOTS server as = out of scope).  There does have to be a common agreement between = DOTS client & DOTS server as to what Networks are in scope, but the = DOTS client currently cannot request this from the DOTS server and has = to be agreed out of band.

 

[TR] I = don’t see a new problem, even when a DOTS client sends a = mitigation request it needs to know if the targets conveyed in the = mitigation request are in its scope or not.

 

[Jon1] but again, the = DOTS server MUST verify the IP prefix is valid, so has to know = scope.  I agree that the DOTS client (or client domain DOTS = gateway) needs to know (today out of band) what is the scope of what is = valid to request.  The challenge comes when the DOTS server’s = scope is reconfigured, but not yet updated on the DOTS client.  =

 

[TR2] The scope would be first updated on the DOTS = client domain and then on the DOTS server (e.g. IP prefix re-numbering). =

 

[Jon2] I was more = thinking of a DOTS client that got missed off a list when the DOTS = server was updated.  Normally though, they should be kept in sync = but which one gets updated first is uncertain to = me.

 

[TR3] If the DOTS client missed update, it will have = various other problems; any network policy based on destination network = IP/prefix will fail. DOTS client should support mechanisms to receive = the latest network configuration after missing critical updates because = it was offline or its

         &= nbsp;connectivity was lost.

 

[Jon3] So to me, we need = to add in something to the data channel protocol so that a DOTS client = can request as to what is the network current scope it is allowed to ask = for ACL/Mitigation for.

 

[TR4] I don’t think so, you may want =
to look into SIG-007 requirement, it says “A DOTS client may obtain the mitigation scope through =
direct provisioning or through implementation-specific methods of =
discovery.”
 
[Jon4] That does not preclude us adding it into the DOTS data =
protocol YANG model.

 

There is no reason as to why the DOTS server = cannot maintain a valid scope of Networks that the client domain DOTS = gateway is allowed to request for validity checking – unless I am = missing something?

 

[TR] You are = partially right, the DOTS server does not know the valid scope of = prefixes that a DOTS client behind client-domain DOTS gateway is allowed = to request.

 

[Jon1] Again, the last = para of 10. stands here, and so the scope has to be known by the DOTS = server.

 

[TR] Yes, = but it may not know the scope of a DOTS client behind a client-domain = DOTS gateway.

 

[Jon2] But it will know = what the client-domain DOTS gateway is allowed to pass through in terms = of Destination Network.  The client-domain DOTS gateway will = separately need to know what Destination networks are allowed to get out = through the gateway.

 

Troubleshooting has kept = me in a job for more years than I care to remember, anything to aid = troubleshooting is what I am interested in and so totally agree that = rogue DOTS client’s capabilities need to be kept under control = with suitable logging to aid diagnosis is a major plus.  However in = this case, the implicit rule is no different to the DOTS client = requesting the full Networks scope in an ACL = request.

 

[TR] If the = client is not authorized to request the full network scope, it can = detected by the client-domain DOTS gateway and rejects the filtering = rule by comparing the destination-networks

        specifi= ed in the ACE.

[Jon1] Agreed, it is the = responsibility of the client domain DOTS gateway to only allow out valid = networks that are valid within the DOTS server’s = scope.

 

[Jon1] Should we support = a way for the client domain DOTS gateway  (i.e. DOTS client agent) = to programmatically get the current valid network scope from the DOTS = server?

 

[TR2] It = will not solve the above problem of detecting and rejecting a rouge (or = misconfigured) DOTS client behind client domain DOTS gateway sending ACL = without specifying destination-network.

 

[Jon2] Hmm.  If the = client-domain DOTS gateway is restricted in scope as to what it is = allowed to request, and a rogue client behind the gateway does not = specify a destination-network, then when the request passes through the = gateway the upstream DOTS server will only use the scope allowed for = that specific client-domain DOTS gateway.  Again, it is exactly the = same as if the rogue client was to specify the full set of allowed scope = as a set of destination networks in terms of damage = capabilities.

 

[TR3] No, = the client-domain DOTS gateway can detect and reject the ACL because the = rouge DOTS client has specified destination-network not under its scope. =

 

[Jon3] You are missing = my point.  Agreed that the client-domain DOTS gateway must sanity = check what is passed through.  However, there will be a set of = Networks that are allowed through the DOTS gateway which are within the = defined scope of what the DOTS server allows.  This “allowed = through networks” can legitimately be set by the DOTS client in = destination-network, or the DOTS server can fill in the same set of = networks in the ACL instantiation if destination-networks was empty and = the potential side effects damage caused will be the = same.

 

[TR4] I = understand, you seem to be focusing on only DDoS detectors and IDMS = acting as DOTS clients . They will be authorized to enforce ACL for the = entire DOTS client domain, but an application server acting as a DOTS = client will only be authorized to enforce ACL for the IP = addresses/prefixes used by the it and not for the entire DOTS client = domain. These type of DOTS clients must fill the destination-network, so = the client-domain DOTS gateway can detect and reject ACL requests = populated with destination IP addresses/prefixes the application server = does not use.

 

[Jon4]=A0 I agree that = the client-domain DOTS gateway has to have a notion of which client can = request what – i.e. maintaining a scope of what the individual = client can ask for.=A0 Not convinced that we clearly define that a = client-domain DOTS gateway must maintain a Destination scope though.=A0 = There is no reason as to why a client-domain DOTS gateway cannot fill in = an empty destination-network with the specifics for the requesting = client though before passing it through upstream – but it does = look tidier if the client does specify the = destination-network.

 

-Tiru

 

~jon2

 

-Tiru

 

~jon1

 

-Tiru

 

Regards

 

Jon

 

From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Kond= a@mcafee.com]
Sent: 07 April 2018 06:48
To: Jon = Shallow; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: RE: = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

Hi = Jon,

 

DOTS clients (intelligent DDoS = mitigation system, application server) will know the destination = networks, what kind of DOTS clients will not know the destination = networks they are allowed to use ?

DOTS clients could be behind = client-domain DOTS gateway, DOTS server will have no way to validate the = DOTS client identity sending the ACE request to determine the = destination IP addresses in its scope, it will only know the destination = IP addresses in the DOTS client domain scope.

Further, the implicit rule can be = misused by compromised DOTS clients (e.g. black-list good traffic to the = entire DOTS client domain) and it’s a  troubleshooting = nightmare to find the culprit device adversely impacting the entire = network.

 

Cheers,

-Tiru

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Friday, April 6, 2018 9:14 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: RE: = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

Hi Tiru,

 

The DOTS server is = likely to have a scope of IP addresses that are valid for the client to = ask for protection for based on the cuid or = cdid.

 

The DOTS client may have = some knowledge of the scope IPs by some out of band method, but = programmatically cannot ask the server what they are. =

 

If a client specifies a = destination network that is out of the valid scope of IP addresses, then = the ACE request will get rejected.  The client may then have a = challenge to work out what destination networks it is allowed to = use.

 

How does a client set up = a blacklist for all the IPS within his allowed scope if it does not know = what the scope is?

 

If the client has not = provided a destination network, then the DOTS server can auto-fill in = the missing information at the time of the ACE instantiation – and = this then handles if the scope of IP addresses = change.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 06 April 2018 = 16:19
To: Jon Shallow; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: Re: = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

I don’t = understand how the DOTS server/mitigation will fill it in at time of ACE = instantiation, and why can’t the DOTS client fill the destination = network details ?

 

-Tiru

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Friday, April 6, 2018 6:58 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: RE: = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

Hi there,

 

There is no current way = to request of a DOTS Server as to what is the set of IP networks that a = DOTS client can use either within a mitigation request or to set up an = ACL other than by “testing for ok or not ok” with lots of = different IP addresses.

 

There is a reasonable = likelihood of the scope of valid IPs from the Server’s perspective = will change over time.  So, unless a DOTS client wants to control a = specific destination network, then my suggestion would be to leave the = ACE destination network empty and for the DOTS Server / DOTS mitigator = (how is out of scope) to fill it in at time of ACE = instantiation.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 27 March 2018 = 13:49
To: Jon Shallow; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: Re: = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

Please see inline = [TR]

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Tuesday, March 27, 2018 4:07 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: RE: = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

Hi Tiru / Med

 

See inline = [Jon]

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 27 March 2018 = 09:47
To: mohamed.boucadair@orange.com= ; Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

I also support to = mandate destination-network for immediately enforced filtering = rules.

[Jon] This can be = enforced / inserted by the DOTS Server for all the destination networks = of the domain that the DOTS client ‘belongs’ to.  That = said, it would be good to always have the destination network in an ACL = as it can be validated and cross-checked whenever the legitimate set of = domain protected IPs are updated.

[Jon] However, what = happens to the Destination network in the case of a call home DOTS = client that becomes a quasi DOTS server and the Destination networks are = somewhere out on the Internet?

 

[TR] DDOS is a targeted attack, so = the DOTS client can specify the destination network targeted by devices = in the DOTS server domain and the DOTS server can validate if the = destination network is indeed targeted by its = devices.

 

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of mohamed.......boucadair@oran= ge.com
Sent: Tuesday, March 27, 2018 1:09 PM
To: = Jon Shallow <supjps-ietf@jpshallow.com&g= t;; dots@ietf.org
Subject: Re: = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

Hi Jon,

 

Thank you for the comments.

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] = De la part de Jon Shallow
Envoy=E9 : lundi 26 mars = 2018 14:23
=C0 : dots@ietf.org
Objet : = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

Hi = there,

 

As per Med’s presentation to the IETF = 101

 

Issue #4: Per-Domain or Per-client = Filters?

 

• Conclusion

– Filters that are activated only during = mitigation time are on a per-client basis

   • Filters are per-domain when are = immediately applied

 

“Filters are per-domain when are immediately = applied” is what I have an challenge with.

 

If we have a = compromised or rogue DOTS client, the simple use of something like curl, = along with the client certificates etc. can be used to generate any ACL = with activation-type :=3D ‘immediate’ which is then = immediately applied for all traffic within the domain as per the = above.

 

[Med] = Yes. FWIW, this attack is called out in the security considerations = section:

 

“Nevertheless, =
an

   attacker who can access a = DOTS client is technically capable of

   launching various attacks, = such as:

 

..;

 

   o  Set invalid ACL entries, which may =
prevent legitimate traffic from
      being forwarded.  =
Likewise, invalid ACL entries may lead =
to
      forward DDoS traffic.

“

[Jon] Agreed that the = attack is covered off in the Security section, but we should be limiting = the possibility / scope of the attack vector by enforcing some rules as = to what is / is not allowed.  Allowing a DOTS client to be able to = affect all the traffic within the domain is a huge risk to me and should = not be allowed.

 

So, a ACL = that blacklists the DNS server, or drops all port 443 traffic etc. can = easily cause all of the other clients / devices within the domain to be = taken off air.  Putting the intelligence into the DOTS server to = not allow this to happen could be a challenge.

[The signal channel is much harder to compromise and = affect traffic flows to other areas within the domain]

 

I believe = that an ACL instantiated by a DOTS client (immediate or when-mitigating) = should only apply to the DOTS client’s traffic which means that = the destination-network has to be a part of the ACL, whether implicitly = added by the DOTS server, or by the DOTS client and suitably = validated.

 

[Med] = Putting aside that I don’t parse “DOTS client’s = traffic”,

[Jon] I was referring to all the traffic flows = that a DOTS client can legitimately request control of to the DOTS = server that are within the scope of what the DOTS client is protecting = (which may or may not be the DOTS client’s IP = address).

I = interpret your answer as a support to this question raised for issue = #4:

    • “Should = we mandate destination-network to be present for immediately enforced = filters?”

[Jon] See response to = Tiru’s Agreement above.

~Jon

There is nothing to stop the DOTS server or DOTS = mitigator merging common ACLs to reduce the number of ACLs within the = mitigation device.

 

As a side = note “mitigation-time” is perhaps a bad name as it implies a = time period – something like “when-mitigating” to me = is clearer.

[Med] = Fixed in my local copy. Thank you.

 

Regards

 

Jon

<= /div>
------=_NextPart_000_005F_01D3D0BF.AD05DD50-- From nobody Tue Apr 10 03:40:56 2018 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 3759C126579 for ; Tue, 10 Apr 2018 03:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 nZ4SnTXvpgvw for ; Tue, 10 Apr 2018 03:40:51 -0700 (PDT) Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEE27120724 for ; Tue, 10 Apr 2018 03:40:50 -0700 (PDT) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 1C8C21C083B; Tue, 10 Apr 2018 12:40:49 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.31]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id F07988008B; Tue, 10 Apr 2018 12:40:48 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1%19]) with mapi id 14.03.0382.000; Tue, 10 Apr 2018 12:40:48 +0200 From: To: Jon Shallow , "'Konda, Tirumaleswar Reddy'" , "dots@ietf.org" Thread-Topic: [Dots] Signal Channel - 300 Redirected Signaling Thread-Index: AQIamFCo/JtwOnwhldffQNYnbiNPYAIQjxxBAf1MOQMBSJYqjAHHGFsmAZdTXv0BiMwQpAGAwQaNAXiOSqoB8X1CYQJlDVUhot/KKpCAAAmhMA== Date: Tue, 10 Apr 2018 10:40:48 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DEFB476@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93302DEFA4A0@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEFA561@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <029b01d3d042$fa319a10$ee94ce30$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEFB0C8@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEFB132@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEFB3A2@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <005001d3d0b3$83e76620$8bb63260$@jpshallow.com> In-Reply-To: <005001d3d0b3$83e76620$8bb63260$@jpshallow.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling 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, 10 Apr 2018 10:40:54 -0000 Re-, Thank you both for raising the issue and helping to fix it.=20 This one is closed.=20 Cheers, Med > -----Message d'origine----- > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > Envoy=E9=A0: mardi 10 avril 2018 12:06 > =C0=A0: 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf= .org > Objet=A0: RE: [Dots] Signal Channel - 300 Redirected Signaling >=20 > Looks good to me also. >=20 > Regards >=20 > Jon >=20 > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumalesw= ar > Reddy > Sent: 10 April 2018 10:51 > To: mohamed.boucadair@orange.com; Jon Shallow; dots@ietf.org > Subject: Re: [Dots] Signal Channel - 300 Redirected Signaling >=20 > > -----Original Message----- > > From: mohamed.boucadair@orange.com > > [mailto:mohamed.boucadair@orange.com] > > Sent: Tuesday, April 10, 2018 3:04 PM > > To: Konda, Tirumaleswar Reddy ; > > Jon Shallow ; dots@ietf.org > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > Re-, > > > > Sounds reasonable. Below a text proposal: > > > > A 'alt-server-ttl' parameter set to '0' may be returned for > > redirecting mitigation requests. Such value means that the > > redirection applies only for the mitigation request in progress. > > Returning short 'alt-server-ttl' may adversely impact DOTS client= s > > on slow links. Returning short values should be avoided under > > such conditions. >=20 > Thanks, Med. Update looks good. >=20 > Cheers, > -Tiru >=20 > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Konda, > > > Tirumaleswar Reddy Envoy=E9=A0: mardi 10 avril 2018 11:16 =C0=A0: BOU= CADAIR > > > Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet=A0: Re: [Dots] > > > Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > -----Original Message----- > > > > From: mohamed.boucadair@orange.com > > > > [mailto:mohamed.boucadair@orange.com] > > > > Sent: Tuesday, April 10, 2018 12:34 PM > > > > To: Konda, Tirumaleswar Reddy > > > > ; > > > > Jon Shallow ; dots@ietf.org > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > Re-, > > > > > > > > The exact value to return is on the deployment side. If a > > > > server/provider > > > decides > > > > that 0 or small value is to be returned (that is, redirect applies > > > > only for > > > the > > > > ongoing request), why should the spec care about this? > > > > > > If 0 value is returned, and the client wants to send a requests to > > > discover and configure the DOTS session configuration before sending > > > the mitigation request, 0 value means the client does not get to > > > send the mitigation request. We may want to clarify that with 0 TTL > > > value, re-direct applies only for the ongoing mitigation request and > > > not for other type of requests. Further, too small value will > > > adversely impact a DOTS client on slow links, e.g. TTL value expires > > > by the time the mitigation request reaches the DOTS server after > multiple retries. > > > > > > -Tiru > > > > > > > > > > > Cheers, > > > > Med > > > > > > > > > -----Message d'origine----- > > > > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Konda, > > > > > Tirumaleswar Reddy Envoy=E9=A0: mardi 10 avril 2018 08:46 =C0=A0: > > > > > BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet=A0: R= e: > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > -----Original Message----- > > > > > > From: mohamed.boucadair@orange.com > > > > > > [mailto:mohamed.boucadair@orange.com] > > > > > > Sent: Tuesday, April 10, 2018 12:01 PM > > > > > > To: Konda, Tirumaleswar Reddy > > > > > > ; > > > > > > Jon Shallow ; dots@ietf.org > > > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > Hi all, > > > > > > > > > > > > I think that we are converging. > > > > > > > > > > > > Below a text proposal which reflects the outcome of the > discussion: > > > > > > > > > > > > =3D=3D=3D=3D=3D=3D > > > > > > ttl: Time to live (TTL) of the alternate DOTS server, > > > > > > represented > > > as > > > > > > an integer number of seconds. That is, the time > > > > > > interval that > > > the > > > > > > alternate DOTS server may be cached for use by a DOTS > client. > > > > > > > > > > > > A value of negative one (-1) indicates indefinite TTL. > > > > > > This > > > value > > > > > > means that the alternate DOTS server is to be used until = the > > > > > > alternate DOTS server redirects the traffic with another > 3.00 > > > > > > response. > > > > > > > > > > > > If no 'ttl' is returned in a redirect response, this is > > > equivalent > > > > > > to returning a 'ttl' parameter set to '-1'. > > > > > > > > > > > > If the alternate DOTS server TTL has expired, the DOTS > > > > > > client > > > MUST > > > > > > use the DOTS server(s), that was provisioned using means > > > discussed > > > > > > in Section 4.1. This fall back mechanism is triggered > > > immediately > > > > > > upon expiry of the TTL except when a DDoS attack is activ= e. > > > > > > > > > > > > Requests issued by misbehaving DOTS clients which do not > > > > > > honor > > > the > > > > > > TTL or react to explicit re-direct messages can be reject= ed > by > > > > > > DOTS servers. > > > > > > > > > > > > This is an optional attribute. > > > > > > > > > > Looks good. We may also want to say that 0 or too small value > > > > > for ttl should be avoided. > > > > > > > > > > -Tiru > > > > > > > > > > > =3D=3D=3D=3D=3D=3D=3D > > > > > > > > > > > > Cheers, > > > > > > Med > > > > > > > > > > > > > -----Message d'origine----- > > > > > > > De=A0: Konda, Tirumaleswar Reddy > > > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > > Envoy=E9=A0: mardi 10 avril 2018 07:31 =C0=A0: Jon Shallow; > > > > > > > BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet=A0: RE: > > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > > > > > > Sent: Tuesday, April 10, 2018 2:10 AM > > > > > > > > To: mohamed.boucadair@orange.com; Konda, Tirumaleswar > > > > > > > > Reddy ; dots@ietf.org > > > > > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected > > > > > > > > Signaling > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > See inline [Jon] > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > Jon > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: mohamed.boucadair@orange.com [mailto: > > > > > > > > mohamed.boucadair@orange.com] > > > > > > > > Sent: 09 April 2018 13:20 > > > > > > > > To: Konda, Tirumaleswar Reddy; Jon Shallow; dots@ietf.org > > > > > > > > Subject: RE: [Dots] Signal Channel - 300 Redirected > > > > > > > > Signaling > > > > > > > > > > > > > > > > Re-, > > > > > > > > > > > > > > > > Glad to see that we both agree to get out from the DNS > comparison. > > > > > > > > > > > > > > > > [Jon] Also agree. Perhaps 'ttl' should be renamed > > > > > > > > 'alt-server- > > > ttl'. > > > > > > > > > > > > > > > > Please see inline. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Med > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Konda, Tirumaleswar > > > > > > > > > Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] > > > > > > > > > Envoy=E9=A0: lundi 9 avril 2018 13:48 =C0=A0: BOUCADAIR M= ohamed > > > > > > > > > IMT/OLN; Jon Shallow; dots@ietf.org Objet=A0: RE: > > > > > > > > > [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of > > > > > > > > > > mohamed.boucadair@orange.com > > > > > > > > > > Sent: Monday, April 9, 2018 5:12 PM > > > > > > > > > > To: Konda, Tirumaleswar Reddy > > > > > > > > > > ; > > > > > > > > > > Jon Shallow ; dots@ietf.org > > > > > > > > > > Subject: Re: [Dots] Signal Channel - 300 Redirected > > > > > > > > > > Signaling > > > > > > > > > > > > > > > > > > > > Re-, > > > > > > > > > > > > > > > > > > > > Please see inline. > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > Med > > > > > > > > > > > > > > > > > > > > > -----Message d'origine----- De=A0: Dots > > > > > > > > > > > [mailto:dots-bounces@ietf.org] De la part de Konda, > > > > > > > > > > > Tirumaleswar Reddy Envoy=E9=A0: lundi 9 avril 2018 13= :29 =C0=A0: > > > > > > > > > > > BOUCADAIR Mohamed IMT/OLN; Jon Shallow; > > > > > > > > > > > dots@ietf.org > > Objet=A0: > > > > > > > > > > > Re: [Dots] Signal Channel - 300 Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: mohamed.boucadair@orange.com > > > > > > > > > > > > [mailto:mohamed.boucadair@orange.com] > > > > > > > > > > > > Sent: Monday, April 9, 2018 4:49 PM > > > > > > > > > > > > To: Konda, Tirumaleswar Reddy > > > > > > > > > > > > ; > > > > > > > > > > > > Jon Shallow ; > > > > > > > > > > > > dots@ietf.org > > > > > > > > > > > > Subject: RE: [Dots] Signal Channel - 300 > > > > > > > > > > > > Redirected Signaling > > > > > > > > > > > > > > > > > > > > > > > > Re-, > > > > > > > > > > > > > > > > > > > > > > > > Focusing on this part of your answer: > > > > > > > > > > > > > > > > > > > > > > > > "No, DNS TTL lifetime does not mean existing > > > > > > > > > > > > session has to be > > > > > > > > > > > disconnected > > > > > > > > > > > > after the TTL expires." > > > > > > > > > > > > > > > > > > > > > > > > This is exactly the disconnect. We are not > > > > > > > > > > > > discussing **DNS > > > > > > > > > > > > TTL** but the validity time of a an alternate > > > > > > > > > > > > server as provided in a DOTS redirect > > > > > > > > > > > signal. > > > > > > > > > > > > > > > > > > > > > > When the server can explicitly re-direct the client, > > > > > > > > > > > why provide the validity time of an alternate server = ? > > > > > > > > > > > > > > > > > > > > [Med] Involving the alternate server is one deployment > > > > > > > > > > mode among > > > > > > > > others. > > > > > > > > > > The current text allows for these two modes: > > > > > > > > > > > > > > > > > > > > (1) redirect upon an explicit signal > > > > > > > > > > (2) automatic fallback upon ttl expiry > > > > > > > > > > > > > > > > > > > > Which one to pick is deployment-specific. > > > > > > > > > > > > > > > > > > > > TTL makes sense only for (2). > > > > > > > > > > > > > > > > > > I don't think (2) is required, HTTP does not support (2) > > > > > > > > > for Temporary > > > > > > > > > re- direct (see > > > > > > > > > https://tools.ietf.org/html/rfc7285#section- > > > 8.5..3). > > > > > > > > > > > > > > > > > > > > > > > > > [Jon] in the general potential overloading case of a > > > > > > > > specific DOTS server, to redirect a DOTS client to an > > > > > > > > alternative DOTS server for a period of > > > > > > > time > > > > > > > > makes sense to me - and then the DOTS client can then come > > > > > > > > back again. So, to me, [2] is a valid option. > > > > > > > > > > > > > > > > [Med] The comparison with 307 is not accurate because that > > > > > > > > code assumes the > > > > > > > > following: > > > > > > > > > > > > > > > > The 307 (Temporary Redirect) status code indicates that > > > > > > > > the > > > target > > > > > > > > resource resides temporarily under a different URI and > > > > > > > > the user > > > > > agent > > > > > > > > MUST NOT change the request method if it performs an > automatic > > > > > > > > redirection to that URI. Since the redirection can > > > > > > > > change over > > > > > time, > > > > > > > > the client ought to continue using the original > > > > > > > > effective request URI > > > > > > > > > > > > > > > > > > > > > > > > > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > > > > > ^^^^ > > > > > > > > for future requests. > > > > > > > > ^^^^^^^^^^^^^^^^^^^ > > > > > > > > > > > > > > > > Supplying the TTL is the only way to master the automatic > > > > > > > > fall back while avoiding contacting the "normal" server > > > > > > > > during the "temporary > > > > > > redirect'. > > > > > > > > > > > > > > > > [Jon] Agreed. > > > > > > > > > > > > > > If TTL expires, DOTS client cannot be re-directed when DDOS > > > > > > > attack is > > > > > active. > > > > > > > If a DOTS client does not honor the TTL value and continues > > > > > > > to use the alternate server, the server should explicitly > > > > > > > re-direct the client and if the client still continues to > > > > > > > use the DOTS server, it should disconnect the (D)TLS session. > > > > > > > > > > > > > > -Tiru > > > > > > > > > > _______________________________________________ > > > > > Dots mailing list > > > > > Dots@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Tue Apr 10 04:00:35 2018 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 5389C126D05 for ; Tue, 10 Apr 2018 04:00:34 -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 LqRBFigbGTOC for ; Tue, 10 Apr 2018 04:00:31 -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 3A7E8126CC4 for ; Tue, 10 Apr 2018 04:00:31 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.90_1) (envelope-from ) id 1f5r0n-0004LK-15; Tue, 10 Apr 2018 12:00:29 +0100 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , , References: <016401d3cc1c$03321200$09963600$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7F97@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <01a701d3cc29$ba915b10$2fb41130$@jpshallow.com> <007501d3ccc2$b49f0b00$1ddd2100$@jpshallow.com> <021301d3cfe7$77e5cbe0$67b163a0$@jpshallow.com> <02b001d3d048$a2c68be0$e853a3a0$@jpshallow.com> <000001d3d0ab$547dec40$fd79c4c0$@jpshallow.com> In-Reply-To: Date: Tue, 10 Apr 2018 12:00:28 +0100 Message-ID: <007701d3d0bb$2404c330$6c0e4990$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0078_01D3D0C3.85CA3CA0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEYhrWXRSNBek+fWBybzdJS41Z0KAI4GsKdAX18SvQDE9KikwNzyn9FAeCfBHcAmG/gMgGrGCDSAZ2/A+cCF5qWXQGy5AXbAg+JyVmkwZjYsA== Content-Language: en-gb Archived-At: Subject: Re: [Dots] Data Channel ACL fragments 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, 10 Apr 2018 11:00:34 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0078_01D3D0C3.85CA3CA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Tiru, See inline [Jon4] Regards Jon From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Konda@mcafee.com] Sent: 10 April 2018 07:10 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] Data Channel ACL fragments [Jon2] The "flags->fragment" definition is ambiguous for an ACE (but valid as to whether to allow a packet to get fragmented or not - is that really a ACE?) which I would like to use. [TR] I don't get it. What purpose does it serve to create a ACE rule using "fragment" bit ? [Jon3] Agreed - This definition has not been thought through for an ACE. I think they have just emulated the DF bit in RFC791 as this general flags definition is the same as for the flags in RFC791. [TR2] You may want to inform the authors of netmod-acl draft, surprisingly BGP flowspec also uses "fragment" bit. [Jon4] On my ToDo list for a clean solution. But we do now have a solution - see below. "Flags->more" definition covers all fragments but the last fragment. "Offset" is unfortunately not a range, but otherwise would get used for the final fragment. ~jon2 [TR] It looks like two ACE entries are required to drop all the fragments ("flags->more" set to 1 in the first ACE and "flags->more" set to 0 in the second ACE). How to use the "Offset" field for the final fragment ? [Jon3] I read "flags-more" to refer to the IP_MF in the IP header (RFC791 MF or more-fragments flag). This is set for all fragments apart from the final (as in last part of packet, not the order in which they are sent - fortunately that early decision to send them in the wrong order was phased out, but still there in some legacy systems!) [TR2] Yes, why can't "flags->more" be set to 0 as one ACE entry to drop the final fragment along with "flags->more" set to 1 to drop the first fragment as another ACE entry so as to drop all fragments to the target ? [Jon4] If "flags->more" is configured and it is configured with a value of 0, this will match not only the final fragment, but also a non-fragmented packet. If "flags->more" is not configured, then this will match a non-fragmented packet only. [Jon4] So, a L4 ACE without "flags->more" defined and "allow", followed by an ACE with "flags->more" = 1 and "drop", followed by an ACE with "flags->more" = 0 and "drop" will cause all fragmented packets to get dropped, but still allow through the non-fragmented packet. So, we have a solution for "allow all traffic to port 53, but drop all fragmented packets". ~jon4 -Tiru [Jon3] But as the final fragment of the sequence could have any offset, the use of the offset field is not that helpful here. Even if we do go with our DOTS fragments definition (but widened to cover all fragments), we still cannot generate a netmod-acl entry for onward processing by an upstream mitigator. [Jon3] FYI, for Juniper, you just need to set 'first-fragment' and 'is-fragment' in their ACL. BGP FlowSpec does support fragmentation detection properly (RFC5575 Type 12 Fragment). -Tiru ------=_NextPart_000_0078_01D3D0C3.85CA3CA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

See inline = [Jon4]

 

Regards

 

Jon

 

 

From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Kond= a@mcafee.com]
Sent: 10 April 2018 07:10
To: Jon = Shallow; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: RE: = [Dots] Data Channel ACL fragments

 

[Jon2] The = “flags->fragment” definition is ambiguous for an ACE (but = valid as to whether to allow a packet to get fragmented or not – = is that really a ACE?) which I would like to use.  =

 

[TR] I = don’t get it. What purpose does it serve to create a ACE rule = using “fragment” bit ?

[Jon3] = Agreed – This definition has not been thought through for an = ACE.  I think they have just emulated the DF bit in RFC791 as this = general flags definition is the same as for the flags in = RFC791.

 

[TR2] You may want to inform the authors of netmod-acl = draft, surprisingly BGP flowspec also uses “fragment” = bit.

[Jon4] On = my ToDo list for a clean solution.  But we do now have a solution = – see below.

 

“Flags->more” definition covers = all fragments but the last fragment. “Offset” is = unfortunately not a range, but otherwise would get used for the final = fragment.

~jon2

 

[TR] It = looks like two ACE entries are required to drop all the fragments = (“flags->more” set to 1 in the first ACE and = “flags->more” set to 0 in the second ACE). How to use the = “Offset”  field for the final fragment = ?

 

[Jon3] I = read “flags-more” to refer to the IP_MF in the IP header = (RFC791 MF or more-fragments flag).  This is set for all fragments = apart from the final (as in last part of packet, not the order in which = they are sent – fortunately that early decision to send them in = the wrong order was phased out, but still there in some legacy = systems!)

 

[TR2] Yes, why can’t “flags->more” be = set to 0 as one ACE entry to drop the final fragment along with = “flags->more” set to 1 to drop the first fragment as = another ACE entry so as to drop all fragments to the target = ?

[Jon4] If “flags->more” is = configured and it is configured with a value of 0, this will match not = only the final fragment, but also a non-fragmented packet.  If = “flags->more” is not configured, then this will match a = non-fragmented packet only.

[Jon4] So, = a L4 ACE without “flags->more” defined and = “allow”, followed by an ACE with = “flags->more” =3D 1 and “drop”, followed by = an ACE with “flags->more” =3D 0 and “drop” = will cause all fragmented packets to get dropped, but still allow = through the non-fragmented packet.  So, we have a solution = for

“allow all traffic to port 53, but drop = all fragmented packets”.

~jon4

 

-Tiru

 

[Jon3] But = as the final fragment of the sequence could have any offset, the use of = the offset field is not that helpful here.  Even if we do go with = our DOTS fragments definition (but widened to cover all fragments), we = still cannot generate a netmod-acl entry for onward processing by an = upstream mitigator.

 

[Jon3] FYI, = for Juniper, you just need to set ‘first-fragment’ and = ‘is-fragment’ in their ACL.  BGP FlowSpec does support = fragmentation detection properly (RFC5575 Type 12 = Fragment).

 

 

-Tiru

------=_NextPart_000_0078_01D3D0C3.85CA3CA0-- From nobody Tue Apr 10 04:36:49 2018 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 AEDED1270A7 for ; Tue, 10 Apr 2018 04:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 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, T_DKIMWL_WL_HIGH=-0.01, 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 x2uUoEJ_SAyL for ; Tue, 10 Apr 2018 04:36:45 -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 AECCB126D05 for ; Tue, 10 Apr 2018 04:36:44 -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=1523360203; 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: dlp-product:dlp-version:dlp-reaction: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-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: 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=6 XD/0CHmeOlJBD33yM9e3nLzNh/MJAcKVvRI3PHBvi U=; b=JHNs0LTMR5FrLOB4edADWhirHGX0ZaEndZP0DxKJ1rFw ZUJj8tEHVIsNXRI5wUCG0BRtbdH27QYQ/Vao21uiDWTkTQ6AmN WyWpY7dv7qLWktkyS8FaT1kaoXDKBLjXbuJgILtPBF5LI3D+Q+ GURoXDzvV2k23lZH7JVXdBXF+1Q= Received: from DNVEXAPP1N04.corpzone.internalzone.com (unknown [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 5812_8dfb_b78f8e96_0f60_438b_afbe_28a55f473ad2; Tue, 10 Apr 2018 06:36:42 -0500 Received: from DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 10 Apr 2018 05:33:48 -0600 Received: from DNVEXUSR1N10.corpzone.internalzone.com (10.44.48.83) by DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 10 Apr 2018 05:33:48 -0600 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXUSR1N10.corpzone.internalzone.com (10.44.48.83) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Tue, 10 Apr 2018 05:33:47 -0600 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (10.44.176.242) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 10 Apr 2018 05:33:47 -0600 Received: from DM5PR16MB1436.namprd16.prod.outlook.com (10.173.210.150) by DM5PR16MB1498.namprd16.prod.outlook.com (10.173.211.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.653.12; Tue, 10 Apr 2018 11:33:45 +0000 Received: from DM5PR16MB1436.namprd16.prod.outlook.com ([fe80::51c:2319:27b3:5250]) by DM5PR16MB1436.namprd16.prod.outlook.com ([fe80::51c:2319:27b3:5250%18]) with mapi id 15.20.0653.017; Tue, 10 Apr 2018 11:33:45 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: [Dots] Data Channel ACL fragments Thread-Index: AdPMHAMfDWFlXvb3TSeAr5MVkYUzIgAA3pEAAAKPJoAAIuTfcAADWaQAAADopUAAyEgtgAACNjegABYTlwAAEYzK0AAHIEOAAAC6rLAAAzlEAAAAT7Kg Date: Tue, 10 Apr 2018 11:33:45 +0000 Message-ID: References: <016401d3cc1c$03321200$09963600$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7F97@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <01a701d3cc29$ba915b10$2fb41130$@jpshallow.com> <007501d3ccc2$b49f0b00$1ddd2100$@jpshallow.com> <021301d3cfe7$77e5cbe0$67b163a0$@jpshallow.com> <02b001d3d048$a2c68be0$e853a3a0$@jpshallow.com> <000001d3d0ab$547dec40$fd79c4c0$@jpshallow.com> <007701d3d0bb$2404c330$6c0e4990$@jpshallow.com> In-Reply-To: <007701d3d0bb$2404c330$6c0e4990$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [185.221.69.46] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1498; 7:WOeCIlz6XeKcYjzj+fECThlEGZKl+t+QhohoWaS7LZlj8ICQjd0oo10gcrCk3xfs5E6IQPMWtTNSzFCIBMyCMD113GMevTRIKGcEPjH3mc8du5r8lMpBemwS53mvySzeWDOa1wU4DdTamfeebEG8ZdKSjkybqdFB0afcJq53o7YJr0lczSGxvEC2GAL3EV1bSAP00JQSxrVnqE0CUC8b0HFSZpoVeV/0n1wWCaGCf7u4i1fdmeE69SNcoIBzXZqI x-ms-exchange-antispam-srfa-diagnostics: SOS; X-MS-Office365-Filtering-Correlation-Id: d59b2ffa-fae9-4ec3-6118-08d59ed6ebc2 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603328)(7153060)(7193020); SRVR:DM5PR16MB1498; x-ms-traffictypediagnostic: DM5PR16MB1498: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(18271650672692)(21748063052155)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231221)(944501327)(52105095)(6041310)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(6072148)(201708071742011); SRVR:DM5PR16MB1498; BCL:0; PCL:0; RULEID:; SRVR:DM5PR16MB1498; x-forefront-prvs: 0638FD5066 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(376002)(366004)(346002)(396003)(39380400002)(69234005)(189003)(199004)(32952001)(6246003)(7696005)(2906002)(99286004)(74316002)(26005)(25786009)(6116002)(790700001)(3846002)(76176011)(106356001)(7736002)(2201001)(105586002)(5660300001)(2501003)(102836004)(86362001)(229853002)(93886005)(5250100002)(110136005)(236005)(53936002)(55016002)(446003)(59450400001)(186003)(81156014)(8676002)(3660700001)(97736004)(81166006)(6306002)(316002)(80792005)(11346002)(72206003)(476003)(486006)(9686003)(2900100001)(54896002)(68736007)(33656002)(6506007)(19609705001)(14454004)(53546011)(6436002)(3280700002)(8936002)(66066001)(478600001)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1498; H:DM5PR16MB1436.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: HXCq/FFliGL2M+cWA6l6zzGrYpOsohUOMWwwn4oUA5atBPkT4wN+LR2f0ni6CU4BNyjmpCTy+z5GY20JTMtZwM2u5SceIenEvRU/ajFGWBN+R3jUtP2/E9qMmP6i4/GooW4Bx7O/D2tTfLNE6VTSEyTEu5R8++oHSKjeBJPi6lsBFYHBivFVuIIh182TuujNHg5jjDNbhdWnFA1VXx2BR4euaR2MFD4EjJj7OlOvdLlBQiXNPf2c2XZ8pJ+J4+8hUbOS8n9DUsYhalhII0g7+6JqW9RtUsUomW+j/tKyqF0EeIefBZ+EHER1lTswxY+2nx6fs+ZV5Lx5SFjYr/J/wvwRpyreW8AAZ131x7MH4FJAu3Y4E1XzH9m3UNvQ0YBcllwEYxyAcGXfQkZOkzagOTF/PHK8M6vItI6X3zRU60E= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB143609A08263017E97C71A17EABE0DM5PR16MB1436namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: d59b2ffa-fae9-4ec3-6118-08d59ed6ebc2 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2018 11:33:45.7899 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1498 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 <6261> : inlines <6554> : streams <1783615> : uri <2623078> Archived-At: Subject: Re: [Dots] Data Channel ACL fragments 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, 10 Apr 2018 11:36:48 -0000 --_000_DM5PR16MB143609A08263017E97C71A17EABE0DM5PR16MB1436namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please see inline [TR3] From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Tuesday, April 10, 2018 4:30 PM To: Konda, Tirumaleswar Reddy ; mohamed= .boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] Data Channel ACL fragments Hi Tiru, See inline [Jon4] Regards Jon From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Konda@mcafee.com= ] Sent: 10 April 2018 07:10 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] Data Channel ACL fragments [Jon2] The "flags->fragment" definition is ambiguous for an ACE (but valid = as to whether to allow a packet to get fragmented or not - is that really a= ACE?) which I would like to use. [TR] I don't get it. What purpose does it serve to create a ACE rule using = "fragment" bit ? [Jon3] Agreed - This definition has not been thought through for an ACE. I= think they have just emulated the DF bit in RFC791 as this general flags d= efinition is the same as for the flags in RFC791. [TR2] You may want to inform the authors of netmod-acl draft, surprisingly = BGP flowspec also uses "fragment" bit. [Jon4] On my ToDo list for a clean solution. But we do now have a solution= - see below. "Flags->more" definition covers all fragments but the last fragment. "Offse= t" is unfortunately not a range, but otherwise would get used for the final= fragment. ~jon2 [TR] It looks like two ACE entries are required to drop all the fragments (= "flags->more" set to 1 in the first ACE and "flags->more" set to 0 in the s= econd ACE). How to use the "Offset" field for the final fragment ? [Jon3] I read "flags-more" to refer to the IP_MF in the IP header (RFC791 M= F or more-fragments flag). This is set for all fragments apart from the fi= nal (as in last part of packet, not the order in which they are sent - fort= unately that early decision to send them in the wrong order was phased out,= but still there in some legacy systems!) [TR2] Yes, why can't "flags->more" be set to 0 as one ACE entry to drop the= final fragment along with "flags->more" set to 1 to drop the first fragmen= t as another ACE entry so as to drop all fragments to the target ? [Jon4] If "flags->more" is configured and it is configured with a value of = 0, this will match not only the final fragment, but also a non-fragmented p= acket. If "flags->more" is not configured, then this will match a non-frag= mented packet only. [TR3] net-mod-acl says "Setting the value to 0 indicates this is the last f= ragment, and setting the value to 1 indicates more fragments are coming.". = I think it means, if "flags->more" is set to zero and offset is not zero th= en it indicates this is the last fragments; the flags can be used in isolat= ion without comparing if offset value is zero or non-zero. We should check = with netmod-acl authors for confirmation. [Jon4] So, a L4 ACE without "flags->more" defined and "allow", followed by = an ACE with "flags->more" =3D 1 and "drop", followed by an ACE with "flags-= >more" =3D 0 and "drop" will cause all fragmented packets to get dropped, b= ut still allow through the non-fragmented packet. So, we have a solution f= or "allow all traffic to port 53, but drop all fragmented packets". [TR3] I don't think the above solution will work. In the above line, I thin= k you meant L3 ACE, and the first fragment will match the first entry and = is allowed. -Tiru ~jon4 -Tiru [Jon3] But as the final fragment of the sequence could have any offset, the= use of the offset field is not that helpful here. Even if we do go with o= ur DOTS fragments definition (but widened to cover all fragments), we still= cannot generate a netmod-acl entry for onward processing by an upstream mi= tigator. [Jon3] FYI, for Juniper, you just need to set 'first-fragment' and 'is-frag= ment' in their ACL. BGP FlowSpec does support fragmentation detection prop= erly (RFC5575 Type 12 Fragment). -Tiru --_000_DM5PR16MB143609A08263017E97C71A17EABE0DM5PR16MB1436namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please se= e inline [TR3]

 

From:<= /span> Jon Shallow [mailto:s= upjps-ietf@jpshallow.com]
Sent: Tuesday, April 10, 2018 4:30 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; mohamed.boucadair@orange.com; dots@ietf.org
Subject: RE: [Dots] Data Channel ACL fragments

 

Hi Tiru= ,

&n= bsp;

See inl= ine [Jon4]

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

&n= bsp;

From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Kon= da@mcafee.com]
Sent: 10 April 2018 07:10
To: Jon Shallow; moh= amed.boucadair@orange.com; dots@ietf.org
Subject: RE: [Dots] Data Channel ACL fragments

 

[Jon2] The “flag= s->fragment” definition is ambiguous for an ACE (but valid as to w= hether to allow a packet to get fragmented or not – is that really a = ACE?) which I would like to use. 

 

[TR] I don’t get= it. What purpose does it serve to create a ACE rule using “fragment&= #8221; bit ?

[Jon3] Agreed – = This definition has not been thought through for an ACE.  I think they= have just emulated the DF bit in RFC791 as this general flags definition i= s the same as for the flags in RFC791.

 

[TR2] You may want to inform the authors of netmod-a= cl draft, surprisingly BGP flowspec also uses “fragment” bit.

[Jon4] On my ToDo list= for a clean solution.  But we do now have a solution – see belo= w.

 

 

“Flags->more&= #8221; definition covers all fragments but the last fragment. “Offset= ” is unfortunately not a range, but otherwise would get used for the = final fragment.

~jon2

 

[TR] It looks like two= ACE entries are required to drop all the fragments (“flags->more&= #8221; set to 1 in the first ACE and “flags->more” set to 0 = in the second ACE). How to use the “Offset”  field for the= final fragment ?

 

[Jon3] I read “f= lags-more” to refer to the IP_MF in the IP header (RFC791 MF or more-= fragments flag).  This is set for all fragments apart from the final (= as in last part of packet, not the order in which they are sent – fortunately that early decision to send them in the wrong= order was phased out, but still there in some legacy systems!)<= /span>

 

[TR2] Yes, why can’t “flags->moreR= 21; be set to 0 as one ACE entry to drop the final fragment along with R= 20;flags->more” set to 1 to drop the first fragment as another ACE= entry so as to drop all fragments to the target ?

[Jon4] If “flags= ->more” is configured and it is configured with a value of 0, this= will match not only the final fragment, but also a non-fragmented packet.&= nbsp; If “flags->more” is not configured, then this will match a non-fragmented packet only.

 

[TR3] net-mod-acl says "Setting the value to 0 = indicates this is the last fragment, and setting the value to 1 indicates m= ore fragments are coming.". I think it means, if “flags->more= ” is set to zero and offset is not zero then it indicates this is the last fragments; the flags can be used in isolation without com= paring if offset value is zero or non-zero. We should check with netmod-acl= authors for confirmation.

 

[Jon4] So, a L4 ACE wi= thout “flags->more” defined and “allow”, followe= d by an ACE with “flags->more” =3D 1 and “drop”,= followed by an ACE with “flags->more” =3D 0 and “drop= ” will cause all fragmented packets to get dropped, but still allow through the non-fragmented packet.  So, we h= ave a solution for

“allow all traff= ic to port 53, but drop all fragmented packets”.

 

[TR3] I don’t think the above solution will wo= rk. In the above line, I think you  meant L3 ACE, and the first fragme= nt will match the first entry and is allowed.

 

-Tiru

 

~jon4

 

-Tiru

 

[Jon3] But as the fina= l fragment of the sequence could have any offset, the use of the offset fie= ld is not that helpful here.  Even if we do go with our DOTS fragments= definition (but widened to cover all fragments), we still cannot generate a netmod-acl entry for onward processing by an up= stream mitigator.

 

[Jon3] FYI, for Junipe= r, you just need to set ‘first-fragment’ and ‘is-fragment= ’ in their ACL.  BGP FlowSpec does support fragmentation detecti= on properly (RFC5575 Type 12 Fragment).

 

 

-Tiru

--_000_DM5PR16MB143609A08263017E97C71A17EABE0DM5PR16MB1436namp_-- From nobody Tue Apr 10 04:45:48 2018 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 B4409126DCA for ; Tue, 10 Apr 2018 04:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 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, T_DKIMWL_WL_HIGH=-0.01, 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 uFjcDmzjKt9Y for ; Tue, 10 Apr 2018 04:45: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 45B5B126D74 for ; Tue, 10 Apr 2018 04:45:41 -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=1523360740; 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: dlp-product:dlp-version:dlp-reaction: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-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: 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=4 dW0BR2c/si4mUMGISwPtTQq6EYefZXRAWNr/B339p U=; b=qWlo2QZzqZvrpFOozJqRCcSYEyVvz1PBZxgYGQO3NMqt ja3/ANgiNnt00RBTI0V9dsG11FLxcO+hwropqs3WOPv9sF5Kto sLIV7X9coaSa+rKKrdrC6TJITILQQ1rmDHtUX4xzF7o+js8u9j gP2P30cBz2zkZv7Tnw/bWluFjlY= Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 5837_6f87_50cc17c4_22d4_4cad_8dc1_d7e7ee79650f; Tue, 10 Apr 2018 06:45:39 -0500 Received: from DNVEXUSR1N11.corpzone.internalzone.com (10.44.48.84) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 10 Apr 2018 05:44:59 -0600 Received: from DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) by DNVEXUSR1N11.corpzone.internalzone.com (10.44.48.84) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 10 Apr 2018 05:44:58 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Tue, 10 Apr 2018 05:44:58 -0600 Received: from NAM01-BY2-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.1347.2; Tue, 10 Apr 2018 05:44:57 -0600 Received: from DM5PR16MB1436.namprd16.prod.outlook.com (10.173.210.150) by DM5PR16MB1771.namprd16.prod.outlook.com (10.172.44.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.653.12; Tue, 10 Apr 2018 11:44:56 +0000 Received: from DM5PR16MB1436.namprd16.prod.outlook.com ([fe80::51c:2319:27b3:5250]) by DM5PR16MB1436.namprd16.prod.outlook.com ([fe80::51c:2319:27b3:5250%18]) with mapi id 15.20.0653.017; Tue, 10 Apr 2018 11:44:56 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: [Dots] IETF 101 Presentation Data Channel Issue #4 Thread-Index: AdPE/QAkDtOD9YeqSAaov9+szxQnSQAoMdfAAAKPC+AAA+QiAAAEVj7wAfiJ0YAAA7+48AABBD0AAByNZ3AAbRM0AAABj4SQAALuHIAAAB7MkAAUhSeAABEJfQAAB3/zgAABjIUwAAFxZoAAAijawA== Date: Tue, 10 Apr 2018 11:44:56 +0000 Message-ID: References: <008401d3c4fd$216d0840$644718c0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF1067@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <014801d3c5b7$94c67f00$be537d00$@jpshallow.com> <009a01d3cdab$150b4c40$3f21e4c0$@jpshallow.com> <00cf01d3cdbe$24876650$6d9632f0$@jpshallow.com> <01fd01d3cfe4$a71b6580$f5523080$@jpshallow.com> <024901d3cff6$9d4beea0$d7e3cbe0$@jpshallow.com> <02c301d3d049$2f60cf20$8e226d60$@jpshallow.com> <000a01d3d 0ab$55bef7c0$013ce740$@jpshallow.com> <005e01d3d0b7$4b3d7db0$e1b87910$@jpshallow.com> In-Reply-To: <005e01d3d0b7$4b3d7db0$e1b87910$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [185.221.69.46] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1771; 7:oghNTd4/4ZHvZIEoS8Ovmey7CE++tOG6waJLhufeg8O0+A7NWnX+EO7vfrVwuKG5sc7iduh09oadibDcXqn0nz9ktIC5Ad2Q/Smr5mQKLcAS9zRc0Q3afce9ywv+lFzTjEJh8sYqz5hlCAcFZb8gq3YulPTMaN3OXYLYzVxr4CrFOiSItlMkx0WcOix1J7uaag7a3O0tF7lM4COP+CXujLRA3EA2oPCBYF5ZBOkcaU83tJ0lOUDeNgZmMLrkN4lz x-ms-exchange-antispam-srfa-diagnostics: SOS; X-MS-Office365-Filtering-Correlation-Id: 25a6db5b-7bbd-403c-6657-08d59ed87b4d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603328)(7153060)(7193020); SRVR:DM5PR16MB1771; x-ms-traffictypediagnostic: DM5PR16MB1771: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(192374486261705)(18271650672692)(21748063052155)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(3231221)(944501327)(52105095)(10201501046)(93006095)(93001095)(6041310)(20161123560045)(20161123558120)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:DM5PR16MB1771; BCL:0; PCL:0; RULEID:; SRVR:DM5PR16MB1771; x-forefront-prvs: 0638FD5066 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(366004)(39860400002)(39380400002)(376002)(5383002)(32952001)(199004)(189003)(478600001)(5660300001)(446003)(33656002)(106356001)(11346002)(68736007)(229853002)(81156014)(81166006)(25786009)(8676002)(486006)(345774005)(19609705001)(110136005)(476003)(55016002)(102836004)(6436002)(186003)(59450400001)(5250100002)(105586002)(2906002)(97736004)(6116002)(53546011)(76176011)(3280700002)(2900100001)(3846002)(7696005)(66066001)(3660700001)(790700001)(6506007)(14454004)(2501003)(80792005)(54896002)(7736002)(74316002)(53946003)(316002)(8936002)(93886005)(99286004)(72206003)(53936002)(26005)(6246003)(9686003)(236005)(86362001)(6306002)(2201001)(91024005)(85282002)(559001)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1771; H:DM5PR16MB1436.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: qrh7pdXIzjwb2+rjWu3B6lGy0ZhhzRc0vWNI4oiFrkrQoPJv/YKeGGV97Ys1M04PYu73Vybf53tfqsUjRZ4rPKmf5HswV8QU0DcN9GxOxKzxK1lVnueeMUrTqmo+IzygG+iGcUqtGj+4G0Yz5eaN1PVwQtDCvx16YYEP3TnIXFJQlltx0doe8Z5AzLl7GkkIy6lJElJZPM9kVBXBJhIvi4Dm97nzsuzflPN6URoMT6kec4iIvwbYWAps+lsLnxzJs0UTEUy11LcTg3Rl+WXaFUSKDpys/WR1KG1PjneXe9ffEFKF0XE1WiQu81L3Pbp/S5j9d5pg+KjdeQurIVoNFiv2V8P4ET4wuaJc70eDeXeP7oTU3lhcw2yfUnVFF08VN3v4e/SeUKv1vSXqg22Zin+Xa7/FF7qmjn7USD6U7GA= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB14364E0122B6191B598F9DE1EABE0DM5PR16MB1436namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 25a6db5b-7bbd-403c-6657-08d59ed87b4d X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2018 11:44:56.1077 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1771 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 <6261> : inlines <6554> : streams <1783616> : uri <2623082> Archived-At: Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 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, 10 Apr 2018 11:45:47 -0000 --_000_DM5PR16MB14364E0122B6191B598F9DE1EABE0DM5PR16MB1436namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Please see inline [TR5] From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Tuesday, April 10, 2018 4:03 PM To: Konda, Tirumaleswar Reddy ; mohamed= .boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 Hi Tiru, See inline [Jon4] Regards Jon From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Monday, April 9, 2018 2:55 PM To: Konda, Tirumaleswar Reddy >; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 Hi Tiru, If a DOTS client knows the full scope of the Networks that it is allowed to= use in a ACL or mitigate request, and the DOTS server limits any update fr= om that client to the scope of Networks (with any unexpected side effects t= hat may have), then there is no difference in my mind as to whether the DOT= S clients fills in the destination-network, or the DOTS server does so on t= he DOTS client's behalf before ACL instantiation if destination-network is = not defined. [TR] The above model only works when the DOTS server and DOTS client are di= rectly communicating with each other (In the above, the DOTS server knows t= he DOTS client identity to enforce the scope but will not the DOTS client i= dentity in the presence of a client-domain DOTS gateway). [Jon1] The last para of "10. Security Considerations" states DOTS servers MUST verify that requesting DOTS clients are entitled to trigger actions on a given IP prefix. That is, only actions on IP resources that belong to the DOTS client' domain MUST be authorized by a DOTS server. The exact mechanism for the DOTS servers to validate that the target prefixes are within the scope of the DOTS client's domain is deployment-specific. [Jon1] So it makes no difference if the DOTS client happens to be an agent = part of a client-domain DOTS gateway. If the client-domain DOTS gateway is= hiding all the 'behind' clients and presenting as single client, there is = no issue. However, if the 'behind' clients are presented as 2 or more 'cui= d's by the DOTS gateway, then either the scope is per 'cuid', or if 'cdid's= are being applied by the upstream server domain DOTS gateway then on a per= 'cdid' basis if wanted. For a client behind a client domain DOTS gateway, there may be non public I= P addresses that the (DMS) client is responsible for, but these should neve= r be sent out through the DOTS gateway (and should be rejected by the DOTS = server as out of scope). There does have to be a common agreement between = DOTS client & DOTS server as to what Networks are in scope, but the DOTS cl= ient currently cannot request this from the DOTS server and has to be agree= d out of band. [TR] I don't see a new problem, even when a DOTS client sends a mitigation = request it needs to know if the targets conveyed in the mitigation request = are in its scope or not. [Jon1] but again, the DOTS server MUST verify the IP prefix is valid, so ha= s to know scope. I agree that the DOTS client (or client domain DOTS gatew= ay) needs to know (today out of band) what is the scope of what is valid to= request. The challenge comes when the DOTS server's scope is reconfigured= , but not yet updated on the DOTS client. [TR2] The scope would be first updated on the DOTS client domain and then o= n the DOTS server (e.g. IP prefix re-numbering). [Jon2] I was more thinking of a DOTS client that got missed off a list when= the DOTS server was updated. Normally though, they should be kept in sync= but which one gets updated first is uncertain to me. [TR3] If the DOTS client missed update, it will have various other problems= ; any network policy based on destination network IP/prefix will fail. DOTS= client should support mechanisms to receive the latest network configurati= on after missing critical updates because it was offline or its connectivity was lost. [Jon3] So to me, we need to add in something to the data channel protocol s= o that a DOTS client can request as to what is the network current scope it= is allowed to ask for ACL/Mitigation for. [TR4] I don't think so, you may want to look into SIG-007 requirement, it s= ays "A DOTS client may obtain the mitigation scope through direct provision= ing or through implementation-specific methods of discovery." [Jon4] That does not preclude us adding it into the DOTS data protocol YANG= model. [TR5] No, it clearly says configurating the mitigation scope on the DOTS cl= ient is outside the scope of DOTS protocols. There is no reason as to why the DOTS server cannot maintain a valid scope = of Networks that the client domain DOTS gateway is allowed to request for v= alidity checking - unless I am missing something? [TR] You are partially right, the DOTS server does not know the valid scope= of prefixes that a DOTS client behind client-domain DOTS gateway is allowe= d to request. [Jon1] Again, the last para of 10. stands here, and so the scope has to be = known by the DOTS server. [TR] Yes, but it may not know the scope of a DOTS client behind a client-do= main DOTS gateway. [Jon2] But it will know what the client-domain DOTS gateway is allowed to p= ass through in terms of Destination Network. The client-domain DOTS gatewa= y will separately need to know what Destination networks are allowed to get= out through the gateway. Troubleshooting has kept me in a job for more years than I care to remember= , anything to aid troubleshooting is what I am interested in and so totally= agree that rogue DOTS client's capabilities need to be kept under control = with suitable logging to aid diagnosis is a major plus. However in this ca= se, the implicit rule is no different to the DOTS client requesting the ful= l Networks scope in an ACL request. [TR] If the client is not authorized to request the full network scope, it = can detected by the client-domain DOTS gateway and rejects the filtering ru= le by comparing the destination-networks specified in the ACE. [Jon1] Agreed, it is the responsibility of the client domain DOTS gateway t= o only allow out valid networks that are valid within the DOTS server's sco= pe. [Jon1] Should we support a way for the client domain DOTS gateway (i.e. DO= TS client agent) to programmatically get the current valid network scope fr= om the DOTS server? [TR2] It will not solve the above problem of detecting and rejecting a roug= e (or misconfigured) DOTS client behind client domain DOTS gateway sending = ACL without specifying destination-network. [Jon2] Hmm. If the client-domain DOTS gateway is restricted in scope as to= what it is allowed to request, and a rogue client behind the gateway does = not specify a destination-network, then when the request passes through the= gateway the upstream DOTS server will only use the scope allowed for that = specific client-domain DOTS gateway. Again, it is exactly the same as if t= he rogue client was to specify the full set of allowed scope as a set of de= stination networks in terms of damage capabilities. [TR3] No, the client-domain DOTS gateway can detect and reject the ACL beca= use the rouge DOTS client has specified destination-network not under its s= cope. [Jon3] You are missing my point. Agreed that the client-domain DOTS gatewa= y must sanity check what is passed through. However, there will be a set o= f Networks that are allowed through the DOTS gateway which are within the d= efined scope of what the DOTS server allows. This "allowed through network= s" can legitimately be set by the DOTS client in destination-network, or th= e DOTS server can fill in the same set of networks in the ACL instantiation= if destination-networks was empty and the potential side effects damage ca= used will be the same. [TR4] I understand, you seem to be focusing on only DDoS detectors and IDMS= acting as DOTS clients . They will be authorized to enforce ACL for the en= tire DOTS client domain, but an application server acting as a DOTS client = will only be authorized to enforce ACL for the IP addresses/prefixes used b= y the it and not for the entire DOTS client domain. These type of DOTS clie= nts must fill the destination-network, so the client-domain DOTS gateway ca= n detect and reject ACL requests populated with destination IP addresses/pr= efixes the application server does not use. [Jon4] I agree that the client-domain DOTS gateway has to have a notion of= which client can request what - i.e. maintaining a scope of what the indiv= idual client can ask for. Not convinced that we clearly define that a clie= nt-domain DOTS gateway must maintain a Destination scope though. There is = no reason as to why a client-domain DOTS gateway cannot fill in an empty de= stination-network with the specifics for the requesting client though befor= e passing it through upstream - but it does look tidier if the client does = specify the destination-network. [TR5] It significantly increases the work on the client-domain gateways, it= will have to modify the response (to remove the destination-network from t= he ACE) when the client is using GET to retrieve the installed filtering ru= les and will have to remember if the destination-network was updated by it= or not. The client anyway knows its mitigation scope, and cannot not a mit= igation request without specifying the mitigation scope (similar to destina= tion-networks specified in ACE). -Tiru ~jon2 -Tiru ~jon1 -Tiru Regards Jon From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Konda@mcafee.com= ] Sent: 07 April 2018 06:48 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 Hi Jon, DOTS clients (intelligent DDoS mitigation system, application server) will = know the destination networks, what kind of DOTS clients will not know the = destination networks they are allowed to use ? DOTS clients could be behind client-domain DOTS gateway, DOTS server will h= ave no way to validate the DOTS client identity sending the ACE request to = determine the destination IP addresses in its scope, it will only know the = destination IP addresses in the DOTS client domain scope. Further, the implicit rule can be misused by compromised DOTS clients (e.g.= black-list good traffic to the entire DOTS client domain) and it's a trou= bleshooting nightmare to find the culprit device adversely impacting the en= tire network. Cheers, -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Friday, April 6, 2018 9:14 PM To: Konda, Tirumaleswar Reddy >; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 Hi Tiru, The DOTS server is likely to have a scope of IP addresses that are valid fo= r the client to ask for protection for based on the cuid or cdid. The DOTS client may have some knowledge of the scope IPs by some out of ban= d method, but programmatically cannot ask the server what they are. If a client specifies a destination network that is out of the valid scope = of IP addresses, then the ACE request will get rejected. The client may th= en have a challenge to work out what destination networks it is allowed to = use. How does a client set up a blacklist for all the IPS within his allowed sco= pe if it does not know what the scope is? If the client has not provided a destination network, then the DOTS server = can auto-fill in the missing information at the time of the ACE instantiati= on - and this then handles if the scope of IP addresses change. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 06 April 2018 16:19 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 I don't understand how the DOTS server/mitigation will fill it in at time o= f ACE instantiation, and why can't the DOTS client fill the destination net= work details ? -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Friday, April 6, 2018 6:58 PM To: Konda, Tirumaleswar Reddy >; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 Hi there, There is no current way to request of a DOTS Server as to what is the set o= f IP networks that a DOTS client can use either within a mitigation request= or to set up an ACL other than by "testing for ok or not ok" with lots of = different IP addresses. There is a reasonable likelihood of the scope of valid IPs from the Server'= s perspective will change over time. So, unless a DOTS client wants to con= trol a specific destination network, then my suggestion would be to leave t= he ACE destination network empty and for the DOTS Server / DOTS mitigator (= how is out of scope) to fill it in at time of ACE instantiation. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 27 March 2018 13:49 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 Please see inline [TR] From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Tuesday, March 27, 2018 4:07 PM To: Konda, Tirumaleswar Reddy >; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 Hi Tiru / Med See inline [Jon] Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 27 March 2018 09:47 To: mohamed.boucadair@orange.com; Jon = Shallow; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 I also support to mandate destination-network for immediately enforced filt= ering rules. [Jon] This can be enforced / inserted by the DOTS Server for all the destin= ation networks of the domain that the DOTS client 'belongs' to. That said,= it would be good to always have the destination network in an ACL as it ca= n be validated and cross-checked whenever the legitimate set of domain prot= ected IPs are updated. [Jon] However, what happens to the Destination network in the case of a cal= l home DOTS client that becomes a quasi DOTS server and the Destination net= works are somewhere out on the Internet? [TR] DDOS is a targeted attack, so the DOTS client can specify the destinat= ion network targeted by devices in the DOTS server domain and the DOTS serv= er can validate if the destination network is indeed targeted by its device= s. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.......boucad= air@orange.com Sent: Tuesday, March 27, 2018 1:09 PM To: Jon Shallow >; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 Hi Jon, Thank you for the comments. Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : lundi 26 mars 2018 14:23 =C0 : dots@ietf.org Objet : [Dots] IETF 101 Presentation Data Channel Issue #4 Hi there, As per Med's presentation to the IETF 101 Issue #4: Per-Domain or Per-client Filters? * Conclusion - Filters that are activated only during mitigation time are on a per-clien= t basis * Filters are per-domain when are immediately applied "Filters are per-domain when are immediately applied" is what I have an cha= llenge with. If we have a compromised or rogue DOTS client, the simple use of something = like curl, along with the client certificates etc. can be used to generate = any ACL with activation-type :=3D 'immediate' which is then immediately app= lied for all traffic within the domain as per the above. [Med] Yes. FWIW, this attack is called out in the security considerations s= ection: "Nevertheless, an attacker who can access a DOTS client is technically capable of launching various attacks, such as: ..; o Set invalid ACL entries, which may prevent legitimate traffic from being forwarded. Likewise, invalid ACL entries may lead to forward DDoS traffic. " [Jon] Agreed that the attack is covered off in the Security section, but we= should be limiting the possibility / scope of the attack vector by enforci= ng some rules as to what is / is not allowed. Allowing a DOTS client to be= able to affect all the traffic within the domain is a huge risk to me and = should not be allowed. So, a ACL that blacklists the DNS server, or drops all port 443 traffic etc= . can easily cause all of the other clients / devices within the domain to = be taken off air. Putting the intelligence into the DOTS server to not all= ow this to happen could be a challenge. [The signal channel is much harder to compromise and affect traffic flows t= o other areas within the domain] I believe that an ACL instantiated by a DOTS client (immediate or when-miti= gating) should only apply to the DOTS client's traffic which means that the= destination-network has to be a part of the ACL, whether implicitly added = by the DOTS server, or by the DOTS client and suitably validated. [Med] Putting aside that I don't parse "DOTS client's traffic", [Jon] I was referring to all the traffic flows that a DOTS client can legit= imately request control of to the DOTS server that are within the scope of = what the DOTS client is protecting (which may or may not be the DOTS client= 's IP address). I interpret your answer as a support to this question raised for issue #4: * "Should we mandate destination-network to be present for immediate= ly enforced filters?" [Jon] See response to Tiru's Agreement above. ~Jon There is nothing to stop the DOTS server or DOTS mitigator merging common A= CLs to reduce the number of ACLs within the mitigation device. As a side note "mitigation-time" is perhaps a bad name as it implies a time= period - something like "when-mitigating" to me is clearer. [Med] Fixed in my local copy. Thank you. Regards Jon --_000_DM5PR16MB14364E0122B6191B598F9DE1EABE0DM5PR16MB1436namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Please se= e inline [TR5]

 

From:<= /span> Jon Shallow [mailto:s= upjps-ietf@jpshallow.com]
Sent: Tuesday, April 10, 2018 4:03 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; mohamed.boucadair@orange.com; dots@ietf.org
Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Hi Tiru= ,

&n= bsp;

See inl= ine [Jon4]

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

&n= bsp;

&nbs= p;

From:<= /span> Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Monday, April 9, 2018 2:55 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; mohamed.boucadair@orange.co= m; dots@ietf.org
Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Hi Tiru= ,

&n= bsp;

If a DO= TS client knows the full scope of the Networks that it is allowed to use in= a ACL or mitigate request, and the DOTS server limits any update from that= client to the scope of Networks (with any unexpected side effects that may have), then there is no difference in= my mind as to whether the DOTS clients fills in the destination-network, o= r the DOTS server does so on the DOTS client’s behalf before ACL inst= antiation if destination-network is not defined.

 

[TR] The above model only works= when the DOTS server and DOTS client are directly communicating with each = other (In the above, the DOTS server knows the DOTS client identity to enfo= rce the scope but will not the DOTS client identity in the presence of a client-domain DOTS gateway).

&n= bsp;

[Jon1] = The last para of “10. Security Considerations” states

   DOTS servers MUST verify that requesting= DOTS clients are entitled to

   trigger actions on a given IP prefix.&nb= sp; That is, only actions on IP

   resources that belong to the DOTS client= ' domain MUST be authorized

   by a DOTS server.  The exact mechan= ism for the DOTS servers to

   validate that the target prefixes are wi= thin the scope of the DOTS

 &= nbsp; client's domain is deployment-specific.

 

[Jon1] = So it makes no difference if the DOTS client happens to be an agent part of= a client-domain DOTS gateway.  If the client-domain DOTS gateway is h= iding all the ‘behind’ clients and presenting as single client, there is no issue.  However, if the ‘behind&#= 8217; clients are presented as 2 or more ‘cuid’s by the DOTS ga= teway, then either the scope is per ‘cuid’, or if ‘cdid&#= 8217;s are being applied by the upstream server domain DOTS gateway then on= a per ‘cdid’ basis if wanted.

&n= bsp;

For a c= lient behind a client domain DOTS gateway, there may be non public IP addre= sses that the (DMS) client is responsible for, but these should never be se= nt out through the DOTS gateway (and should be rejected by the DOTS server as out of scope).  There does have to = be a common agreement between DOTS client & DOTS server as to what Netw= orks are in scope, but the DOTS client currently cannot request this from t= he DOTS server and has to be agreed out of band.

 

[TR] I don’t see a new pr= oblem, even when a DOTS client sends a mitigation request it needs to know = if the targets conveyed in the mitigation request are in its scope or not.<= o:p>

&n= bsp;

[Jon1] = but again, the DOTS server MUST verify the IP prefix is valid, so has to kn= ow scope.  I agree that the DOTS client (or client domain DOTS gateway= ) needs to know (today out of band) what is the scope of what is valid to request.  The challenge comes when the = DOTS server’s scope is reconfigured, but not yet updated on the DOTS = client. 

 

[TR2] The scope would be first = updated on the DOTS client domain and then on the DOTS server (e.g. IP pref= ix re-numbering).

&n= bsp;

[Jon2] = I was more thinking of a DOTS client that got missed off a list when the DO= TS server was updated.  Normally though, they should be kept in sync b= ut which one gets updated first is uncertain to me.

 

[TR3] If the DOTS client missed= update, it will have various other problems; any network policy based on d= estination network IP/prefix will fail. DOTS client should support mechanis= ms to receive the latest network configuration after missing critical updates because it was offline or its

     &= nbsp;    connectivity was lost.

&n= bsp;

[Jon3] = So to me, we need to add in something to the data channel protocol so that = a DOTS client can request as to what is the network current scope it is all= owed to ask for ACL/Mitigation for.

 

[TR4] I don’t think so, you =
may want to look into SIG-007 requirement, it says “A DOTS cli=
ent may obtain the mitigation scope through direct provisioning or through =
implementation-specific methods of discovery.”
 
[Jon4] That does not preclude us adding it into the DOT=
S data protocol YANG model.
 
[TR5] No, it clearly says configurating the mitigation scope on the D=
OTS client is outside the scope of DOTS protocols.

 

There i= s no reason as to why the DOTS server cannot maintain a valid scope of Netw= orks that the client domain DOTS gateway is allowed to request for validity= checking – unless I am missing something?

 

[TR] You are partially right, t= he DOTS server does not know the valid scope of prefixes that a DOTS client= behind client-domain DOTS gateway is allowed to request.=

&n= bsp;

[Jon1] = Again, the last para of 10. stands here, and so the scope has to be known b= y the DOTS server.

 

[TR] Yes, but it may not know t= he scope of a DOTS client behind a client-domain DOTS gateway.

&n= bsp;

[Jon2] = But it will know what the client-domain DOTS gateway is allowed to pass thr= ough in terms of Destination Network.  The client-domain DOTS gateway = will separately need to know what Destination networks are allowed to get out through the gateway.

&n= bsp;

Trouble= shooting has kept me in a job for more years than I care to remember, anyth= ing to aid troubleshooting is what I am interested in and so totally agree = that rogue DOTS client’s capabilities need to be kept under control with suitable logging to aid diagnosis is a = major plus.  However in this case, the implicit rule is no different t= o the DOTS client requesting the full Networks scope in an ACL request.

 

[TR] If the client is not autho= rized to request the full network scope, it can detected by the client-doma= in DOTS gateway and rejects the filtering rule by comparing the destination= -networks

     &= nbsp;  specified in the ACE.

[Jon1] = Agreed, it is the responsibility of the client domain DOTS gateway to only = allow out valid networks that are valid within the DOTS server’s scop= e.

&n= bsp;

[Jon1] = Should we support a way for the client domain DOTS gateway  (i.e. DOTS= client agent) to programmatically get the current valid network scope from= the DOTS server?

 

[TR2] It will not solve the abo= ve problem of detecting and rejecting a rouge (or misconfigured) DOTS clien= t behind client domain DOTS gateway sending ACL without specifying destinat= ion-network.

&n= bsp;

[Jon2] = Hmm.  If the client-domain DOTS gateway is restricted in scope as to w= hat it is allowed to request, and a rogue client behind the gateway does no= t specify a destination-network, then when the request passes through the gateway the upstream DOTS server will only = use the scope allowed for that specific client-domain DOTS gateway.  A= gain, it is exactly the same as if the rogue client was to specify the full= set of allowed scope as a set of destination networks in terms of damage capabilities.

 

[TR3] No, the client-domain DOT= S gateway can detect and reject the ACL because the rouge DOTS client has s= pecified destination-network not under its scope.

&n= bsp;

[Jon3] = You are missing my point.  Agreed that the client-domain DOTS gateway = must sanity check what is passed through.  However, there will be a se= t of Networks that are allowed through the DOTS gateway which are within the defined scope of what the DOTS server allows.=   This “allowed through networks” can legitimately be set = by the DOTS client in destination-network, or the DOTS server can fill in t= he same set of networks in the ACL instantiation if destination-networks was empty and the potential side effects damage ca= used will be the same.

 

[TR4] I understand, you seem to be focusing on only DDoS detectors an= d IDMS acting as DOTS clients . They will be authorized to enforce ACL for = the entire DOTS client domain, but an application server acting as a DOTS client will only be authorized to enfo= rce ACL for the IP addresses/prefixes used by the it and not for the entire= DOTS client domain. These type of DOTS clients must fill the destination-n= etwork, so the client-domain DOTS gateway can detect and reject ACL requests populated with destination IP a= ddresses/prefixes the application server does not use.

&n= bsp;

[Jon4]&= nbsp; I agree that the client-domain DOTS gateway has to have a notion of w= hich client can request what – i.e. maintaining a scope of what the i= ndividual client can ask for.  Not convinced that we clearly define that a client-domain DOTS gateway must maintain a Destin= ation scope though.  There is no reason as to why a client-domain DOTS= gateway cannot fill in an empty destination-network with the specifics for= the requesting client though before passing it through upstream – but it does look tidier if the client = does specify the destination-network.

 

[TR5] It significantly increase= s the work on the client-domain gateways, it will have to modify the respon= se (to remove the destination-network from the ACE) when the client is usin= g GET to retrieve the installed filtering rules and will  have to remember if the destination-network was updat= ed by it or not. The client anyway knows its mitigation scope, and cannot n= ot a mitigation request without specifying the mitigation scope (similar to= destination-networks specified in ACE).

 

-Tiru

 

~jon2

 

-Tiru

 

~jon1

 

-Tiru

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Kon= da@mcafee.com]
Sent: 07 April 2018 06:48
To: Jon Shallow; moh= amed.boucadair@orange.com; dots@ietf.org
Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Hi Jon,

&nbs= p;

DOTS clie= nts (intelligent DDoS mitigation system, application server) will know the = destination networks, what kind of DOTS clients will not know the destinati= on networks they are allowed to use ?

DOTS clie= nts could be behind client-domain DOTS gateway, DOTS server will have no wa= y to validate the DOTS client identity sending the ACE request to determine= the destination IP addresses in its scope, it will only know the destination IP addresses in the DOTS client d= omain scope.

Further, = the implicit rule can be misused by compromised DOTS clients (e.g. black-li= st good traffic to the entire DOTS client domain) and it’s a  tr= oubleshooting nightmare to find the culprit device adversely impacting the entire network.

&nbs= p;

Cheers,

-Tiru

&nbs= p;

From:<= /span> Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Friday, April 6, 2018 9:14 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; mohamed.boucadair@orange.co= m; dots@ietf.org
Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Hi Tiru= ,

&n= bsp;

The DOT= S server is likely to have a scope of IP addresses that are valid for the c= lient to ask for protection for based on the cuid or cdid.

&n= bsp;

The DOT= S client may have some knowledge of the scope IPs by some out of band metho= d, but programmatically cannot ask the server what they are.

&n= bsp;

If a cl= ient specifies a destination network that is out of the valid scope of IP a= ddresses, then the ACE request will get rejected.  The client may then= have a challenge to work out what destination networks it is allowed to use.

&n= bsp;

How doe= s a client set up a blacklist for all the IPS within his allowed scope if i= t does not know what the scope is?

&n= bsp;

If the = client has not provided a destination network, then the DOTS server can aut= o-fill in the missing information at the time of the ACE instantiation R= 11; and this then handles if the scope of IP addresses change.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 06 April 2018 16:19
To: Jon Shallow; moh= amed.boucadair@orange.com; dots@ietf.org
Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

I donR= 17;t understand how the DOTS server/mitigation will fill it in at time of A= CE instantiation, and why can’t the DOTS client fill the destination = network details ?

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Friday, April 6, 2018 6:58 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; mohamed.boucadair@orange.co= m; dots@ietf.org
Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Hi ther= e,

&n= bsp;

There i= s no current way to request of a DOTS Server as to what is the set of IP ne= tworks that a DOTS client can use either within a mitigation request or to = set up an ACL other than by “testing for ok or not ok” with lots of different IP addresses.=

&n= bsp;

There i= s a reasonable likelihood of the scope of valid IPs from the Server’s= perspective will change over time.  So, unless a DOTS client wants to= control a specific destination network, then my suggestion would be to leave the ACE destination network empty and for the= DOTS Server / DOTS mitigator (how is out of scope) to fill it in at time o= f ACE instantiation.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 27 March 2018 13:49
To: Jon Shallow; moh= amed.boucadair@orange.com; dots@ietf.org
Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Please se= e inline [TR]

&nbs= p;

From:<= /span> Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Tuesday, March 27, 2018 4:07 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; mohamed.boucadair@orange.co= m; dots@ietf.org
Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Hi Tiru= / Med

&n= bsp;

See inl= ine [Jon]

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 27 March 2018 09:47
To: mohamed.boucadai= r@orange.com; Jon Shallow; dots@ietf.org
Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

I also su= pport to mandate destination-network for immediately enforced filtering rul= es.

[Jon] This can be enforced / inserted by the DOTS Server for all the d= estination networks of the domain that the DOTS client ‘belongs’= ; to.  That said, it would be good to always have the destination network in an ACL as it can be validated and cross-checked= whenever the legitimate set of domain protected IPs are updated.

[Jon] However, what happens to the Destination network in the case of = a call home DOTS client that becomes a quasi DOTS server and the Destinatio= n networks are somewhere out on the Internet?

&nbs= p;

[TR] DDOS= is a targeted attack, so the DOTS client can specify the destination netwo= rk targeted by devices in the DOTS server domain and the DOTS server can va= lidate if the destination network is indeed targeted by its devices.

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed= .......boucadair@orange.com
Sent: Tuesday, March 27, 2018 1:09 PM
To: Jon Shallow <sup= jps-ietf@jpshallow.com>; dots@ietf.org
Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Hi Jon,

 

Thank you for the comments.<= /p>

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow
Envoy=E9 : lundi 26 mars 2018 14:23
=C0 : dots@ietf.org
Objet : [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Hi there,

 

As per Med’s presentation= to the IETF 101

 

Issue #4: Per-Domain or Per-cli= ent Filters?

 

• Conclusion

– Filters that are activa= ted only during mitigation time are on a per-client basis=

   • Filters ar= e per-domain when are immediately applied

 

“Filters are per-domain w= hen are immediately applied” is what I have an challenge with.

 

If we have a compromised or rog= ue DOTS client, the simple use of something like curl, along with the clien= t certificates etc. can be used to generate any ACL with activation-type := =3D ‘immediate’ which is then immediately applied for all traffic within the domain as per the above.

 

[Med] Yes. FWIW, this attack is= called out in the security considerations section:

 

“Nevertheless,=
 an

   attacker who can acce= ss a DOTS client is technically capable of

   launching various att= acks, such as:

 

..;

 

   o  Set invalid ACL entries, which may prevent legiti=
mate traffic from
      being forwarded.  Likewise, invali=
d ACL entries may lead to
      forward DDoS traffic.=

“

[Jon] A= greed that the attack is covered off in the Security section, but we should= be limiting the possibility / scope of the attack vector by enforcing some= rules as to what is / is not allowed.  Allowing a DOTS client to be able to affect all the traffic within the dom= ain is a huge risk to me and should not be allowed.

 

So, a ACL that blacklists the D= NS server, or drops all port 443 traffic etc. can easily cause all of the o= ther clients / devices within the domain to be taken off air.  Putting= the intelligence into the DOTS server to not allow this to happen could be a challenge.

[The signal channel is much har= der to compromise and affect traffic flows to other areas within the domain= ]

 

I believe that an ACL instantia= ted by a DOTS client (immediate or when-mitigating) should only apply to th= e DOTS client’s traffic which means that the destination-network has = to be a part of the ACL, whether implicitly added by the DOTS server, or by the DOTS client and suitably validated.

 

[Med] Putting aside that I don&= #8217;t parse “DOTS client’s traffic”,

[Jon] I= was referring to all the traffic flows that a DOTS client can legitimately= request control of to the DOTS server that are within the scope of what th= e DOTS client is protecting (which may or may not be the DOTS client’s IP address).

I interpret your answer as a su= pport to this question raised for issue #4:

    • “Should we mandate destination-network to be present for immediately enforced filters?”

[Jon] S= ee response to Tiru’s Agreement above.

~Jon

There is nothing to stop the DO= TS server or DOTS mitigator merging common ACLs to reduce the number of ACL= s within the mitigation device.

 

As a side note “mitigatio= n-time” is perhaps a bad name as it implies a time period – som= ething like “when-mitigating” to me is clearer.

[Med] Fixed in my local copy. T= hank you.

 

Regards

 

Jon

--_000_DM5PR16MB14364E0122B6191B598F9DE1EABE0DM5PR16MB1436namp_-- From nobody Tue Apr 10 05:21:52 2018 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 81E44127201 for ; Tue, 10 Apr 2018 05:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 K4OPJUvkKPx3 for ; Tue, 10 Apr 2018 05:21:47 -0700 (PDT) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80EB11241F5 for ; Tue, 10 Apr 2018 05:21:47 -0700 (PDT) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id CDDD1409C3; Tue, 10 Apr 2018 14:21:45 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.62]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id AEEF41A007E; Tue, 10 Apr 2018 14:21:45 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5E.corporate.adroot.infra.ftgroup ([fe80::2912:bfa5:91d3:bf63%18]) with mapi id 14.03.0382.000; Tue, 10 Apr 2018 14:21:45 +0200 From: To: "Konda, Tirumaleswar Reddy" , "kaname nishizuka" , "dots@ietf.org" Thread-Topic: [Dots] WGLC on DOTS Signal Channel Thread-Index: AdPA/2I8r8JGmyBkSmyI9HwbArIJBwKrEr+AAAxpFAAAATBugAABO8EAAAGuM4AAAmXtgABcmkKAAAOWXAAAK9pXgACngmdQ Date: Tue, 10 Apr 2018 12:21:45 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DEFB59A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <359EC4B99E040048A7131E0F4E113AFC014C36B932@marathon> <68904f77-3cef-4c77-4cfa-3aeaacf95133@nttv6.jp> <787AE7BB302AE849A7480A190F8B93302DEF7927@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7277ba5c-436b-9027-8be0-49c8a53dbde2@nttv6.jp> <787AE7BB302AE849A7480A190F8B93302DEF79C9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEF7B45@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <69de4e41-1761-d02a-616d-85bc340601b4@nttv6.jp> <787AE7BB302AE849A7480A190F8B93302DEF91CB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] WGLC on DOTS Signal Channel 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, 10 Apr 2018 12:21:50 -0000 UmUtLA0KDQpUbyBjb25jbHVkZSB0aGlzIG9uZSwgSSBjb25maXJtIHRoYXQgSSBhZGRlZCB0aGlz IE5FVyB0ZXh0OiANCg0KICAgIEEgRE9UUyBjbGllbnQgbWF5IGlzc3VlIGEgR0VUIG1lc3NhZ2Ug d2l0aCAnc2lkJyBwYXJhbWV0ZXIgdG8gcmV0cmlldmUgdGhlDQogICAgY29uZmlndXJhdGlvbiBw YXJhbWV0ZXJzLiBUaGUgcmVzcG9uc2UgZG9lcyBub3QgbmVlZCB0byBpbmNsdWRlICdzaWQnIGlu IGl0cyANCiAgICBtZXNzYWdlIGJvZHkuIA0KDQpDaGVlcnMsDQpNZWQNCg0KPiAtLS0tLU1lc3Nh Z2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDogS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSBbbWFp bHRvOlRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb21dDQo+IEVudm95w6nCoDogc2Ft ZWRpIDcgYXZyaWwgMjAxOCAwNjo1OA0KPiDDgMKgOiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xO OyBrYW5hbWUgbmlzaGl6dWthOyBkb3RzQGlldGYub3JnDQo+IE9iamV0wqA6IFJFOiBbRG90c10g V0dMQyBvbiBET1RTIFNpZ25hbCBDaGFubmVsDQo+IA0KPiBQbGVhc2Ugc2VlIGlubGluZQ0KPiAN Cj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IERvdHMgW21haWx0bzpk b3RzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiA+IG1vaGFtZWQuYm91Y2FkYWly QG9yYW5nZS5jb20NCj4gPiBTZW50OiBGcmlkYXksIEFwcmlsIDYsIDIwMTggMTI6NTMgUE0NCj4g PiBUbzoga2FuYW1lIG5pc2hpenVrYSA8a2FuYW1lQG50dHY2LmpwPjsgZG90c0BpZXRmLm9yZw0K PiA+IFN1YmplY3Q6IFJlOiBbRG90c10gV0dMQyBvbiBET1RTIFNpZ25hbCBDaGFubmVsDQo+ID4N Cj4gPiBIaSBLYW5hbWUsDQo+ID4NCj4gPiBQbGVhc2Ugc2VlIGlubGluZS4NCj4gPg0KPiA+IENo ZWVycywNCj4gPiBNZWQNCj4gPg0KPiA+ID4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ ID4gPiBEZcKgOiBrYW5hbWUgbmlzaGl6dWthIFttYWlsdG86a2FuYW1lQG50dHY2LmpwXSBFbnZv ecOpwqA6IHZlbmRyZWRpIDYNCj4gPiA+IGF2cmlsIDIwMTggMDc6NDAgw4DCoDogQk9VQ0FEQUlS IE1vaGFtZWQgSU1UL09MTjsgZG90c0BpZXRmLm9yZyBPYmpldMKgOg0KPiA+ID4gUmU6IFtEb3Rz XSBXR0xDIG9uIERPVFMgU2lnbmFsIENoYW5uZWwNCj4gPiA+DQo+ID4gPiBIaSBNZWQsDQo+ID4g Pg0KPiA+ID4gUGxlYXNlIHNlZSBpbmxpbmUuDQo+ID4gPg0KPiA+ID4gdGhhbmtzLA0KPiA+ID4g S2FuYW1lDQo+ID4gPg0KPiA+ID4gT24gMjAxOC8wNC8wNCAxODoyOCwgbW9oYW1lZC5ib3VjYWRh aXJAb3JhbmdlLmNvbSB3cm90ZToNCj4gPiA+ID4gUmUtLA0KPiA+ID4gPg0KPiA+ID4gPiBUaGFu ayB5b3UgZm9yICB0aGUgY29tbWVudHMuDQo+ID4gPiA+DQo+ID4gPiA+IFBsZWFzZSBzZWUgaW5s aW5lLg0KPiA+ID4gPg0KPiA+ID4gPiBDaGVlcnMsDQo+ID4gPiA+IE1lZA0KPiA+ID4gPg0KPiA+ ID4gPj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ID4gPiA+PiBEZcKgOiBrYW5hbWUg bmlzaGl6dWthIFttYWlsdG86a2FuYW1lQG50dHY2LmpwXSBFbnZvecOpwqA6IG1lcmNyZWRpIDQN Cj4gPiA+ID4+IGF2cmlsIDIwMTggMTA6MjAgw4DCoDogQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09M TjsgZG90c0BpZXRmLm9yZyBPYmpldA0KPiA+ID4gPj4gOiBSZTogW0RvdHNdIFdHTEMgb24gRE9U UyBTaWduYWwgQ2hhbm5lbA0KPiA+ID4gPj4NCj4gPiA+ID4+IEhpIE1lZCwNCj4gPiA+ID4+DQo+ ID4gPiA+PiBUaGFuayB5b3UgZm9yIHRoZSBjbGFyaWZpY2F0aW9uIGFuZCB0aGUgcHJvcGVyIHJl ZmVyZW5jZS4NCj4gPiA+ID4+IEkgY2FuIG5vdCBhc3N1bWUgdGhhdCBteSBET1RTIGNsaWVudCB3 aWxsIGRvIE91dC1vZi1PcmRlcg0KPiA+ID4gPj4gQ29uZmlndXJhdGlvbiBSZXF1ZXN0cywgYnV0 Li4uIEkgZ290IHVuZGVyc3RhbmQgdGhhdCAnc2lkJyBpcyB0aGUNCj4gPiA+ID4+IHNvbHV0aW9u IHRvIG91dCBvZg0KPiA+ID4gb3JkZXINCj4gPiA+ID4+IGNvbmZpZ3VyYXRpb24gcmVxdWVzdHMu DQo+ID4gPiA+Pg0KPiA+ID4gPj4gMiBtb3JlIHF1ZXN0aW9uczoNCj4gPiA+ID4+DQo+ID4gPiA+ PiAxLiBHRVQgd2l0aCBzaWQNCj4gPiA+ID4+IE9uIHRoZSBzbGlkZSAxMiwgaXQgaXMgd3JpdHRl biBpbiB0aGUgdGFibGUgdGhhdCAnc2lkJyBVUkkNCj4gPiA+ID4+IFBhcmFtZXRlciBNVVNUDQo+ ID4gPiBOT1QNCj4gPiA+ID4+IGV4aXN0IGluIEdFVC4NCj4gPiA+ID4gW01lZF0gQWN0dWFsbHks IHRoZSBHRVQgaW4gdGhhdCBzbGlkZSByZWZlcnMgdG8gdGhlIGNhc2UgdG8gZGlzY292ZXINCj4g PiA+IGNvbmZpZ3VyYXRpb24gcGFyYW1ldGVycyB3aGVuLCBmb3IgZXhhbXBsZSwgYSBjbGllbnQg Ym9vdHN0cmFwcy4gSW4NCj4gPiA+IHN1Y2ggY2FzZSwgdGhlcmUgaXMgbm8gJ3NpZCcgdG8gcGxh eSB3aXRoLg0KPiA+ID4gPg0KPiA+ID4gPj4gSG93ZXZlciwgSW4gUkZDNzI1MjoNCj4gPiA+ID4+ IDUuOC4xLiBHRVQNCj4gPiA+ID4+ICAgwqBUaGUgR0VUIG1ldGhvZCByZXRyaWV2ZXMgYSByZXBy ZXNlbnRhdGlvbiBmb3IgdGhlIGluZm9ybWF0aW9uIHRoYXQNCj4gPiA+ID4+ICAgwqBjdXJyZW50 bHkgY29ycmVzcG9uZHMgdG8gdGhlIHJlc291cmNlIGlkZW50aWZpZWQgYnkgdGhlIHJlcXVlc3QN Cj4gVVJJLg0KPiA+ID4gPj4NCj4gPiA+ID4+IFNvLCBJIHRoaW5rIHRoZSByZXNvdXJjZSBtYWRl IGJ5IFBVVCBpbiB0aGUgZXhhY3QgVVJJIHBhdGggbWF5IGJlDQo+ID4gPiByZXRyaWV2ZWQNCj4g PiA+ID4+IGJ5IEdFVC4NCj4gPiA+ID4gW01lZF0gQWdyZWUuIFRoZSBzaWduYWwgY2hhbm5lbCBz cGVjaWZpY2F0aW9uIGRvZXMgbm90IGNoYW5nZSB0aGUNCj4gPiA+ID4gUkZDNzI1Mg0KPiA+ID4g YmVoYXZpb3IuDQo+ID4gPiA+DQo+ID4gPiA+PiBJIGFuZCBKb24gZ290IGNvbnNlbnN1cyB0aGF0 IHRoZSBleHBlY3RlZCByZXNwb25zZSBvZiBHRVQgd2l0aCBzaWQNCj4gPiA+ID4+IGlzIGEgIkZp Z3VyZSAxODogR0VUIENvbmZpZ3VyYXRpb24gUmVzcG9uc2UgQm9keSIgbGlrZSByZXNwb25zZQ0K PiA+ID4gPj4gd2l0aCBjdXJyZW50DQo+ID4gPiB2YWx1ZQ0KPiA+ID4gPj4gb2YgdGhhdCBzaWQg YXQgdGhlIGludGVyb3AgdGVzdGluZy4NCj4gPiA+ID4+IFRoZSBjdXJyZW50IGRyYWZ0IGlzIG5v dCBjbGVhciBhYm91dCB0aGlzIGJlaGF2aW9yLg0KPiA+ID4gPiBbTWVkXSBBcyBJIG1lbnRpb25l ZCBhYm92ZSwgd2UgYXJlIG5vdCBjaGFuZ2luZyB0aGUgNzI1MiBiZWhhdmlvci4gSQ0KPiA+ID4g PiBjYW4NCj4gPiA+IGFkZCB0aGlzIE5FVyB0ZXh0IGlmIGl0IGhlbHBzOg0KPiA+ID4gPg0KPiA+ ID4gPiAgICAgQSBET1RTIGNsaWVudCBtYXkgaXNzdWUgYSBHRVQgbWVzc2FnZSB3aXRoIG9yIHdp dGhvdXQgJ3NpZCcNCj4gcGFyYW1ldGVyDQo+ID4gPiA+ICAgICB0byByZXRyaWV2ZSB0aGUgY29u ZmlndXJhdGlvbiBwYXJhbWV0ZXJzLiAgVGhlIHJlc3BvbnNlIG1lc3NhZ2UNCj4gYm9keQ0KPiA+ ID4gPiAgICAgaXMgdGhlIHNhbWUgYXMgdGhlIG9uZSBkZXBpY3RlZCBpbiBGaWd1cmUgMTguDQo+ ID4gPiA+DQo+ID4gPiBba2FuYW1lXQ0KPiA+ID4gUmVmZXJyaW5nIHRvIEZpZ3VyZSAxOCB3YXMg bm90IHByZWNpc2UsIHNvcnJ5Lg0KPiA+ID4gVGhlIEdFVCB3aXRoIHNpZCB3aWxsIGluY2x1ZGUg c2lkIGluIHJlc3BvbnNlIGJvZHkgYWNjb3JkaW5nIHRvIFlBTkcNCj4gPiA+IG1vZHVsZSg1LjEs IDUuMikNCj4gPiA+DQo+ID4gPiBTbywgdGhpcyB3b3VsZCBiZSBtb3JlIHByZWNpc2UuDQo+ID4g Pg0KPiA+ID4gICAgIEEgRE9UUyBjbGllbnQgbWF5IGlzc3VlIGEgR0VUIG1lc3NhZ2Ugd2l0aCBv ciB3aXRob3V0ICdzaWQnIHBhcmFtZXRlcg0KPiA+ID4gICAgIHRvIHJldHJpZXZlIHRoZSBjb25m aWd1cmF0aW9uIHBhcmFtZXRlcnMuICBUaGUgcmVzcG9uc2UgbWVzc2FnZSBib2R5DQo+ID4gPiAg ICAgZm9sbG93cyB0aGUgWUFORyBtb2R1bGUgImlldGYtZG90cy1zaWduYWwtY2hhbm5lbCIgKFNl Y3Rpb24gNS4yKS4NCj4gPiA+DQo+ID4NCj4gPiBbTWVkXSBJIHN1Z2dlc3QgdG8gZGVsZXRlICJv ciB3aXRob3V0IiBiZWNhdXNlIHRoaXMgaXMgYWxyZWFkeSBkaXNjdXNzZWQgaW4NCj4gNC41LjEu DQo+ID4NCj4gPiAiQSBET1RTIGNsaWVudCBtYXkgaXNzdWUgYSBHRVQgbWVzc2FnZSB3aXRoICdz aWQnIHBhcmFtZXRlciB0byByZXRyaWV2ZSB0aGUNCj4gPiBjb25maWd1cmF0aW9uIHBhcmFtZXRl cnMuIg0KPiA+DQo+ID4gSWYgd2UgYXJlIHNpbGVudCBhYm91dCB0aGUgcmVzcG9uc2UsIHRoaXMg bWVhbnMgdGhhdCB0aGUgY2xpZW50IHNob3VsZA0KPiBhY2NlcHQNCj4gPiBib3RoIHJlc3BvbnNl cyB3aXRoIG9yIHdpdGhvdXQgJ3NpZCcgaW4gdGhlIGJvZHkuDQo+ID4NCj4gPiBEbyB5b3Ugd2Fu dCB0aGUgdGV4dCB0byBiZSBtb3JlIHNwZWNpZmljLCBlLmcuOg0KPiA+ICgxKSBhbHdheXMgcmV0 dXJuIHNpZCBpbiB0aGUgcmVzcG9uc2U/IElmIHNvLCBkb2VzIHRoZSBjbGllbnQgdXNlcyB0aGF0 DQo+IGluZm9ybWF0aW9uDQo+ID4gZm9yIHNvbWUgcHJvY2Vzc2luZz8NCj4gPiAoMikgZm9yYmlk IHRvIHJldHVybiB0aGUgc2lkPyBUaGUgY2xpZW50IHdpbGwgYXNzdW1lIHRoYXQgdGhlIHJlc3Bv bnNlDQo+IG1hdGNoZXMgdGhlDQo+ID4gc2lkIGluY2x1ZGVkIGluIHRoZSByZXF1ZXN0Lg0KPiA+ ICgzKSBhbGxvdyBmb3IgYm90aCBjYXNlcy4NCj4gDQo+IENvbmZpZ3VyYXRpb24gcmVxdWVzdC9y ZXNwb25zZSBhcmUgY29uZmlybWFibGUgbWVzc2FnZXMsIERPVFMgY2xpZW50IHdpbGwNCj4ga25v dyBpZiBpdHMgcmVxdWVzdCBpcyBhY2NlcHRlZCBieSB0aGUgc2VydmVyIG9yIG5vdCwgZG9uJ3Qg c2VlIHRoZSBuZWVkIHRvDQo+IHJldHVybiAic2lkIiBpbiB0aGUgcmVzcG9uc2UuDQo+IEhvd2V2 ZXIsICJzaWQiIGlzIHVzZWZ1bCBpbiB0aGUgcmVxdWVzdCwgdGhvdWdoIHRoZSBjbGllbnQgc2Vu ZHMNCj4gY29uZmlndXJhdGlvbiByZXF1ZXN0IGluIG9yZGVyLCB0aGV5IG1heSBhcnJpdmUNCj4g YXQgdGhlIERPVFMgc2VydmVyIG91dC1vZi1vcmRlciAocmVxdWVzdHMgbWF5IHRha2UgZGlmZmVy ZW50IG5ldHdvcmsgcGF0aHMpLg0KPiANCj4gQ2hlZXJzDQo+IC1UaXJ1DQo+IA0KPiA+DQo+ID4g Pg0KPiA+ID4gPj4gMi4gaG93IHRvIGdldCBkZWZhdWx0IHZhbHVlcyBhZnRlciBzZXZlcmFsIG5l Z290aWF0aW9ucyBHRVQgd2l0aG91dA0KPiA+ID4gPj4gc2lkIHJldHVybnMgdGhlIGN1cnJlbnQg dmFsdWVzLg0KPiA+ID4gPj4gVGhlIGRlZmF1bHQgdmFsdWVzIGNhbiBiZSByZXRyaWV2ZWQgb25s eSBqdXN0IGFmdGVyIGJvb3RzcmFwcGluZyBvcg0KPiA+ID4gc2VuZGluZw0KPiA+ID4gPj4gREVM RVRFIHJlcXVlc3QuDQo+ID4gPiA+PiAoYSBET1RTIGNsaWVudCBNQVkgc2VuZCBhIERFTEVURSBy ZXF1ZXN0IHRvIHNldCB0aGUgY29uZmlndXJhdGlvbg0KPiA+ID4gcGFyYW1ldGVycw0KPiA+ID4g Pj4gdG8gZGVmYXVsdCB2YWx1ZXMuKQ0KPiA+ID4gPj4gSSdkIGxpa2UgdG8gZ2V0IHRoZSBkZWZh dWx0IHZhbHVlcyBldmVuIGFmdGVyIG5lZ290aWF0aW9ucy4gSXMNCj4gPiA+ID4+IHRoZXJlIGFu eQ0KPiA+ID4gd2F5DQo+ID4gPiA+PiB0byBnZXQgdGhlbT8NCj4gPiA+ID4gW01lZF0gRGVmYXVs dCB2YWx1ZXMgYXJlIGtub3duIHRvIERPVFMgYWdlbnRzIGJ5IGRlc2lnbi4gVGhhdCBpcyBhDQo+ ID4gPiA+IERPVFMNCj4gPiA+IGFnZW50IGFzc3VtZXMgdGhlIGZvbGxvd2luZyBkZWZhdWx0IHZh bHVlczoNCj4gPiA+ID4NCj4gPiA+ID4gVGhlIFJFQ09NTUVOREVEIHZhbHVlcyBvZiB0cmFuc21p c3Npb24gcGFyYW1ldGVyDQo+ID4gPiA+ICAgICB2YWx1ZXMgYXJlIGFjay10aW1lb3V0ICgyIHNl Y29uZHMpLCBtYXgtcmV0cmFuc21pdCAoMyksIGFjay1yYW5kb20tDQo+ID4gPiA+ICAgICBmYWN0 b3IgKDEuNSkuICBJbiBhZGRpdGlvbiB0byB0aG9zZSBwYXJhbWV0ZXJzLCB0aGUgUkVDT01NRU5E RUQNCj4gPiA+ID4gICAgIHNwZWNpZmljIERPVFMgdHJhbnNtaXNzaW9uIHBhcmFtZXRlciB2YWx1 ZXMgYXJlICdoZWFydGJlYXQtDQo+IGludGVydmFsJw0KPiA+ID4gPiAgICAgKDMwIHNlY29uZHMp IGFuZCAnbWlzc2luZy1oYi1hbGxvd2VkJyAoNSkuDQo+ID4gPg0KPiA+ID4gW0thbmFtZV0NCj4g PiA+IEkgdGhvdWdodCBlYWNoIERPVFMgc2VydmVyIGNvdWxkIGhhdmUgaXRzIG93biBkZWZhdWx0 IHZhbHVlcyBiZWNhdXNlDQo+ID4gPiB0aGUgZGVmYXVsdCB2YWx1ZXMgYnkgZGVzaWduIGlzIGp1 c3QgYSByZWNvbW1lbmRhdGlvbi4NCj4gPiA+DQo+ID4NCj4gPiBbTWVkXSBPbmUgd2F5IHRvIGRp c2NvdmVyIHdoZXRoZXIgYSBzZXZlciB1c2VzIG5vbi1yZWNvbW1lbmRlZCB2YWx1ZXMgYXMNCj4g PiBkZWZhdWx0IGlzIHRvIGlzc3VlIGEgR0VUIGF0IGJvb3RzdHJhcCBvciBhZnRlciBhIERFTFRF VEUuDQo+ID4NCj4gPiA+ID4gV2hlbiBET1RTIGFnZW50cyBuZWdvdGlhdGUgYSBnaXZlbiBwYXJh bWV0ZXIsIHRoZSBuZWdvdGlhdGVkIHZhbHVlDQo+ID4gPiA+IGlzIHVzZWQNCj4gPiA+IHRvIG92 ZXJyaWRlIHRoZSBkZWZhdWx0IG9uZS4gT3RoZXJ3aXNlLCB0aGUgZGVmYXVsdCB2YWx1ZSBpcyB1 c2VkLg0KPiA+ID4gPg0KPiA+ID4gPiBBIERPVFMgY2xpZW50IG1haW50YWlucyBhIHN0YXRlIHdo ZXRoZXIgYSB2YWx1ZSB3YXMgbmVnb3RpYXRlZC4gQXMNCj4gPiA+ID4gc3VjaCwgYQ0KPiA+ID4g RE9UUyBjbGllbnQgZG9lcyBub3QgbmVlZCB0byBkaXNjb3ZlciBkZWZhdWx0IHZhbHVlcy4NCj4g PiA+IFtLYW5hbWVdDQo+ID4gPiBZZXMsIHRoYXQncyB0cnVlLg0KPiA+ID4gV2hhdCBJIHRob3Vn aHQgd2FzLCBmcm9tIG9wZXJhdGlvbmFsIHBlcnNwZWN0aXZlLCBhbiBvcGVyYXRvciBtYXkgd2Fu dA0KPiA+ID4gdG8ga25vdyB0aGUgZGVmYXVsdCB2YWx1ZXMgb2YgdGhlIERPVFMgc2VydmVyIGJl Zm9yZSBkZWxldGluZyB0aGUNCj4gPiA+IG5lZ290aWF0ZWQgdmFsdWVzLg0KPiA+ID4gQnV0LCBJ IGFncmVlIHRoYXQgaXMgb3V0IG9mIERPVFMgc3BlYy4NCj4gPiA+DQo+ID4gPiA+IERpZCBJIG1p c3NlZCBzb21ldGhpbmc/DQo+ID4gPg0KPiA+ID4NCj4gPiA+ID4+IHRoYW5rcywNCj4gPiA+ID4+ IEthbmFtZQ0KPiA+ID4gPj4NCj4gPiA+ID4+DQo+ID4gPiA+Pg0KPiA+ID4gPj4gT24gMjAxOC8w NC8wNCAxNjozMSwgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSB3cm90ZToNCj4gPiA+ID4+ PiBSZS0sDQo+ID4gPiA+Pj4NCj4gPiA+ID4+PiBQbGVhc2Ugc2VlIGlubGluZS4NCj4gPiA+ID4+ Pg0KPiA+ID4gPj4+IENoZWVycywNCj4gPiA+ID4+PiBNZWQNCj4gPiA+ID4+Pg0KPiA+ID4gPj4+ PiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gPiA+ID4+Pj4gRGXCoDoga2FuYW1lIG5p c2hpenVrYSBbbWFpbHRvOmthbmFtZUBudHR2Ni5qcF0gRW52b3nDqcKgOiBtZXJjcmVkaQ0KPiA+ ID4gPj4+PiA0IGF2cmlsIDIwMTggMDg6NTcgw4DCoDogQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09M TjsgZG90c0BpZXRmLm9yZw0KPiA+ID4gPj4+PiBPYmpldMKgOiBSZTogW0RvdHNdIFdHTEMgb24g RE9UUyBTaWduYWwgQ2hhbm5lbA0KPiA+ID4gPj4+Pg0KPiA+ID4gPj4+PiBIaSBNZWQsDQo+ID4g PiA+Pj4+DQo+ID4gPiA+Pj4+DQo+ID4gPiA+Pj4+IE9uIDIwMTgvMDQvMDQgMTU6MjIsIG1vaGFt ZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20gd3JvdGU6DQo+ID4gPiA+Pj4+PiBIaSBLYW5hbWUsDQo+ ID4gPiA+Pj4+Pg0KPiA+ID4gPj4+Pj4gUGxlYXNlIHNlZSBpbmxpbmUuDQo+ID4gPiA+Pj4+Pg0K PiA+ID4gPj4+Pj4gQ2hlZXJzLA0KPiA+ID4gPj4+Pj4gTWVkDQo+ID4gPiA+Pj4+Pg0KPiA+ID4g Pj4+Pj4+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiA+ID4gPj4+Pj4+IERlwqA6IERv dHMgW21haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUga2FuYW1lDQo+ ID4gPiBuaXNoaXp1a2ENCj4gPiA+ID4+Pj4+PiBFbnZvecOpwqA6IG1lcmNyZWRpIDQgYXZyaWwg MjAxOCAwMjoyNyDDgMKgOiBkb3RzQGlldGYub3JnIE9iamV0wqA6DQo+ID4gPiA+Pj4+Pj4gUmU6 IFtEb3RzXSBXR0xDIG9uIERPVFMgU2lnbmFsIENoYW5uZWwNCj4gPiA+ID4+Pj4+Pg0KPiA+ID4g Pj4+Pj4+IEhpLA0KPiA+ID4gPj4+Pj4+DQo+ID4gPiA+Pj4+Pj4gSSBoYXZlIG9uZSBjbGFyaWZp Y2F0aW9uIHF1ZXN0aW9ucyBhYm91dCBzaWQgaW4gc2lnbmFsIGNoYW5uZWwNCj4gPiA+ID4+Pj4+ PiBzZXNzaW9uIGNvbmZpZ3VyYXRpb24uDQo+ID4gPiA+Pj4+Pj4NCj4gPiA+ID4+Pj4+PiBUaGUg ZHJhZnQgc2F5czoNCj4gPiA+ID4+Pj4+PiAgICAgwqBBdCBsZWFzdCBvbmUgb2YgdGhlIGF0dHJp YnV0ZXMg4oCZaGVhcnRiZWF0LWludGVydmFs4oCZLA0KPiA+ID4gPj4+Pj4+IOKAmW1pc3Npbmct aGIgYWxsb3dlZOKAmSwg4oCZbWF4LXJldHJhbnNtaXTigJksIOKAmWFjay10aW1lb3V04oCZLCDi gJlhY2stDQo+IHJhbmRvbS0NCj4gPiBmYWN0b3LigJksIGFuZA0KPiA+ID4gPj4+Pj4+ICAgICDC oOKAmXRyaWdnZXItbWl0aWdhdGlvbuKAmSBNVVNUIGJlIHByZXNlbnQgaW4gdGhlIFBVVCByZXF1 ZXN0Lg0KPiA+ID4gPj4+Pj4+ICAgICDCoChzbmlwKQ0KPiA+ID4gPj4+Pj4+ICAgICDCoFRoZSBQ VVQgcmVxdWVzdCB3aXRoIGEgaGlnaGVyIG51bWVyaWMg4oCZc2lk4oCZIHZhbHVlDQo+ID4gPiA+ Pj4+Pj4gb3ZlcnJpZGVzIHRoZQ0KPiA+ID4gRE9UUw0KPiA+ID4gPj4+Pj4+ICAgICDCoHNpZ25h bCBjaGFubmVsIHNlc3Npb24gY29uZmlndXJhdGlvbiBkYXRhIGluc3RhbGxlZCBieSBhDQo+ID4g PiA+Pj4+Pj4gUFVUDQo+ID4gPiByZXF1ZXN0DQo+ID4gPiA+Pj4+Pj4gICAgIMKgd2l0aCBhIGxv d2VyIG51bWVyaWMg4oCZc2lk4oCZIHZhbHVlLg0KPiA+ID4gPj4+Pj4+DQo+ID4gPiA+Pj4+Pj4g YXNzdW1pbmcgdGhlc2UgYXJlIGRlZmF1bHQgdmFsdWVzIG9mIGEgRE9UUyBzZXJ2ZXI6DQo+ID4g PiA+Pj4+Pj4gICAgIMKgJ2hlYXJ0YmVhdC1pbnRlcnZhbCc9MzANCj4gPiA+ID4+Pj4+PiAgICAg wqDigJltYXgtcmV0cmFuc21pdOKAmT0zDQo+ID4gPiA+Pj4+Pj4NCj4gPiA+ID4+Pj4+PiBpZiB0 aGVzZSBtZXNzYWdlcyBjYW1lIHRvIHRoZSBET1RTIHNlcnZlciBjb25zZWN1dGl2ZWx5LA0KPiA+ ID4gPj4+Pj4+ICAgICDCoDEuIHNpZD0xMjMsICJoZWFydGJlYXQtaW50ZXJ2YWwiPTEwDQo+ID4g PiA+Pj4+Pj4gICAgIMKgMi4gc2lkPTQ1Niwg4oCZbWF4LXJldHJhbnNtaXTigJk9NSBpbiB0aGUg ZmluYWwgc3RhdGUsIHRoZQ0KPiA+ID4gPj4+Pj4+IGZpcnN0IGNoYW5nZSBzaG91bGQgYmUgZGlz Y2FyZGVkPzoNCj4gPiA+ID4+Pj4+PiAgICAgwqAnaGVhcnRiZWF0LWludGVydmFsJz0zMA0KPiA+ ID4gPj4+Pj4+ICAgICDCoOKAmW1heC1yZXRyYW5zbWl04oCZPTUNCj4gPiA+ID4+Pj4+PiBvciBh Y2N1bXVsYXRlZD86DQo+ID4gPiA+Pj4+Pj4gICAgIMKgJ2hlYXJ0YmVhdC1pbnRlcnZhbCc9MTAN Cj4gPiA+ID4+Pj4+PiAgICAgwqDigJltYXgtcmV0cmFuc21pdOKAmT01DQo+ID4gPiA+Pj4+Pj4N Cj4gPiA+ID4+Pj4+PiBzbywgdGhlIHF1ZXN0aW9uIGlzOiBzaG91bGQgdGhleSBiZSBvdmVycmlk ZGVuIGJ5IGRlZmF1bHQNCj4gPiA+ID4+Pj4+PiB2YWx1ZXMgZXZlbg0KPiA+ID4gaWYNCj4gPiA+ ID4+Pj4gaXQNCj4gPiA+ID4+Pj4+PiBpcyBub3Qgc3BlY2lmaWVkPw0KPiA+ID4gPj4+Pj4gW01l ZF0gVGhlIGJlaGF2aW9yIHRvIGZvbGxvdyBpcyBjb3ZlcmVkIGJ5IHRoaXMgdGV4dDoNCj4gPiA+ ID4+Pj4+DQo+ID4gPiA+Pj4+PiAgICAgICBUaGUgUFVUIHJlcXVlc3Qgd2l0aCBhIGhpZ2hlciBu dW1lcmljICdzaWQnIHZhbHVlDQo+ID4gPiA+Pj4+PiBvdmVycmlkZXMgdGhlDQo+ID4gPiBET1RT DQo+ID4gPiA+Pj4+PiAgICAgICBzaWduYWwgY2hhbm5lbCBzZXNzaW9uIGNvbmZpZ3VyYXRpb24g ZGF0YSBpbnN0YWxsZWQgYnkgYQ0KPiA+ID4gPj4+Pj4gUFVUDQo+ID4gPiByZXF1ZXN0DQo+ID4g PiA+Pj4+PiAgICAgICB3aXRoIGEgbG93ZXIgbnVtZXJpYyAnc2lkJyB2YWx1ZS4gIFRvIGF2b2lk IG1haW50YWluaW5nIGENCj4gPiA+ID4+Pj4+IGxvbmcNCj4gPiA+IGxpc3QNCj4gPiA+ID4+Pj4+ ICAgICAgIG9mICdzaWQnIHJlcXVlc3RzIGZyb20gYSBET1RTIGNsaWVudCwgdGhlIGxvd2VyIG51 bWVyaWMgJ3NpZCcNCj4gPiA+IE1VU1QNCj4gPiA+ID4+IGJlDQo+ID4gPiA+Pj4+PiAgICAgICBh dXRvbWF0aWNhbGx5IGRlbGV0ZWQgYW5kIG5vIGxvbmdlciBhdmFpbGFibGUgYXQgdGhlIERPVFMN Cj4gc2VydmVyLg0KPiA+ID4gPj4+Pj4NCj4gPiA+ID4+Pj4+IEFuZA0KPiA+ID4gPj4+Pj4NCj4g PiA+ID4+Pj4+ICAgICAgIFRoZSBET1RTIGFnZW50cyBNVVNUIHVzZSB0aGUgbmVnb3RpYXRlZA0K PiA+ID4gPj4+Pj4gICAgICAgdmFsdWVzIGZvciBtZXNzYWdlIHRyYW5zbWlzc2lvbiBwYXJhbWV0 ZXJzIGFuZCBkZWZhdWx0IHZhbHVlcw0KPiBmb3INCj4gPiA+ID4+Pj4+ICAgICAgIG5vbi1uZWdv dGlhdGVkIG1lc3NhZ2UgdHJhbnNtaXNzaW9uIHBhcmFtZXRlcnMuDQo+ID4gPiA+Pj4+IFRoYW5r cywgc28sIGluIG15IGV4YW1wbGUsIGZpbmFsIHN0YXRlIGlzDQo+ID4gPiA+Pj4+ICAgIMKgICdo ZWFydGJlYXQtaW50ZXJ2YWwnPTMwIChyZXZlcnRlZCB0byBkZWZhdWx0IHZhbHVlKQ0KPiA+ID4g Pj4+PiAgICDCoCDigJltYXgtcmV0cmFuc21pdOKAmT01DQo+ID4gPiA+Pj4+IGFuZCB0aGUgbG93 ZXIgbnVtZXJpYyAnc2lkJyBubyBsb25nZXIgZXhpc3QgaW4gdGhlIERPVFMgc2VydmVyLA0KPiBy aWdodD8NCj4gPiA+ID4+Pj4NCj4gPiA+ID4+PiBbTWVkXSBFeGFjdGx5Lg0KPiA+ID4gPj4+DQo+ ID4gPiA+Pj4+Pj4gSSB0aGluayB0aGUgZm9ybWVyIGlzIGlkZWFsIGJlaGF2aW9yLg0KPiA+ID4g Pj4+Pj4+IEhvd2V2ZXIsIGlmIHNvLCB0aGUgRE9UUyBzZXJ2ZXIgaXMgb25seSByZXF1aXJlZCB0 byBrZWVwIHRoZQ0KPiA+ID4gPj4+Pj4+IGxhdGVzdA0KPiA+ID4gPj4+PiByZXNvdXJjZQ0KPiA+ ID4gPj4+Pj4+IG9mIHRoZSBoaWdoZXN0IHNpZCwNCj4gPiA+ID4+Pj4+PiB0aGVuIHRoZXJlIHNo b3VsZCBiZSBubyBkaWZmZXJlbmNlIGJldHdlZW4gREVMRVRFIG1lc3NhZ2Ugd2l0aA0KPiA+ID4g Pj4+Pj4+IGFuZA0KPiA+ID4gPj4gd2l0aG91dA0KPiA+ID4gPj4+Pj4+IHNpZC4NCj4gPiA+ID4+ Pj4+Pg0KPiA+ID4gPj4+Pj4gW01lZF0gVG8gZGVsZXRlIGEgY29uZmlndXJhdGlvbiwgYSBjbGll bnQgbWF5IHNlbmQgYSBERUxFVEUgd2l0aA0KPiA+ID4gPj4+Pj4gYQ0KPiA+ID4gdmFsaWQNCj4g PiA+ID4+Pj4gJ3NpZCcgb3IgYSBERUxFVEUgd2l0aG91dCBzdXBwbHlpbmcgYSAnc2lkJy4NCj4g PiA+ID4+Pj4+IEJvdGggYXJlIGNvbnNpZGVyZWQgYXMgdmFsaWQgaW4gU2VjdGlvbiA0LjUuNC4N Cj4gPiA+ID4+Pj4+DQo+ID4gPiA+Pj4+IGJvdGggYXJlIE9LIGFuZCBoYXZlIHRoZSBzYW1lIGVm ZmVjdCBvbiBET1RTIHNlcnZlciwgcmlnaHQ/DQo+ID4gPiA+Pj4gW01lZF0gWWVzLg0KPiA+ID4g Pj4+DQo+ID4gPiA+Pj4+IEEgRE9UUyBzZXJ2ZXIgYWx3YXlzIGtlZXBzIHRoZSBsYXRlc3Qgc2lk IG9ubHkuDQo+ID4gPiA+Pj4gW01lZF0gTm90IHRoZSAibGF0ZXN0IiByZWNlaXZlZCBzaWQuLi5i dXQgdGhlIHJlcXVlc3Qgd2l0aCB0aGUNCj4gPiA+ID4+PiBoaWdoZXINCj4gPiA+IHNpZC4NCj4g PiA+ID4+Pg0KPiA+ID4gPj4+ICAgIEEgRE9UUyBjbGllbnQgYWx3YXlzIGF0dGVtcHQNCj4gPiA+ ID4+Pj4gdG8gdXBkYXRlIGl0Lg0KPiA+ID4gPj4+PiBTbyB0aGVyZSBpcyBubyByZWFzb24gdG8g dXNlIFBVVCwgR0VULCBERUxFVEUgd2l0aCBzaWQuDQo+ID4gPiA+Pj4+IFdoeSBzaWQgZG9lcyBl eGlzdCBpcyBjb25mdXNpbmcgbWUuDQo+ID4gPiA+Pj4gW01lZF0gJ3NpZCcgaXMgdGhlcmUgdG8g c29sdmUgb3V0IG9mIG9yZGVyIGNvbmZpZ3VyYXRpb24gcmVxdWVzdHMuDQo+ID4gPiA+Pj4gVGhl DQo+ID4gPiA+PiByYXRpb25hbGUgaXMgZXhwbGFpbmVkIGluIHNsaWRlIDEyIG9mDQo+ID4gPiA+ PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvaW50ZXJpbS0yMDE4LWRvdHMt DQo+ID4gPiAwMS9tYXRlcmlhbHMvc2xpZGVzLQ0KPiA+ID4gPj4gaW50ZXJpbS0yMDE4LWRvdHMt MDEtc2Vzc2Etc2lnbmFsLWNoYW5uZWwtMDAucGRmDQo+ID4gPiA+Pj4+IEknbSBhZnJhaWQgaXQg d2FzIGRpc2N1c3NlZCBvbiB0aGUgTUwgYnV0IEknZCBsaWtlIHRvIGtub3cgdGhlDQo+ID4gPiA+ Pj4+IHJhdGlvbmFsDQo+ID4gPiBvZg0KPiA+ID4gPj4+PiBleGlzdGVuY2Ugb2Ygc2lkLg0KPiA+ ID4gPj4+PiBgYGANCj4gPiA+ID4+Pj4gICAgwqBzaWQ6IFNlc3Npb24gSWRlbnRpZmllciBpcyBh biBpZGVudGlmaWVyIGZvciB0aGUgRE9UUyBzaWduYWwNCj4gY2hhbm5lbA0KPiA+ID4gPj4+PiAg ICDCoHNlc3Npb24gY29uZmlndXJhdGlvbiBkYXRhIHJlcHJlc2VudGVkIGFzIGFuIGludGVnZXIu IFRoaXMNCj4gPiA+ID4+Pj4gICAgwqBpZGVudGlmaWVyIE1VU1QgYmUgZ2VuZXJhdGVkIGJ5IERP VFMgY2xpZW50cy4g4oCZc2lk4oCZIHZhbHVlcyBNVVNUDQo+ID4gPiA+Pj4+ICAgIMKgaW5jcmVh c2UgbW9ub3RvbmljYWxseS4NCj4gPiA+ID4+Pj4gYGBgDQo+ID4gPiA+Pj4+IHRoaXMgaXMgbm90 IGNvbnZpbmNpbmcgYmVjYXVzZSBhbHdheXMgb25seSBvbmUgY29uZmlndXJhdGlvbiBpcw0KPiA+ ID4gcmVnaXN0ZXJlZA0KPiA+ID4gPj4gb24NCj4gPiA+ID4+Pj4gRE9UUyBzZXJ2ZXIuDQo+ID4g PiA+Pj4+IGl0IHdpbGwgY29tcGxldGVseSB3b3JrIHdpdGhvdXQgc2lkLg0KPiA+ID4gPj4+Pg0K PiA+ID4gPj4+PiB0aGFua3MsDQo+ID4gPiA+Pj4+IEthbmFtZQ0KPiA+ID4gPj4+Pg0KPiA+ID4g Pj4+Pg0KPiA+ID4gPj4+Pj4+IHJlZ2FyZHMsDQo+ID4gPiA+Pj4+Pj4gS2FuYW1lDQo+ID4gPiA+ Pj4+Pj4NCj4gPiA+ID4+Pj4+Pg0KPiA+ID4gPj4+Pj4+IE9uIDIwMTgvMDMvMjEgMTk6MzIsIFJv bWFuIERhbnlsaXcgd3JvdGU6DQo+ID4gPiA+Pj4+Pj4+IEhlbGxvIQ0KPiA+ID4gPj4+Pj4+Pg0K PiA+ID4gPj4+Pj4+PiBDb25zaXN0ZW50IHdpdGggb3VyIGRpc2N1c3Npb24gYXQgdGhlIExvbmRv biBtZWV0aW5nLCB3ZSBhcmUNCj4gPiA+ID4+Pj4+Pj4gc3RhcnRpbmcNCj4gPiA+IGENCj4gPiA+ ID4+Pj4+PiB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCAoV0dMQykgZm9yIHRoZSBET1RTIFNpZ25h bCBDaGFubmVsIGRyYWZ0Og0KPiA+ID4gPj4+Pj4+PiBET1RTIFNpZ25hbCBDaGFubmVsIFNwZWNp ZmljYXRpb24NCj4gPiA+ID4+Pj4+Pj4gZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1jaGFubmVsLTE4 DQo+ID4gPiA+Pj4+Pj4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRv dHMtc2lnbmFsLWNoYW5uZWwtMTgNCj4gPiA+ID4+Pj4+Pj4NCj4gPiA+ID4+Pj4+Pj4gUGxlYXNl IHNlbmQgY29tbWVudHMgdG8gdGhlIERPVFMgbWFpbGluZyBsaXN0IC0tIGZlZWRiYWNrIG9uDQo+ ID4gPiByZW1haW5pbmcNCj4gPiA+ID4+Pj4+PiBpc3N1ZXMgb3IgbmVlZGVkIGNoYW5nZXM7IGFz IHdlbGwgYXMgZW5kb3JzZW1lbnRzIHRoYXQgdGhpcw0KPiA+ID4gPj4+Pj4+IGRyYWZ0IGlzDQo+ ID4gPiA+Pj4+IHJlYWR5Lg0KPiA+ID4gPj4+Pj4+PiBUaGlzIFdHTEMgd2lsbCBlbmQgb24gQXBy aWwgNiwgMjAxOC4NCj4gPiA+ID4+Pj4+Pj4NCj4gPiA+ID4+Pj4+Pj4gVGhhbmtzLA0KPiA+ID4g Pj4+Pj4+PiBSb21hbg0KPiA+ID4gPj4+Pj4+Pg0KPiA+ID4gPj4+Pj4+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gPj4+Pj4+PiBEb3RzIG1h aWxpbmcgbGlzdA0KPiA+ID4gPj4+Pj4+PiBEb3RzQGlldGYub3JnDQo+ID4gPiA+Pj4+Pj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90cw0KPiA+ID4gPj4+Pj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiA+Pj4+ Pj4gRG90cyBtYWlsaW5nIGxpc3QNCj4gPiA+ID4+Pj4+PiBEb3RzQGlldGYub3JnDQo+ID4gPiA+ Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3RzDQo+ID4gPiA+ Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ ID4gPj4+Pj4gRG90cyBtYWlsaW5nIGxpc3QNCj4gPiA+ID4+Pj4+IERvdHNAaWV0Zi5vcmcNCj4g PiA+ID4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90cw0KPiA+ ID4gPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4gPiA+Pj4gRG90cyBtYWlsaW5nIGxpc3QNCj4gPiA+ID4+PiBEb3RzQGlldGYub3JnDQo+ID4g PiA+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3RzDQo+ID4gPiA+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiA+ IERvdHMgbWFpbGluZyBsaXN0DQo+ID4gPiA+IERvdHNAaWV0Zi5vcmcNCj4gPiA+ID4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3RzDQo+ID4NCj4gPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IERvdHMgbWFpbGluZyBs aXN0DQo+ID4gRG90c0BpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vZG90cw0K From nobody Tue Apr 10 05:35:33 2018 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 0D6DD12426E for ; Tue, 10 Apr 2018 05:35:32 -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 nA-8-T0oSgFk for ; Tue, 10 Apr 2018 05:35:29 -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 9EF8B1241F5 for ; Tue, 10 Apr 2018 05:35:28 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.90_1) (envelope-from ) id 1f5sUf-0004Q1-8E; Tue, 10 Apr 2018 13:35:26 +0100 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , , References: <016401d3cc1c$03321200$09963600$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7F97@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <01a701d3cc29$ba915b10$2fb41130$@jpshallow.com> <007501d3ccc2$b49f0b00$1ddd2100$@jpshallow.com> <021301d3cfe7$77e5cbe0$67b163a0$@jpshallow.com> <02b001d3d048$a2c68be0$e853a3a0$@jpshallow.com> <000001d3d0ab$547dec40$fd79c4c0$@jpshallow.com> <007701d3d0bb$2404c330$6c0e4990$@jpshallow.com> In-Reply-To: Date: Tue, 10 Apr 2018 13:35:26 +0100 Message-ID: <00a801d3d0c8$67315800$35940800$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A9_01D3D0D0.C8FB1730" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEYhrWXRSNBek+fWBybzdJS41Z0KAI4GsKdAX18SvQDE9KikwNzyn9FAeCfBHcAmG/gMgGrGCDSAZ2/A+cCF5qWXQGy5AXbAg+JyVkByAAwbQHvg6xBpKPyZhA= Content-Language: en-gb Archived-At: Subject: Re: [Dots] Data Channel ACL fragments 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, 10 Apr 2018 12:35:32 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00A9_01D3D0D0.C8FB1730 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Tiru, See inline [Jon5] Regards Jon From: Dots [mailto: -bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 10 April 2018 12:34 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] Data Channel ACL fragments Please see inline [TR3] From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Tuesday, April 10, 2018 4:30 PM To: Konda, Tirumaleswar Reddy ; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] Data Channel ACL fragments Hi Tiru, See inline [Jon4] Regards Jon From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Konda@mcafee.com] Sent: 10 April 2018 07:10 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] Data Channel ACL fragments [Jon2] The "flags->fragment" definition is ambiguous for an ACE (but valid as to whether to allow a packet to get fragmented or not - is that really a ACE?) which I would like to use. [TR] I don't get it. What purpose does it serve to create a ACE rule using "fragment" bit ? [Jon3] Agreed - This definition has not been thought through for an ACE. I think they have just emulated the DF bit in RFC791 as this general flags definition is the same as for the flags in RFC791. [TR2] You may want to inform the authors of netmod-acl draft, surprisingly BGP flowspec also uses "fragment" bit. [Jon4] On my ToDo list for a clean solution. But we do now have a solution - see below. "Flags->more" definition covers all fragments but the last fragment. "Offset" is unfortunately not a range, but otherwise would get used for the final fragment. ~jon2 [TR] It looks like two ACE entries are required to drop all the fragments ("flags->more" set to 1 in the first ACE and "flags->more" set to 0 in the second ACE). How to use the "Offset" field for the final fragment ? [Jon3] I read "flags-more" to refer to the IP_MF in the IP header (RFC791 MF or more-fragments flag). This is set for all fragments apart from the final (as in last part of packet, not the order in which they are sent - fortunately that early decision to send them in the wrong order was phased out, but still there in some legacy systems!) [TR2] Yes, why can't "flags->more" be set to 0 as one ACE entry to drop the final fragment along with "flags->more" set to 1 to drop the first fragment as another ACE entry so as to drop all fragments to the target ? [Jon4] If "flags->more" is configured and it is configured with a value of 0, this will match not only the final fragment, but also a non-fragmented packet. If "flags->more" is not configured, then this will match a non-fragmented packet only. [TR3] net-mod-acl says "Setting the value to 0 indicates this is the last fragment, and setting the value to 1 indicates more fragments are coming.". I think it means, if "flags->more" is set to zero and offset is not zero then it indicates this is the last fragments; the flags can be used in isolation without comparing if offset value is zero or non-zero. We should check with netmod-acl authors for confirmation. [Jon5]. The netmod-acl text for flags and offset is effectively a word for word copy out of RFC791 3.1 Internet Header Format. So I think it is meant to be interpreted as being an exact match for the same - including the offset specific value. Flags: 3 bits Various Control Flags. Bit 0: reserved, must be zero Bit 1: (DF) 0 = May Fragment, 1 = Don't Fragment. Bit 2: (MF) 0 = Last Fragment, 1 = More Fragments. 0 1 2 +---+---+---+ | | D | M | | 0 | F | F | +---+---+---+ Fragment Offset: 13 bits This field indicates where in the datagram this fragment belongs. The fragment offset is measured in units of 8 octets (64 bits). The first fragment has offset zero. ---- Versus ---- leaf flags { type bits { bit reserved { position 0; description "Reserved. Must be zero."; } bit fragment { position 1; description "Setting value to 0 indicates may fragment, while setting the value to 1 indicates do not fragment."; } bit more { position 2; description "Setting the value to 0 indicates this is the last fragment, and setting the value to 1 indicates more fragments are coming."; } } description "Bit definitions for the flags field in IPv4 header."; } leaf offset { type uint16 { range "20..65535"; } description "The fragment offset is measured in units of 8 octets (64 bits). The first fragment has offset zero. The length is 13 bits"; } [Jon4] So, a L4 ACE without "flags->more" defined and "allow", followed by an ACE with "flags->more" = 1 and "drop", followed by an ACE with "flags->more" = 0 and "drop" will cause all fragmented packets to get dropped, but still allow through the non-fragmented packet. So, we have a solution for "allow all traffic to port 53, but drop all fragmented packets". [TR3] I don't think the above solution will work. In the above line, I think you meant L3 ACE, and the first fragment will match the first entry and is allowed. [Jon5]No, the first ACE is a L3/L4 match. If you have (a1 allows through all non-fragmented packets, a2 & a3 drops all fragmented packets) the following . { "aces": [{ "ace": { "name": "a1", "matches": [{ "ipv4": { "destination-network": "1.2.3.0/24" }, "udp": { "destination-port": 53 } }], "actions": { "forwarding": "accept" } } }, { "ace": { "name": "a2", "matches": [{ "ipv4": { "flags": { "destination-network": "1.2.3.0/24", "more": 0 }, "udp": { "destination-port": 53 } } }], "actions": { "forwarding": "drop" } } }, { "ace": { "name": "a3", "matches": [{ "ipv4": { "flags": { "more": 1 } } }], "actions": { "forwarding": "drop" } } } ] } . [Jon5] It will work -Tiru ~jon4 -Tiru [Jon3] But as the final fragment of the sequence could have any offset, the use of the offset field is not that helpful here. Even if we do go with our DOTS fragments definition (but widened to cover all fragments), we still cannot generate a netmod-acl entry for onward processing by an upstream mitigator. [Jon3] FYI, for Juniper, you just need to set 'first-fragment' and 'is-fragment' in their ACL. BGP FlowSpec does support fragmentation detection properly (RFC5575 Type 12 Fragment). -Tiru ------=_NextPart_000_00A9_01D3D0D0.C8FB1730 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

See inline = [Jon5]

 

Regards

 

Jon

 

From: Dots [mailto: -bounces@ietf.org] On Behalf Of = Konda, Tirumaleswar Reddy
Sent: 10 April 2018 = 12:34
To: Jon Shallow; mohamed.boucadair@orange.com; = dots@ietf.org
Subject: Re: [Dots] Data Channel ACL = fragments

 

Please see inline = [TR3]

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Tuesday, April 10, 2018 4:30 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: RE: = [Dots] Data Channel ACL fragments

 

Hi = Tiru,

 

See inline = [Jon4]

 

Regards

 

Jon

 

 

From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Kond= a@mcafee.com]
Sent: 10 April 2018 07:10
To: Jon = Shallow; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: RE: = [Dots] Data Channel ACL fragments

 

[Jon2] The = “flags->fragment” definition is ambiguous for an ACE (but = valid as to whether to allow a packet to get fragmented or not – = is that really a ACE?) which I would like to use.  =

 

[TR] I = don’t get it. What purpose does it serve to create a ACE rule = using “fragment” bit ?

[Jon3] = Agreed – This definition has not been thought through for an = ACE.  I think they have just emulated the DF bit in RFC791 as this = general flags definition is the same as for the flags in = RFC791.

 

[TR2] You may want to inform the authors of netmod-acl = draft, surprisingly BGP flowspec also uses “fragment” = bit.

[Jon4] On = my ToDo list for a clean solution.  But we do now have a solution = – see below.

 

 

“Flags->more” definition covers = all fragments but the last fragment. “Offset” is = unfortunately not a range, but otherwise would get used for the final = fragment.

~jon2

 

[TR] It = looks like two ACE entries are required to drop all the fragments = (“flags->more” set to 1 in the first ACE and = “flags->more” set to 0 in the second ACE). How to use the = “Offset”  field for the final fragment = ?

 

[Jon3] I = read “flags-more” to refer to the IP_MF in the IP header = (RFC791 MF or more-fragments flag).  This is set for all fragments = apart from the final (as in last part of packet, not the order in which = they are sent – fortunately that early decision to send them in = the wrong order was phased out, but still there in some legacy = systems!)

 

[TR2] Yes, why can’t “flags->more” be = set to 0 as one ACE entry to drop the final fragment along with = “flags->more” set to 1 to drop the first fragment as = another ACE entry so as to drop all fragments to the target = ?

[Jon4] If “flags->more” is = configured and it is configured with a value of 0, this will match not = only the final fragment, but also a non-fragmented packet.  If = “flags->more” is not configured, then this will match a = non-fragmented packet only.

 

[TR3] net-mod-acl says = "Setting the value to 0 indicates this is the last fragment, and = setting the value to 1 indicates more fragments are coming.". I = think it means, if “flags->more” is set to zero and = offset is not zero then it indicates this is the last fragments; the = flags can be used in isolation without comparing if offset value is zero = or non-zero. We should check with netmod-acl authors for confirmation. =

 

[Jon5].  The netmod-acl text for flags and = offset is effectively a word for word copy out of RFC791 3.1 Internet = Header Format.  So I think it is meant to be interpreted as being = an exact match for the same – including the offset specific = value.

 

  Flags:  3 = bits

 

    Various Control = Flags.

 

      Bit 0: reserved, = must be zero

      Bit 1: (DF) 0 =3D = May Fragment,  1 =3D Don't Fragment.

      Bit 2: (MF) 0 =3D = Last Fragment, 1 =3D More Fragments.

 

        &= nbsp; 0   1   2

        = +---+---+---+

        = |   | D | M |

        | 0 | = F | F |

        = +---+---+---+

 

  Fragment Offset:  13 = bits

 

    This field indicates where in = the datagram this fragment belongs.

 

    The fragment offset is = measured in units of 8 octets (64 bits).  = The

    first fragment has offset = zero.

 

 

----

 

Versus

 

----

    leaf flags = {

      type bits = {

        bit = reserved {

        &= nbsp; position 0;

        &= nbsp; description

        &= nbsp;   "Reserved. Must be = zero.";

        = }

        bit = fragment {

        &= nbsp; position 1;

        &= nbsp; description

        &= nbsp;   "Setting value to 0 indicates may fragment, while = setting

        &= nbsp;    the value to 1 indicates do not = fragment.";

        = }

        bit = more {

        &= nbsp; position 2;

        &= nbsp; description

        &= nbsp;   "Setting the value to 0 indicates this is the = last fragment,

        &= nbsp;    and setting the value to 1 indicates more = fragments are

        &= nbsp;    coming.";

        = }

      = }

      = description

        = "Bit definitions for the flags field in IPv4 = header.";

    }

 

    leaf offset = {

      type uint16 = {

        range = "20..65535";

      = }

 

      = description

        = "The fragment offset is measured in units of 8 octets (64 = bits).

         = The first fragment has offset zero. The length is 13 = bits";

    }

 

[Jon4] So, = a L4 ACE without “flags->more” defined and = “allow”, followed by an ACE with = “flags->more” =3D 1 and “drop”, followed by = an ACE with “flags->more” =3D 0 and “drop” = will cause all fragmented packets to get dropped, but still allow = through the non-fragmented packet.  So, we have a solution = for

“allow all traffic to port 53, but drop = all fragmented packets”.

 

[TR3] I don’t think the above = solution will work. In the above line, I think you  meant L3 ACE, = and the first fragment will match the first entry and is allowed. =

 

[Jon5]No, = the first ACE is a L3/L4 match.  If you have (a1 allows through all = non-fragmented packets, a2 & a3 drops all fragmented packets) the = following

 

…

{

       = "aces": [{

        &= nbsp;           &n= bsp;           &nb= sp;    "ace": {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       "name": = "a1",

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       "matches": = [{

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          = "ipv4": {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =              = "destination-network": = "1.2.3.0/24"

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          = },

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          "udp": = {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =              = "destination-port": 53

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          = }

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       }],

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       "actions": = {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          = "forwarding": "accept"

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       }

        &= nbsp;           &n= bsp;           &nb= sp;    }

        &= nbsp;           &n= bsp; },

        &= nbsp;           &n= bsp; {

        &= nbsp;           &n= bsp;           &nb= sp;    "ace": {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       "name": = "a2",

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       "matches": = [{

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          = "ipv4": {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =              = "flags": {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;   "destination-network": = "1.2.3.0/24",

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;   "more": 0

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =              = },

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =              = "udp": {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;   "destination-port": = 53

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =              = }

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          = }

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       }],

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       "actions": = {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          = "forwarding": "drop"

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       }

 

        &= nbsp;           &n= bsp;           &nb= sp;    }

        &= nbsp;           &n= bsp; },

        &= nbsp;           &n= bsp; {

        &= nbsp;           &n= bsp;           &nb= sp;    "ace": {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       "name": = "a3",

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       "matches": = [{

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          = "ipv4": {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =              = "flags": {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;   "more": 1

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =              = }

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          = }

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       }],

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       "actions": = {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          = "forwarding": "drop"

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       }

        &= nbsp;           &n= bsp;           &nb= sp;    }

        &= nbsp;           &n= bsp; }

       = ]

}

…

[Jon5] It = will work

 

-Tiru

 

~jon4

 

-Tiru

 

[Jon3] But = as the final fragment of the sequence could have any offset, the use of = the offset field is not that helpful here.  Even if we do go with = our DOTS fragments definition (but widened to cover all fragments), we = still cannot generate a netmod-acl entry for onward processing by an = upstream mitigator.

 

[Jon3] FYI, = for Juniper, you just need to set ‘first-fragment’ and = ‘is-fragment’ in their ACL.  BGP FlowSpec does support = fragmentation detection properly (RFC5575 Type 12 = Fragment).

 

 

-Tiru

------=_NextPart_000_00A9_01D3D0D0.C8FB1730-- From nobody Tue Apr 10 06:39:54 2018 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 46041120725; Tue, 10 Apr 2018 06:39:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.77.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152336759324.13436.2718962831054268683@ietfa.amsl.com> Date: Tue, 10 Apr 2018 06:39:53 -0700 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-signal-channel-19.txt 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: Tue, 10 Apr 2018 13:39:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DDoS Open Threat Signaling WG of the IETF. Title : Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification Authors : Tirumaleswar Reddy Mohamed Boucadair Prashanth Patil Andrew Mortensen Nik Teague Filename : draft-ietf-dots-signal-channel-19.txt Pages : 86 Date : 2018-04-10 Abstract: This document specifies the DOTS signal channel, a protocol for signaling the need for protection against Distributed Denial-of- Service (DDoS) attacks to a server capable of enabling network traffic mitigation on behalf of the requesting client. A companion document defines the DOTS data channel, a separate reliable communication layer for DOTS management and configuration purposes. Editorial Note (To be removed by RFC Editor) Please update these statements with the RFC number to be assigned to this document: o "This version of this YANG module is part of RFC XXXX;" o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification"; o "| [RFCXXXX] |" o reference: RFC XXXX Please update TBD statements with the port number to be assigned to DOTS Signal Channel Protocol. Also, please update the "revision" date of the YANG module. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-signal-channel-19 https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel-19 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-signal-channel-19 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 10 06:43:05 2018 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 3818C12778D for ; Tue, 10 Apr 2018 06:43:04 -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, 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=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 LQ9UipgMWArJ for ; Tue, 10 Apr 2018 06:43:02 -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 33C8D120725 for ; Tue, 10 Apr 2018 06:43:02 -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 w3ADh1Na012124 for ; Tue, 10 Apr 2018 09:43:01 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu w3ADh1Na012124 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1523367781; bh=smVuNBiD7MckWd9s7qo86IJ1hwOCB/GPLFy8K2MMPns=; h=From:To:Subject:Date:References:In-Reply-To:From; b=bmNEAWmAZxpB81DTx6pD5qg4HoeH5sn0QUXec/kkMtsKI89iqWrChtTn83A69725z T2aIbZWupmgDCFJTmCmMptQ9ESrirvtsd8+qHD2TpiRAwCpNqe/4cKdEEU0j6jl53u jrmKJCiAfkk5ISSbL7e8GEK2lydnHjj4E4HAVEy8= 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 w3ADh0c2040183 for ; Tue, 10 Apr 2018 09:43:00 -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; Tue, 10 Apr 2018 09:42:59 -0400 From: Roman Danyliw To: "dots@ietf.org" Thread-Topic: WGLC on DOTS Signal Channel Thread-Index: AdPA/2I8r8JGmyBkSmyI9HwbArIJBwP0jFcA Date: Tue, 10 Apr 2018 13:42:59 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC014C38025E@marathon> References: <359EC4B99E040048A7131E0F4E113AFC014C36B932@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC014C36B932@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: Re: [Dots] WGLC on DOTS Signal Channel 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, 10 Apr 2018 13:43:04 -0000 Hello! The WGLC last call on this draft closed this past Friday, April 6. Thank y= ou for all of your input. The authors continue to work on resolving commen= ts/feedback and will publish a new draft that captures this input. Thanks, Roman > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Roman Danyliw > Sent: Wednesday, March 21, 2018 6:33 AM > To: dots@ietf.org > Subject: [Dots] WGLC on DOTS Signal Channel >=20 > Hello! >=20 > Consistent with our discussion at the London meeting, we are starting a > working group last call (WGLC) for the DOTS Signal Channel draft: >=20 > DOTS Signal Channel Specification > draft-ietf-dots-signal-channel-18 > https://tools.ietf.org/html/draft-ietf-dots-signal-channel-18 >=20 > Please send comments to the DOTS mailing list -- feedback on remaining > issues or needed changes; as well as endorsements that this draft is read= y. >=20 > This WGLC will end on April 6, 2018. >=20 > Thanks, > Roman >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Tue Apr 10 06:47:54 2018 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 5487212946D for ; Tue, 10 Apr 2018 06:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 0ibS_rejQ6io for ; Tue, 10 Apr 2018 06:47:52 -0700 (PDT) Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 719B4127869 for ; Tue, 10 Apr 2018 06:47:50 -0700 (PDT) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 53803608D5 for ; Tue, 10 Apr 2018 15:47:49 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.2]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 352621800AA for ; Tue, 10 Apr 2018 15:47:49 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06%19]) with mapi id 14.03.0382.000; Tue, 10 Apr 2018 15:47:49 +0200 From: To: "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-signal-channel-19.txt Thread-Index: AQHT0NFsZJkEuRKAxUavjt82wa95JqP6AU7w Date: Tue, 10 Apr 2018 13:47:48 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DEFB67D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <152336759324.13436.2718962831054268683@ietfa.amsl.com> In-Reply-To: <152336759324.13436.2718962831054268683@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-19.txt 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, 10 Apr 2018 13:47:53 -0000 Re-, This version addresses the comments raised during the WGLC, in particular: = =20 - (Clarification) Indicate that only one hop-limit is included - Specify the loop diagnostic payload=20 - (Clarification) Indicate explicitly that GET messages with 'sid' are allo= wed - Update the redirect behavior.=20 Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de internet- > drafts@ietf.org > Envoy=E9=A0: mardi 10 avril 2018 15:40 > =C0=A0: i-d-announce@ietf.org > Cc=A0: dots@ietf.org > Objet=A0: [Dots] I-D Action: draft-ietf-dots-signal-channel-19.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the DDoS Open Threat Signaling WG of the IET= F. >=20 > Title : Distributed Denial-of-Service Open Threat Signa= ling > (DOTS) Signal Channel Specification > Authors : Tirumaleswar Reddy > Mohamed Boucadair > Prashanth Patil > Andrew Mortensen > Nik Teague > Filename : draft-ietf-dots-signal-channel-19.txt > Pages : 86 > Date : 2018-04-10 >=20 > Abstract: > This document specifies the DOTS signal channel, a protocol for > signaling the need for protection against Distributed Denial-of- > Service (DDoS) attacks to a server capable of enabling network > traffic mitigation on behalf of the requesting client. >=20 > A companion document defines the DOTS data channel, a separate > reliable communication layer for DOTS management and configuration > purposes. >=20 > Editorial Note (To be removed by RFC Editor) >=20 > Please update these statements with the RFC number to be assigned to > this document: >=20 > o "This version of this YANG module is part of RFC XXXX;" >=20 > o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling > (DOTS) Signal Channel Specification"; >=20 > o "| [RFCXXXX] |" >=20 > o reference: RFC XXXX >=20 > Please update TBD statements with the port number to be assigned to > DOTS Signal Channel Protocol. >=20 > Also, please update the "revision" date of the YANG module. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dots-signal-channel-19 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel-19 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-signal-channel-19 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Tue Apr 10 22:36:36 2018 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 AB72012706D for ; Tue, 10 Apr 2018 22:36:34 -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 g6JS6I9c-Nxb for ; Tue, 10 Apr 2018 22:36:31 -0700 (PDT) Received: from guri.nttv6.jp (guri.nttv6.jp [IPv6:2402:c800:ff06:136::140]) by ietfa.amsl.com (Postfix) with ESMTP id 83EF7126FDC for ; Tue, 10 Apr 2018 22:36:30 -0700 (PDT) Received: from z.nttv6.jp (z.nttv6.jp [192.168.8.15]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id 781DB25F692; Wed, 11 Apr 2018 14:36:27 +0900 (JST) Received: from MacBook-Pro-17.local (fujiko.nttv6.jp [115.69.228.141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 4653D763506; Wed, 11 Apr 2018 14:36:27 +0900 (JST) To: mohamed.boucadair@orange.com, "Konda, Tirumaleswar Reddy" , "dots@ietf.org" References: <359EC4B99E040048A7131E0F4E113AFC014C36B932@marathon> <68904f77-3cef-4c77-4cfa-3aeaacf95133@nttv6.jp> <787AE7BB302AE849A7480A190F8B93302DEF7927@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7277ba5c-436b-9027-8be0-49c8a53dbde2@nttv6.jp> <787AE7BB302AE849A7480A190F8B93302DEF79C9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEF7B45@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <69de4e41-1761-d02a-616d-85bc340601b4@nttv6.jp> <787AE7BB302AE849A7480A190F8B93302DEF91CB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DEFB59A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: kaname nishizuka Message-ID: Date: Wed, 11 Apr 2018 14:36:27 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DEFB59A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Dots] WGLC on DOTS Signal Channel 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: Wed, 11 Apr 2018 05:36:35 -0000 Hi Med, Tiru, > If we are silent about the response, this means that the client should accept both responses with or without 'sid' in the body. yes, agreed. I'm OK with the NEW text. Thank you! Kaname On 2018/04/10 21:21, mohamed.boucadair@orange.com wrote: > Re-, > > To conclude this one, I confirm that I added this NEW text: > > A DOTS client may issue a GET message with 'sid' parameter to retrieve the > configuration parameters. The response does not need to include 'sid' in its > message body. > > Cheers, > Med > >> -----Message d'origine----- >> De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] >> Envoyé : samedi 7 avril 2018 06:58 >> À : BOUCADAIR Mohamed IMT/OLN; kaname nishizuka; dots@ietf.org >> Objet : RE: [Dots] WGLC on DOTS Signal Channel >> >> Please see inline >> >>> -----Original Message----- >>> From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of >>> mohamed.boucadair@orange.com >>> Sent: Friday, April 6, 2018 12:53 PM >>> To: kaname nishizuka ; dots@ietf.org >>> Subject: Re: [Dots] WGLC on DOTS Signal Channel >>> >>> Hi Kaname, >>> >>> Please see inline. >>> >>> Cheers, >>> Med >>> >>>> -----Message d'origine----- >>>> De : kaname nishizuka [mailto:kaname@nttv6.jp] Envoyé : vendredi 6 >>>> avril 2018 07:40 À : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : >>>> Re: [Dots] WGLC on DOTS Signal Channel >>>> >>>> Hi Med, >>>> >>>> Please see inline. >>>> >>>> thanks, >>>> Kaname >>>> >>>> On 2018/04/04 18:28, mohamed.boucadair@orange.com wrote: >>>>> Re-, >>>>> >>>>> Thank you for the comments. >>>>> >>>>> Please see inline. >>>>> >>>>> Cheers, >>>>> Med >>>>> >>>>>> -----Message d'origine----- >>>>>> De : kaname nishizuka [mailto:kaname@nttv6.jp] Envoyé : mercredi 4 >>>>>> avril 2018 10:20 À : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet >>>>>> : Re: [Dots] WGLC on DOTS Signal Channel >>>>>> >>>>>> Hi Med, >>>>>> >>>>>> Thank you for the clarification and the proper reference. >>>>>> I can not assume that my DOTS client will do Out-of-Order >>>>>> Configuration Requests, but... I got understand that 'sid' is the >>>>>> solution to out of >>>> order >>>>>> configuration requests. >>>>>> >>>>>> 2 more questions: >>>>>> >>>>>> 1. GET with sid >>>>>> On the slide 12, it is written in the table that 'sid' URI >>>>>> Parameter MUST >>>> NOT >>>>>> exist in GET. >>>>> [Med] Actually, the GET in that slide refers to the case to discover >>>> configuration parameters when, for example, a client bootstraps. In >>>> such case, there is no 'sid' to play with. >>>>>> However, In RFC7252: >>>>>> 5.8.1. GET >>>>>>  The GET method retrieves a representation for the information that >>>>>>  currently corresponds to the resource identified by the request >> URI. >>>>>> So, I think the resource made by PUT in the exact URI path may be >>>> retrieved >>>>>> by GET. >>>>> [Med] Agree. The signal channel specification does not change the >>>>> RFC7252 >>>> behavior. >>>>>> I and Jon got consensus that the expected response of GET with sid >>>>>> is a "Figure 18: GET Configuration Response Body" like response >>>>>> with current >>>> value >>>>>> of that sid at the interop testing. >>>>>> The current draft is not clear about this behavior. >>>>> [Med] As I mentioned above, we are not changing the 7252 behavior. I >>>>> can >>>> add this NEW text if it helps: >>>>> A DOTS client may issue a GET message with or without 'sid' >> parameter >>>>> to retrieve the configuration parameters. The response message >> body >>>>> is the same as the one depicted in Figure 18. >>>>> >>>> [kaname] >>>> Referring to Figure 18 was not precise, sorry. >>>> The GET with sid will include sid in response body according to YANG >>>> module(5.1, 5.2) >>>> >>>> So, this would be more precise. >>>> >>>> A DOTS client may issue a GET message with or without 'sid' parameter >>>> to retrieve the configuration parameters. The response message body >>>> follows the YANG module "ietf-dots-signal-channel" (Section 5.2). >>>> >>> [Med] I suggest to delete "or without" because this is already discussed in >> 4.5.1. >>> "A DOTS client may issue a GET message with 'sid' parameter to retrieve the >>> configuration parameters." >>> >>> If we are silent about the response, this means that the client should >> accept >>> both responses with or without 'sid' in the body. >>> >>> Do you want the text to be more specific, e.g.: >>> (1) always return sid in the response? If so, does the client uses that >> information >>> for some processing? >>> (2) forbid to return the sid? The client will assume that the response >> matches the >>> sid included in the request. >>> (3) allow for both cases. >> Configuration request/response are confirmable messages, DOTS client will >> know if its request is accepted by the server or not, don't see the need to >> return "sid" in the response. >> However, "sid" is useful in the request, though the client sends >> configuration request in order, they may arrive >> at the DOTS server out-of-order (requests may take different network paths). >> >> Cheers >> -Tiru >> >>>>>> 2. how to get default values after several negotiations GET without >>>>>> sid returns the current values. >>>>>> The default values can be retrieved only just after bootsrapping or >>>> sending >>>>>> DELETE request. >>>>>> (a DOTS client MAY send a DELETE request to set the configuration >>>> parameters >>>>>> to default values.) >>>>>> I'd like to get the default values even after negotiations. Is >>>>>> there any >>>> way >>>>>> to get them? >>>>> [Med] Default values are known to DOTS agents by design. That is a >>>>> DOTS >>>> agent assumes the following default values: >>>>> The RECOMMENDED values of transmission parameter >>>>> values are ack-timeout (2 seconds), max-retransmit (3), ack-random- >>>>> factor (1.5). In addition to those parameters, the RECOMMENDED >>>>> specific DOTS transmission parameter values are 'heartbeat- >> interval' >>>>> (30 seconds) and 'missing-hb-allowed' (5). >>>> [Kaname] >>>> I thought each DOTS server could have its own default values because >>>> the default values by design is just a recommendation. >>>> >>> [Med] One way to discover whether a sever uses non-recommended values as >>> default is to issue a GET at bootstrap or after a DELTETE. >>> >>>>> When DOTS agents negotiate a given parameter, the negotiated value >>>>> is used >>>> to override the default one. Otherwise, the default value is used. >>>>> A DOTS client maintains a state whether a value was negotiated. As >>>>> such, a >>>> DOTS client does not need to discover default values. >>>> [Kaname] >>>> Yes, that's true. >>>> What I thought was, from operational perspective, an operator may want >>>> to know the default values of the DOTS server before deleting the >>>> negotiated values. >>>> But, I agree that is out of DOTS spec. >>>> >>>>> Did I missed something? >>>> >>>>>> thanks, >>>>>> Kaname >>>>>> >>>>>> >>>>>> >>>>>> On 2018/04/04 16:31, mohamed.boucadair@orange.com wrote: >>>>>>> Re-, >>>>>>> >>>>>>> Please see inline. >>>>>>> >>>>>>> Cheers, >>>>>>> Med >>>>>>> >>>>>>>> -----Message d'origine----- >>>>>>>> De : kaname nishizuka [mailto:kaname@nttv6.jp] Envoyé : mercredi >>>>>>>> 4 avril 2018 08:57 À : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org >>>>>>>> Objet : Re: [Dots] WGLC on DOTS Signal Channel >>>>>>>> >>>>>>>> Hi Med, >>>>>>>> >>>>>>>> >>>>>>>> On 2018/04/04 15:22, mohamed.boucadair@orange.com wrote: >>>>>>>>> Hi Kaname, >>>>>>>>> >>>>>>>>> Please see inline. >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Med >>>>>>>>> >>>>>>>>>> -----Message d'origine----- >>>>>>>>>> De : Dots [mailto:dots-bounces@ietf.org] De la part de kaname >>>> nishizuka >>>>>>>>>> Envoyé : mercredi 4 avril 2018 02:27 À : dots@ietf.org Objet : >>>>>>>>>> Re: [Dots] WGLC on DOTS Signal Channel >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I have one clarification questions about sid in signal channel >>>>>>>>>> session configuration. >>>>>>>>>> >>>>>>>>>> The draft says: >>>>>>>>>>  At least one of the attributes ’heartbeat-interval’, >>>>>>>>>> ’missing-hb allowed’, ’max-retransmit’, ’ack-timeout’, ’ack- >> random- >>> factor’, and >>>>>>>>>>  ’trigger-mitigation’ MUST be present in the PUT request. >>>>>>>>>>  (snip) >>>>>>>>>>  The PUT request with a higher numeric ’sid’ value >>>>>>>>>> overrides the >>>> DOTS >>>>>>>>>>  signal channel session configuration data installed by a >>>>>>>>>> PUT >>>> request >>>>>>>>>>  with a lower numeric ’sid’ value. >>>>>>>>>> >>>>>>>>>> assuming these are default values of a DOTS server: >>>>>>>>>>  'heartbeat-interval'=30 >>>>>>>>>>  ’max-retransmit’=3 >>>>>>>>>> >>>>>>>>>> if these messages came to the DOTS server consecutively, >>>>>>>>>>  1. sid=123, "heartbeat-interval"=10 >>>>>>>>>>  2. sid=456, ’max-retransmit’=5 in the final state, the >>>>>>>>>> first change should be discarded?: >>>>>>>>>>  'heartbeat-interval'=30 >>>>>>>>>>  ’max-retransmit’=5 >>>>>>>>>> or accumulated?: >>>>>>>>>>  'heartbeat-interval'=10 >>>>>>>>>>  ’max-retransmit’=5 >>>>>>>>>> >>>>>>>>>> so, the question is: should they be overridden by default >>>>>>>>>> values even >>>> if >>>>>>>> it >>>>>>>>>> is not specified? >>>>>>>>> [Med] The behavior to follow is covered by this text: >>>>>>>>> >>>>>>>>> The PUT request with a higher numeric 'sid' value >>>>>>>>> overrides the >>>> DOTS >>>>>>>>> signal channel session configuration data installed by a >>>>>>>>> PUT >>>> request >>>>>>>>> with a lower numeric 'sid' value. To avoid maintaining a >>>>>>>>> long >>>> list >>>>>>>>> of 'sid' requests from a DOTS client, the lower numeric 'sid' >>>> MUST >>>>>> be >>>>>>>>> automatically deleted and no longer available at the DOTS >> server. >>>>>>>>> And >>>>>>>>> >>>>>>>>> The DOTS agents MUST use the negotiated >>>>>>>>> values for message transmission parameters and default values >> for >>>>>>>>> non-negotiated message transmission parameters. >>>>>>>> Thanks, so, in my example, final state is >>>>>>>>   'heartbeat-interval'=30 (reverted to default value) >>>>>>>>   ’max-retransmit’=5 >>>>>>>> and the lower numeric 'sid' no longer exist in the DOTS server, >> right? >>>>>>> [Med] Exactly. >>>>>>> >>>>>>>>>> I think the former is ideal behavior. >>>>>>>>>> However, if so, the DOTS server is only required to keep the >>>>>>>>>> latest >>>>>>>> resource >>>>>>>>>> of the highest sid, >>>>>>>>>> then there should be no difference between DELETE message with >>>>>>>>>> and >>>>>> without >>>>>>>>>> sid. >>>>>>>>>> >>>>>>>>> [Med] To delete a configuration, a client may send a DELETE with >>>>>>>>> a >>>> valid >>>>>>>> 'sid' or a DELETE without supplying a 'sid'. >>>>>>>>> Both are considered as valid in Section 4.5.4. >>>>>>>>> >>>>>>>> both are OK and have the same effect on DOTS server, right? >>>>>>> [Med] Yes. >>>>>>> >>>>>>>> A DOTS server always keeps the latest sid only. >>>>>>> [Med] Not the "latest" received sid...but the request with the >>>>>>> higher >>>> sid. >>>>>>> A DOTS client always attempt >>>>>>>> to update it. >>>>>>>> So there is no reason to use PUT, GET, DELETE with sid. >>>>>>>> Why sid does exist is confusing me. >>>>>>> [Med] 'sid' is there to solve out of order configuration requests. >>>>>>> The >>>>>> rationale is explained in slide 12 of >>>>>> https://datatracker.ietf.org/meeting/interim-2018-dots- >>>> 01/materials/slides- >>>>>> interim-2018-dots-01-sessa-signal-channel-00.pdf >>>>>>>> I'm afraid it was discussed on the ML but I'd like to know the >>>>>>>> rational >>>> of >>>>>>>> existence of sid. >>>>>>>> ``` >>>>>>>>  sid: Session Identifier is an identifier for the DOTS signal >> channel >>>>>>>>  session configuration data represented as an integer. This >>>>>>>>  identifier MUST be generated by DOTS clients. ’sid’ values MUST >>>>>>>>  increase monotonically. >>>>>>>> ``` >>>>>>>> this is not convincing because always only one configuration is >>>> registered >>>>>> on >>>>>>>> DOTS server. >>>>>>>> it will completely work without sid. >>>>>>>> >>>>>>>> thanks, >>>>>>>> Kaname >>>>>>>> >>>>>>>> >>>>>>>>>> regards, >>>>>>>>>> Kaname >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2018/03/21 19:32, Roman Danyliw wrote: >>>>>>>>>>> Hello! >>>>>>>>>>> >>>>>>>>>>> Consistent with our discussion at the London meeting, we are >>>>>>>>>>> starting >>>> a >>>>>>>>>> working group last call (WGLC) for the DOTS Signal Channel draft: >>>>>>>>>>> DOTS Signal Channel Specification >>>>>>>>>>> draft-ietf-dots-signal-channel-18 >>>>>>>>>>> https://tools.ietf.org/html/draft-ietf-dots-signal-channel-18 >>>>>>>>>>> >>>>>>>>>>> Please send comments to the DOTS mailing list -- feedback on >>>> remaining >>>>>>>>>> issues or needed changes; as well as endorsements that this >>>>>>>>>> draft is >>>>>>>> ready. >>>>>>>>>>> This WGLC will end on April 6, 2018. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Roman >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Dots mailing list >>>>>>>>>>> Dots@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dots >>>>>>>>>> _______________________________________________ >>>>>>>>>> Dots mailing list >>>>>>>>>> Dots@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/dots >>>>>>>>> _______________________________________________ >>>>>>>>> Dots mailing list >>>>>>>>> Dots@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/dots >>>>>>> _______________________________________________ >>>>>>> Dots mailing list >>>>>>> Dots@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/dots >>>>> _______________________________________________ >>>>> Dots mailing list >>>>> Dots@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dots >>> _______________________________________________ >>> Dots mailing list >>> Dots@ietf.org >>> https://www.ietf.org/mailman/listinfo/dots From nobody Wed Apr 11 11:36:15 2018 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 34126129515 for ; Wed, 11 Apr 2018 11:36:14 -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 iKVjg-nfZNFA for ; Wed, 11 Apr 2018 11:36:12 -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 1342F12946D for ; Wed, 11 Apr 2018 11:36:12 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.90_1) (envelope-from ) id 1f6KbI-0005XN-Vj; Wed, 11 Apr 2018 19:36:09 +0100 From: "Jon Shallow" To: , References: <152336759324.13436.2718962831054268683@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302DEFB67D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DEFB67D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Wed, 11 Apr 2018 19:36:07 +0100 Message-ID: <000301d3d1c3$f5ee2810$e1ca7830$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLtkEb0W5betwnY/yHoXL68fQEa1gHvZXoHobjlHIA= Content-Language: en-gb Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-19.txt 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: Wed, 11 Apr 2018 18:36:14 -0000 Hi Med, Thanks for this. Only one very minor issue seen so far (it was an issue in previous draft = for ttl) - alt-server-ttl is integer in some places (which is correct), and unsigned integer in other places (YANG model / YANG tree / CBOR mapping) which need to be corrected to integer (or int32). General question - where are we with the port allocation and all the = other IANA requests for allocation? Regards Jon -----Original Message----- From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 10 April 2018 14:48 To: dots@ietf.org Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-19.txt Re-, This version addresses the comments raised during the WGLC, in = particular: =20 - (Clarification) Indicate that only one hop-limit is included - Specify the loop diagnostic payload - (Clarification) Indicate explicitly that GET messages with 'sid' are allowed - Update the redirect behavior.=20 Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de internet-=20 > drafts@ietf.org Envoy=E9=A0: mardi 10 avril 2018 15:40 =C0=A0:=20 > i-d-announce@ietf.org Cc=A0: dots@ietf.org Objet=A0: [Dots] I-D = Action:=20 > draft-ietf-dots-signal-channel-19.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. > This draft is a work item of the DDoS Open Threat Signaling WG of the IETF. >=20 > Title : Distributed Denial-of-Service Open Threat Signaling > (DOTS) Signal Channel Specification > Authors : Tirumaleswar Reddy > Mohamed Boucadair > Prashanth Patil > Andrew Mortensen > Nik Teague > Filename : draft-ietf-dots-signal-channel-19.txt > Pages : 86 > Date : 2018-04-10 >=20 > Abstract: > This document specifies the DOTS signal channel, a protocol for > signaling the need for protection against Distributed Denial-of- > Service (DDoS) attacks to a server capable of enabling network > traffic mitigation on behalf of the requesting client. >=20 > A companion document defines the DOTS data channel, a separate > reliable communication layer for DOTS management and configuration > purposes. >=20 > Editorial Note (To be removed by RFC Editor) >=20 > Please update these statements with the RFC number to be assigned = to > this document: >=20 > o "This version of this YANG module is part of RFC XXXX;" >=20 > o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling > (DOTS) Signal Channel Specification"; >=20 > o "| [RFCXXXX] |" >=20 > o reference: RFC XXXX >=20 > Please update TBD statements with the port number to be assigned to > DOTS Signal Channel Protocol. >=20 > Also, please update the "revision" date of the YANG module. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dots-signal-channel-19 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel-1 > 9 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-signal-channel-19 >=20 >=20 > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Wed Apr 11 23:15:50 2018 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 B4A2612D955 for ; Wed, 11 Apr 2018 23:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 Fod4K7L3X9Ll for ; Wed, 11 Apr 2018 23:15:48 -0700 (PDT) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD03C12D94E for ; Wed, 11 Apr 2018 23:15:47 -0700 (PDT) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 40M9dG0PqVz2xvL; Thu, 12 Apr 2018 08:15:46 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.2]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id E16F9180061; Thu, 12 Apr 2018 08:15:45 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06%19]) with mapi id 14.03.0389.001; Thu, 12 Apr 2018 08:15:45 +0200 From: To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-signal-channel-19.txt Thread-Index: AQLtkEb0W5betwnY/yHoXL68fQEa1gHvZXoHobjlHICAAMj3MA== Date: Thu, 12 Apr 2018 06:15:45 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DF089BF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <152336759324.13436.2718962831054268683@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302DEFB67D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <000301d3d1c3$f5ee2810$e1ca7830$@jpshallow.com> In-Reply-To: <000301d3d1c3$f5ee2810$e1ca7830$@jpshallow.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-19.txt 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, 12 Apr 2018 06:15:49 -0000 Hi Jon,=20 Fixed those in the tree, YANG, and CBOR mapping table. Thank you for catchi= ng those.=20 I don't have any update to share about the port allocation. Cheers, Med > -----Message d'origine----- > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > Envoy=E9=A0: mercredi 11 avril 2018 20:36 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; dots@ietf.org > Objet=A0: RE: [Dots] I-D Action: draft-ietf-dots-signal-channel-19.txt >=20 > Hi Med, >=20 > Thanks for this. >=20 > Only one very minor issue seen so far (it was an issue in previous draft = for > ttl) - alt-server-ttl is integer in some places (which is correct), and > unsigned integer in other places (YANG model / YANG tree / CBOR mapping) > which need to be corrected to integer (or int32). >=20 > General question - where are we with the port allocation and all the othe= r > IANA requests for allocation? >=20 > Regards >=20 > Jon >=20 > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > mohamed.boucadair@orange.com > Sent: 10 April 2018 14:48 > To: dots@ietf.org > Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-19.txt >=20 > Re-, >=20 > This version addresses the comments raised during the WGLC, in particular= : > - (Clarification) Indicate that only one hop-limit is included > - Specify the loop diagnostic payload > - (Clarification) Indicate explicitly that GET messages with 'sid' are > allowed > - Update the redirect behavior. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de internet- > > drafts@ietf.org Envoy=E9=A0: mardi 10 avril 2018 15:40 =C0=A0: > > i-d-announce@ietf.org Cc=A0: dots@ietf.org Objet=A0: [Dots] I-D Action: > > draft-ietf-dots-signal-channel-19.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the DDoS Open Threat Signaling WG of the > IETF. > > > > Title : Distributed Denial-of-Service Open Threat > Signaling > > (DOTS) Signal Channel Specification > > Authors : Tirumaleswar Reddy > > Mohamed Boucadair > > Prashanth Patil > > Andrew Mortensen > > Nik Teague > > Filename : draft-ietf-dots-signal-channel-19.txt > > Pages : 86 > > Date : 2018-04-10 > > > > Abstract: > > This document specifies the DOTS signal channel, a protocol for > > signaling the need for protection against Distributed Denial-of- > > Service (DDoS) attacks to a server capable of enabling network > > traffic mitigation on behalf of the requesting client. > > > > A companion document defines the DOTS data channel, a separate > > reliable communication layer for DOTS management and configuration > > purposes. > > > > Editorial Note (To be removed by RFC Editor) > > > > Please update these statements with the RFC number to be assigned to > > this document: > > > > o "This version of this YANG module is part of RFC XXXX;" > > > > o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling > > (DOTS) Signal Channel Specification"; > > > > o "| [RFCXXXX] |" > > > > o reference: RFC XXXX > > > > Please update TBD statements with the port number to be assigned to > > DOTS Signal Channel Protocol. > > > > Also, please update the "revision" date of the YANG module. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-dots-signal-channel-19 > > https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel-1 > > 9 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-signal-channel-19 > > > > > > 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. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Fri Apr 13 02:03:53 2018 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 6CB561243FE for ; Fri, 13 Apr 2018 02:03:51 -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, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-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 AAb_1BZty86N for ; Fri, 13 Apr 2018 02:03:48 -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 172ED120721 for ; Fri, 13 Apr 2018 02:03:45 -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=1523610225; 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: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-microsoft-antispam: x-ms-traffictypediagnostic:x-microsoft-antispam-prvs: x-exchange-antispam-report-test:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Office365-Filtering-Correlation-Id: X-MS-Exchange-CrossTenant-Network-Message-Id: 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=t wq6qtkTS7mR3ju/x0fYNzR8kg0tx2K5f2D7cECrz7 s=; b=HO1bllwczD1sLCkPgMYvcYPqfrkXXsmbUUWO3gUhOaiE /X1qzSSPS3Axk52UOH8czFvt9tB/P0/cAFtG0DnCtJUzN1IOYQ uBuIMV6XYO1CGnQwkJfTKE2mgYqhpfGXo6yfC+B2pTUDGA1qOc 5nJHmYkUmFDfRinMqk1THDUwan8= Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 277a_d577_0fae56bc_6ffa_4dd3_a827_979d945527ff; Fri, 13 Apr 2018 04:03:44 -0500 Received: from DNVEXUSR1N12.corpzone.internalzone.com (10.44.48.85) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 13 Apr 2018 03:02:59 -0600 Received: from DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) by DNVEXUSR1N12.corpzone.internalzone.com (10.44.48.85) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 13 Apr 2018 03:02:58 -0600 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Fri, 13 Apr 2018 03:02:58 -0600 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (10.44.176.241) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 13 Apr 2018 03:02:56 -0600 Received: from BN6PR16MB1425.namprd16.prod.outlook.com (10.172.207.19) by BN6PR16MB1714.namprd16.prod.outlook.com (10.172.28.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.675.10; Fri, 13 Apr 2018 09:02:55 +0000 Received: from BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::4430:6104:630b:a067]) by BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::4430:6104:630b:a067%2]) with mapi id 15.20.0675.014; Fri, 13 Apr 2018 09:02:55 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: [Dots] Data Channel ACL fragments Thread-Index: AdPMHAMfDWFlXvb3TSeAr5MVkYUzIgAA3pEAAAKPJoAAIuTfcAADWaQAAADopUAAyEgtgAACNjegABYTlwAAEYzK0AAHIEOAAAC6rLAAAzlEAAAAT7KgAAMBYAAAjfWr8A== Date: Fri, 13 Apr 2018 09:02:54 +0000 Message-ID: References: <016401d3cc1c$03321200$09963600$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7F97@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <01a701d3cc29$ba915b10$2fb41130$@jpshallow.com> <007501d3ccc2$b49f0b00$1ddd2100$@jpshallow.com> <021301d3cfe7$77e5cbe0$67b163a0$@jpshallow.com> <02b001d3d048$a2c68be0$e853a3a0$@jpshallow.com> <000001d3d0ab$547dec40$fd79c4c0$@jpshallow.com> <007701d3d0bb$2404c330$6c0e4990$@jpshallow.com> <00a801d3d0c8$67315800$35940800$@jpshallow.com> In-Reply-To: <00a801d3d0c8$67315800$35940800$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR16MB1714; 7:khBLkxzcjh6qQ2VHbsEPbTfIcOYDPjEAv0f+zsW1UfRGhsfndwnvB1pTk6PqtUU77Z4Bi9RDLL9kL0X8IYN+56/HXMsfSgydy8yhicOFk8oyO7h2FExOZGr/sonaNLs76RNzFIJYUqr50HQvd9JvxJDYVAosJ7pUSjo9cF8gDmILRmxaDQMmnkS6/wNldu+xS/Yi/+bZOyGqUedUCRF9IRSHoGVo6567UX/HKXFqWRGMiLQtepjnDfAolc6Zjo4P x-ms-exchange-antispam-srfa-diagnostics: SOS; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BN6PR16MB1714; x-ms-traffictypediagnostic: BN6PR16MB1714: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(18271650672692)(21748063052155)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231232)(944501327)(52105095)(93006095)(93001095)(3002001)(10201501046)(6041310)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:BN6PR16MB1714; BCL:0; PCL:0; RULEID:; SRVR:BN6PR16MB1714; x-forefront-prvs: 0641678E68 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39380400002)(376002)(366004)(39850400004)(346002)(396003)(32952001)(189003)(69234005)(199004)(9326002)(5660300001)(97736004)(53936002)(53946003)(11346002)(3280700002)(2900100001)(80792005)(486006)(476003)(8936002)(2201001)(316002)(93886005)(74316002)(72206003)(81156014)(81166006)(7736002)(110136005)(186003)(446003)(8676002)(2501003)(99286004)(68736007)(6506007)(6116002)(229853002)(106356001)(66066001)(3846002)(7696005)(790700001)(105586002)(76176011)(86362001)(25786009)(59450400001)(2906002)(53546011)(102836004)(33656002)(55016002)(54896002)(6436002)(14454004)(236005)(478600001)(5250100002)(3660700001)(6306002)(26005)(19609705001)(6246003)(9686003)(85282002)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR16MB1714; H:BN6PR16MB1425.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: YMwFuizePu6S7qK3UyDUjzLunmD/1yOM8VNqMKflZiHsFGRB1nEPznZDekn8YUrP3oE9cIELKQVL3S48Vh8lPdXDH8rcNf89s1rDe2qxWf9ivus9gNMEQ9I/UpyEpFoZE1qqayhawWKXewouH9Vlu2K/hYiAJY7X5agjcqvYexHEJaF8FhOnI0L9qIKnHhCk3Y7M31s1eVmwzB3SgfSfaQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR16MB142519B30BC7F44E332B7077EAB30BN6PR16MB1425namp_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 38ba38e0-c6c0-4163-775c-08d5a11d5888 X-MS-Exchange-CrossTenant-Network-Message-Id: 38ba38e0-c6c0-4163-775c-08d5a11d5888 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Apr 2018 09:02:54.8317 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR16MB1714 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 <6263> : inlines <6559> : streams <1783891> : uri <2624724> Archived-At: Subject: Re: [Dots] Data Channel ACL fragments 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, 13 Apr 2018 09:03:51 -0000 --_000_BN6PR16MB142519B30BC7F44E332B7077EAB30BN6PR16MB1425namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jon, Please see inline From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Tuesday, April 10, 2018 6:05 PM To: Konda, Tirumaleswar Reddy ; mohamed= .boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] Data Channel ACL fragments Hi Tiru, See inline [Jon5] Regards Jon From: Dots [mailto: -bounces@ietf.org] On Behalf = Of Konda, Tirumaleswar Reddy Sent: 10 April 2018 12:34 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] Data Channel ACL fragments Please see inline [TR3] From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Tuesday, April 10, 2018 4:30 PM To: Konda, Tirumaleswar Reddy >; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] Data Channel ACL fragments Hi Tiru, See inline [Jon4] Regards Jon From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Konda@mcafee.com= ] Sent: 10 April 2018 07:10 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] Data Channel ACL fragments [Jon2] The "flags->fragment" definition is ambiguous for an ACE (but valid = as to whether to allow a packet to get fragmented or not - is that really a= ACE?) which I would like to use. [TR] I don't get it. What purpose does it serve to create a ACE rule using = "fragment" bit ? [Jon3] Agreed - This definition has not been thought through for an ACE. I= think they have just emulated the DF bit in RFC791 as this general flags d= efinition is the same as for the flags in RFC791. [TR2] You may want to inform the authors of netmod-acl draft, surprisingly = BGP flowspec also uses "fragment" bit. [Jon4] On my ToDo list for a clean solution. But we do now have a solution= - see below. "Flags->more" definition covers all fragments but the last fragment. "Offse= t" is unfortunately not a range, but otherwise would get used for the final= fragment. ~jon2 [TR] It looks like two ACE entries are required to drop all the fragments (= "flags->more" set to 1 in the first ACE and "flags->more" set to 0 in the s= econd ACE). How to use the "Offset" field for the final fragment ? [Jon3] I read "flags-more" to refer to the IP_MF in the IP header (RFC791 M= F or more-fragments flag). This is set for all fragments apart from the fi= nal (as in last part of packet, not the order in which they are sent - fort= unately that early decision to send them in the wrong order was phased out,= but still there in some legacy systems!) [TR2] Yes, why can't "flags->more" be set to 0 as one ACE entry to drop the= final fragment along with "flags->more" set to 1 to drop the first fragmen= t as another ACE entry so as to drop all fragments to the target ? [Jon4] If "flags->more" is configured and it is configured with a value of = 0, this will match not only the final fragment, but also a non-fragmented p= acket. If "flags->more" is not configured, then this will match a non-frag= mented packet only. [TR3] net-mod-acl says "Setting the value to 0 indicates this is the last f= ragment, and setting the value to 1 indicates more fragments are coming.". = I think it means, if "flags->more" is set to zero and offset is not zero th= en it indicates this is the last fragments; the flags can be used in isolat= ion without comparing if offset value is zero or non-zero. We should check = with netmod-acl authors for confirmation. [Jon5]. The netmod-acl text for flags and offset is effectively a word for= word copy out of RFC791 3.1 Internet Header Format. So I think it is mean= t to be interpreted as being an exact match for the same - including the of= fset specific value. Flags: 3 bits Various Control Flags. Bit 0: reserved, must be zero Bit 1: (DF) 0 =3D May Fragment, 1 =3D Don't Fragment. Bit 2: (MF) 0 =3D Last Fragment, 1 =3D More Fragments. 0 1 2 +---+---+---+ | | D | M | | 0 | F | F | +---+---+---+ Fragment Offset: 13 bits This field indicates where in the datagram this fragment belongs. The fragment offset is measured in units of 8 octets (64 bits). The first fragment has offset zero. ---- Versus ---- leaf flags { type bits { bit reserved { position 0; description "Reserved. Must be zero."; } bit fragment { position 1; description "Setting value to 0 indicates may fragment, while setting the value to 1 indicates do not fragment."; } bit more { position 2; description "Setting the value to 0 indicates this is the last fragment, and setting the value to 1 indicates more fragments are coming."; } } description "Bit definitions for the flags field in IPv4 header."; } leaf offset { type uint16 { range "20..65535"; } description "The fragment offset is measured in units of 8 octets (64 bits). The first fragment has offset zero. The length is 13 bits"; } [Jon4] So, a L4 ACE without "flags->more" defined and "allow", followed by = an ACE with "flags->more" =3D 1 and "drop", followed by an ACE with "flags-= >more" =3D 0 and "drop" will cause all fragmented packets to get dropped, b= ut still allow through the non-fragmented packet. So, we have a solution f= or "allow all traffic to port 53, but drop all fragmented packets". [TR3] I don't think the above solution will work. In the above line, I thin= k you meant L3 ACE, and the first fragment will match the first entry and = is allowed. [Jon5]No, the first ACE is a L3/L4 match. If you have (a1 allows through a= ll non-fragmented packets, a2 & a3 drops all fragmented packets) the follow= ing [TR4] The first fragment will have both L3 and L4 information, and matches = a1 and is allowed, but if the order is changed to a3, a1 and a2 (a3 will dr= op all fragments except last-fragment, the last fragment will not have L4 i= nfo, so will not match a1 but will match a2 and get dropped). -Tiru ... { "aces": [{ "ace": { "name": "a1", "matches": [{ "ipv4": = { = "destination-network": "1.2.3.0/24" }, "udp": { = "destination-port": 53 } }], "actions": { "forward= ing": "accept" } } }, { "ace": { "name": "a2", "matches": [{ "ipv4": = { = "flags": { = "destination-network": "1.2.3.0/24", = "more": 0 = }, = "udp": { = "destination-port": 53 = } } }], "actions": { "forward= ing": "drop" } } }, { "ace": { "name": "a3", "matches": [{ "ipv4": = { = "flags": { = "more": 1 = } } }], "actions": { "forward= ing": "drop" } } } ] } ... [Jon5] It will work -Tiru ~jon4 -Tiru [Jon3] But as the final fragment of the sequence could have any offset, the= use of the offset field is not that helpful here. Even if we do go with o= ur DOTS fragments definition (but widened to cover all fragments), we still= cannot generate a netmod-acl entry for onward processing by an upstream mi= tigator. [Jon3] FYI, for Juniper, you just need to set 'first-fragment' and 'is-frag= ment' in their ACL. BGP FlowSpec does support fragmentation detection prop= erly (RFC5575 Type 12 Fragment). -Tiru --_000_BN6PR16MB142519B30BC7F44E332B7077EAB30BN6PR16MB1425namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jon,

&nbs= p;

Please se= e inline

 

From:<= /span> Jon Shallow [mailto:s= upjps-ietf@jpshallow.com]
Sent: Tuesday, April 10, 2018 6:05 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; mohamed.boucadair@orange.com; dots@ietf.org
Subject: RE: [Dots] Data Channel ACL fragments

 

Hi Tiru= ,

&n= bsp;

See inl= ine [Jon5]

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: -bounces@ietf.org] On Behalf Of= Konda, Tirumaleswar Reddy
Sent: 10 April 2018 12:34
To: Jon Shallow; moh= amed.boucadair@orange.com; dots@ietf.org
Subject: Re: [Dots] Data Channel ACL fragments

 

Please se= e inline [TR3]

&nbs= p;

From:<= /span> Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Tuesday, April 10, 2018 4:30 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; mohamed.boucadair@orange.co= m; dots@ietf.org
Subject: RE: [Dots] Data Channel ACL fragments

 

Hi Tiru= ,

&n= bsp;

See inl= ine [Jon4]

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

&n= bsp;

From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Kon= da@mcafee.com]
Sent: 10 April 2018 07:10
To: Jon Shallow; moh= amed.boucadair@orange.com; dots@ietf.org
Subject: RE: [Dots] Data Channel ACL fragments

 

[Jon2] The “flag= s->fragment” definition is ambiguous for an ACE (but valid as to w= hether to allow a packet to get fragmented or not – is that really a = ACE?) which I would like to use. 

 

[TR] I don’t get= it. What purpose does it serve to create a ACE rule using “fragment&= #8221; bit ?

[Jon3] Agreed – = This definition has not been thought through for an ACE.  I think they= have just emulated the DF bit in RFC791 as this general flags definition i= s the same as for the flags in RFC791.

 

[TR2] You may want to inform the authors of netmod-a= cl draft, surprisingly BGP flowspec also uses “fragment” bit.

[Jon4] On my ToDo list= for a clean solution.  But we do now have a solution – see belo= w.

 

 

“Flags->more&= #8221; definition covers all fragments but the last fragment. “Offset= ” is unfortunately not a range, but otherwise would get used for the = final fragment.

~jon2

 

[TR] It looks like two= ACE entries are required to drop all the fragments (“flags->more&= #8221; set to 1 in the first ACE and “flags->more” set to 0 = in the second ACE). How to use the “Offset”  field for the= final fragment ?

 

[Jon3] I read “f= lags-more” to refer to the IP_MF in the IP header (RFC791 MF or more-= fragments flag).  This is set for all fragments apart from the final (= as in last part of packet, not the order in which they are sent – fortunately that early decision to send them in the wrong= order was phased out, but still there in some legacy systems!)<= /span>

 

[TR2] Yes, why can’t “flags->moreR= 21; be set to 0 as one ACE entry to drop the final fragment along with R= 20;flags->more” set to 1 to drop the first fragment as another ACE= entry so as to drop all fragments to the target ?

[Jon4] If “flags= ->more” is configured and it is configured with a value of 0, this= will match not only the final fragment, but also a non-fragmented packet.&= nbsp; If “flags->more” is not configured, then this will match a non-fragmented packet only.

 

[TR3] net-mod-acl says "Setting the value to 0 = indicates this is the last fragment, and setting the value to 1 indicates m= ore fragments are coming.". I think it means, if “flags->more= ” is set to zero and offset is not zero then it indicates this is the last fragments; the flags can be used in isolation without com= paring if offset value is zero or non-zero. We should check with netmod-acl= authors for confirmation.

 

[Jon5].  The netm= od-acl text for flags and offset is effectively a word for word copy out of= RFC791 3.1 Internet Header Format.  So I think it is meant to be inte= rpreted as being an exact match for the same – including the offset specific value.

 

  Flags:  3 bits

 

    Various Control Flags.

 

      Bit 0: reserved, must be zero

      Bit 1: (DF) 0 =3D May Fragment, = 1 =3D Don't Fragment.

      Bit 2: (MF) 0 =3D Last Fragment, 1 = =3D More Fragments.

 

          0  = 1   2

        +---+---+---&= #43;

        |   | D | M |

        | 0 | F | F |<= /span>

        +---+---+---&= #43;

 

  Fragment Offset:  13 bits

 

    This field indicates where in the datagram this f= ragment belongs.

 

    The fragment offset is measured in units of 8 oct= ets (64 bits).  The

    first fragment has offset zero.=

 

 

----

 

Versus

 

----

    leaf flags {

      type bits {

        bit reserved {=

          position 0;

          description

            &= quot;Reserved. Must be zero.";

        }

        bit fragment {=

          position 1;

          description

            &= quot;Setting value to 0 indicates may fragment, while setting

           &n= bsp; the value to 1 indicates do not fragment.";

        }

        bit more {

          position 2;

          description

            &= quot;Setting the value to 0 indicates this is the last fragment,=

           &n= bsp; and setting the value to 1 indicates more fragments are

           &n= bsp; coming.";

        }

      }

      description

        "Bit definitions for= the flags field in IPv4 header.";

    }

 

    leaf offset {

      type uint16 {

        range "20..65535&quo= t;;

      }

 

      description

        "The fragment offset= is measured in units of 8 octets (64 bits).

         The first fragment = has offset zero. The length is 13 bits";

    }

 

[Jon4] So, a L4 ACE wi= thout “flags->more” defined and “allow”, followe= d by an ACE with “flags->more” =3D 1 and “drop”,= followed by an ACE with “flags->more” =3D 0 and “drop= ” will cause all fragmented packets to get dropped, but still allow through the non-fragmented packet.  So, we h= ave a solution for

“allow all traff= ic to port 53, but drop all fragmented packets”.

 

[TR3] I don’t think the above solution will wo= rk. In the above line, I think you  meant L3 ACE, and the first fragme= nt will match the first entry and is allowed.

 

[Jon5]No, the first AC= E is a L3/L4 match.  If you have (a1 allows through all non-fragmented= packets, a2 & a3 drops all fragmented packets) the following

 

[TR4] The first fragment will have both L3 and L4 in= formation, and matches a1 and is allowed, but if the order is changed to a3= , a1 and a2 (a3 will drop all fragments except last-fragment, the last frag= ment will not have L4 info, so will not match a1 but will match a2 and get dropped).

 

-Tiru

 

…

{

       "aces": [{=

           &n= bsp;            = ;             &= quot;ace": {

           &n= bsp;            = ;            &n= bsp;            = ;   "name": "a1",

           &n= bsp;            = ;            &n= bsp;            = ;   "matches": [{

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;     "ipv4": {

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;        "destination-network"= : "1.2.3.0/24"

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;     },

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;     "udp": {

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;        "destination-port": 5= 3

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;     }

           &n= bsp;            = ;            &n= bsp;            = ;   }],

           &n= bsp;            = ;            &n= bsp;            = ;   "actions": {

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;     "forwarding": "accept"

           &n= bsp;            = ;            &n= bsp;            = ;   }

           &n= bsp;            = ;             }=

           &n= bsp;          },

           &n= bsp;          {

           &n= bsp;            = ;             &= quot;ace": {

           &n= bsp;            = ;            &n= bsp;            = ;   "name": "a2",

           &n= bsp;            = ;            &n= bsp;            = ;   "matches": [{

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;     "ipv4": {

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;        "flags": {=

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;          "destinatio= n-network": "1.2.3.0/24",

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;          "more"= : 0

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;        },

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;        "udp": {

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;          "destinatio= n-port": 53

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;        }

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;     }

           &n= bsp;            = ;            &n= bsp;            = ;   }],

           &n= bsp;            = ;            &n= bsp;            = ;   "actions": {

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;     "forwarding": "drop"<= /o:p>

           &n= bsp;            = ;            &n= bsp;            = ;   }

 

           &n= bsp;            = ;             }=

           &n= bsp;          },

           &n= bsp;          {

           &n= bsp;            = ;             &= quot;ace": {

           &n= bsp;            = ;            &n= bsp;            = ;   "name": "a3",

           &n= bsp;            = ;            &n= bsp;            = ;   "matches": [{

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;     "ipv4": {

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;        "flags": {=

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;          "more"= : 1

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;        }

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;     }

           &n= bsp;            = ;            &n= bsp;            = ;   }],

           &n= bsp;            = ;            &n= bsp;            = ;   "actions": {

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;     "forwarding": "drop"<= /o:p>

           &n= bsp;            = ;            &n= bsp;            = ;   }

           &n= bsp;            = ;             }=

           &n= bsp;          }

       ]

}

…

[Jon5] It will work

 

-Tiru

 

~jon4

 

-Tiru

 

[Jon3] But as the fina= l fragment of the sequence could have any offset, the use of the offset fie= ld is not that helpful here.  Even if we do go with our DOTS fragments= definition (but widened to cover all fragments), we still cannot generate a netmod-acl entry for onward processing by an up= stream mitigator.

 

[Jon3] FYI, for Junipe= r, you just need to set ‘first-fragment’ and ‘is-fragment= ’ in their ACL.  BGP FlowSpec does support fragmentation detecti= on properly (RFC5575 Type 12 Fragment).

 

 

-Tiru

--_000_BN6PR16MB142519B30BC7F44E332B7077EAB30BN6PR16MB1425namp_-- From nobody Fri Apr 13 03:08:51 2018 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 C08361243FE for ; Fri, 13 Apr 2018 03:08:49 -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 aq6Scgatv7SH for ; Fri, 13 Apr 2018 03:08:47 -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 C525F120721 for ; Fri, 13 Apr 2018 03:08:46 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.90_1) (envelope-from ) id 1f6vdL-0006qS-S6; Fri, 13 Apr 2018 11:08:44 +0100 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , , References: <016401d3cc1c$03321200$09963600$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7F97@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <01a701d3cc29$ba915b10$2fb41130$@jpshallow.com> <007501d3ccc2$b49f0b00$1ddd2100$@jpshallow.com> <021301d3cfe7$77e5cbe0$67b163a0$@jpshallow.com> <02b001d3d048$a2c68be0$e853a3a0$@jpshallow.com> <000001d3d0ab$547dec40$fd79c4c0$@jpshallow.com> <007701d3d0bb$2404c330$6c0e4990$@jpshallow.com> <00a801d3d0c8$67315800$35940800$@jpshallow.com> In-Reply-To: Date: Fri, 13 Apr 2018 11:08:45 +0100 Message-ID: <00e901d3d30f$687eb1a0$397c14e0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00EA_01D3D317.CA48BEF0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEYhrWXRSNBek+fWBybzdJS41Z0KAI4GsKdAX18SvQDE9KikwNzyn9FAeCfBHcAmG/gMgGrGCDSAZ2/A+cCF5qWXQGy5AXbAg+JyVkByAAwbQHvg6xBAdFnBMICXX0TDaSHE8rg Content-Language: en-gb Archived-At: Subject: Re: [Dots] Data Channel ACL fragments 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, 13 Apr 2018 10:08:50 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00EA_01D3D317.CA48BEF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Tiru, See inline [Jon6] Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 13 April 2018 10:03 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] Data Channel ACL fragments Hi Jon, Please see inline [TR4] From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Konda@mcafee.com] Sent: 10 April 2018 07:10 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] Data Channel ACL fragments [Jon2] The "flags->fragment" definition is ambiguous for an ACE (but valid as to whether to allow a packet to get fragmented or not - is that really a ACE?) which I would like to use. [TR] I don't get it. What purpose does it serve to create a ACE rule using "fragment" bit ? [Jon3] Agreed - This definition has not been thought through for an ACE. I think they have just emulated the DF bit in RFC791 as this general flags definition is the same as for the flags in RFC791. [TR2] You may want to inform the authors of netmod-acl draft, surprisingly BGP flowspec also uses "fragment" bit. [Jon4] On my ToDo list for a clean solution. But we do now have a solution - see below. "Flags->more" definition covers all fragments but the last fragment. "Offset" is unfortunately not a range, but otherwise would get used for the final fragment. ~jon2 [TR] It looks like two ACE entries are required to drop all the fragments ("flags->more" set to 1 in the first ACE and "flags->more" set to 0 in the second ACE). How to use the "Offset" field for the final fragment ? [Jon3] I read "flags-more" to refer to the IP_MF in the IP header (RFC791 MF or more-fragments flag). This is set for all fragments apart from the final (as in last part of packet, not the order in which they are sent - fortunately that early decision to send them in the wrong order was phased out, but still there in some legacy systems!) [TR2] Yes, why can't "flags->more" be set to 0 as one ACE entry to drop the final fragment along with "flags->more" set to 1 to drop the first fragment as another ACE entry so as to drop all fragments to the target ? [Jon4] If "flags->more" is configured and it is configured with a value of 0, this will match not only the final fragment, but also a non-fragmented packet. If "flags->more" is not configured, then this will match a non-fragmented packet only. [TR3] net-mod-acl says "Setting the value to 0 indicates this is the last fragment, and setting the value to 1 indicates more fragments are coming.". I think it means, if "flags->more" is set to zero and offset is not zero then it indicates this is the last fragments; the flags can be used in isolation without comparing if offset value is zero or non-zero. We should check with netmod-acl authors for confirmation. [Jon5]. The netmod-acl text for flags and offset is effectively a word for word copy out of RFC791 3.1 Internet Header Format. So I think it is meant to be interpreted as being an exact match for the same - including the offset specific value. Flags: 3 bits Various Control Flags. Bit 0: reserved, must be zero Bit 1: (DF) 0 = May Fragment, 1 = Don't Fragment. Bit 2: (MF) 0 = Last Fragment, 1 = More Fragments. 0 1 2 +---+---+---+ | | D | M | | 0 | F | F | +---+---+---+ Fragment Offset: 13 bits This field indicates where in the datagram this fragment belongs. The fragment offset is measured in units of 8 octets (64 bits). The first fragment has offset zero. ---- Versus ---- leaf flags { type bits { bit reserved { position 0; description "Reserved. Must be zero."; } bit fragment { position 1; description "Setting value to 0 indicates may fragment, while setting the value to 1 indicates do not fragment."; } bit more { position 2; description "Setting the value to 0 indicates this is the last fragment, and setting the value to 1 indicates more fragments are coming."; } } description "Bit definitions for the flags field in IPv4 header."; } leaf offset { type uint16 { range "20..65535"; } description "The fragment offset is measured in units of 8 octets (64 bits). The first fragment has offset zero. The length is 13 bits"; } [Jon4] So, a L4 ACE without "flags->more" defined and "allow", followed by an ACE with "flags->more" = 1 and "drop", followed by an ACE with "flags->more" = 0 and "drop" will cause all fragmented packets to get dropped, but still allow through the non-fragmented packet. So, we have a solution for "allow all traffic to port 53, but drop all fragmented packets". [TR3] I don't think the above solution will work. In the above line, I think you meant L3 ACE, and the first fragment will match the first entry and is allowed. [Jon5]No, the first ACE is a L3/L4 match. If you have (a1 allows through all non-fragmented packets, a2 & a3 drops all fragmented packets) the following [TR4] The first fragment will have both L3 and L4 information, and matches a1 and is allowed, but if the order is changed to a3, a1 and a2 (a3 will drop all fragments except last-fragment, the last fragment will not have L4 info, so will not match a1 but will match a2 and get dropped). [Jon6] - Yes - I stand corrected, your ordering is correct. A2 no longer needs destination-port. ~jon6 -Tiru . { "aces": [{ "ace": { "name": "a1", "matches": [{ "ipv4": { "destination-network": "1.2.3.0/24" }, "udp": { "destination-port": 53 } }], "actions": { "forwarding": "accept" } } }, { "ace": { "name": "a2", "matches": [{ "ipv4": { "flags": { "destination-network": "1.2.3.0/24", "more": 0 }, "udp": { "destination-port": 53 } } }], "actions": { "forwarding": "drop" } } }, { "ace": { "name": "a3", "matches": [{ "ipv4": { "flags": { "more": 1 } } }], "actions": { "forwarding": "drop" } } } ] } . [Jon5] It will work -Tiru ~jon4 -Tiru [Jon3] But as the final fragment of the sequence could have any offset, the use of the offset field is not that helpful here. Even if we do go with our DOTS fragments definition (but widened to cover all fragments), we still cannot generate a netmod-acl entry for onward processing by an upstream mitigator. [Jon3] FYI, for Juniper, you just need to set 'first-fragment' and 'is-fragment' in their ACL. BGP FlowSpec does support fragmentation detection properly (RFC5575 Type 12 Fragment). -Tiru ------=_NextPart_000_00EA_01D3D317.CA48BEF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

See inline = [Jon6]

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = Konda, Tirumaleswar Reddy
Sent: 13 April 2018 = 10:03
To: Jon Shallow; mohamed.boucadair@orange.com; = dots@ietf.org
Subject: Re: [Dots] Data Channel ACL = fragments

 

Hi = Jon,

 

Please see inline [TR4]

 

 

From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Kond= a@mcafee.com]
Sent: 10 April 2018 07:10
To: Jon = Shallow; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: RE: = [Dots] Data Channel ACL fragments

 

[Jon2] The = “flags->fragment” definition is ambiguous for an ACE (but = valid as to whether to allow a packet to get fragmented or not – = is that really a ACE?) which I would like to use.  =

 

[TR] I = don’t get it. What purpose does it serve to create a ACE rule = using “fragment” bit ?

[Jon3] = Agreed – This definition has not been thought through for an = ACE.  I think they have just emulated the DF bit in RFC791 as this = general flags definition is the same as for the flags in = RFC791.

 

[TR2] You may want to inform the authors of netmod-acl = draft, surprisingly BGP flowspec also uses “fragment” = bit.

[Jon4] On = my ToDo list for a clean solution.  But we do now have a solution = – see below.

 

 

“Flags->more” definition covers = all fragments but the last fragment. “Offset” is = unfortunately not a range, but otherwise would get used for the final = fragment.

~jon2

 

[TR] It = looks like two ACE entries are required to drop all the fragments = (“flags->more” set to 1 in the first ACE and = “flags->more” set to 0 in the second ACE). How to use the = “Offset”  field for the final fragment = ?

 

[Jon3] I = read “flags-more” to refer to the IP_MF in the IP header = (RFC791 MF or more-fragments flag).  This is set for all fragments = apart from the final (as in last part of packet, not the order in which = they are sent – fortunately that early decision to send them in = the wrong order was phased out, but still there in some legacy = systems!)

 

[TR2] Yes, why can’t “flags->more” be = set to 0 as one ACE entry to drop the final fragment along with = “flags->more” set to 1 to drop the first fragment as = another ACE entry so as to drop all fragments to the target = ?

[Jon4] If “flags->more” is = configured and it is configured with a value of 0, this will match not = only the final fragment, but also a non-fragmented packet.  If = “flags->more” is not configured, then this will match a = non-fragmented packet only.

 

[TR3] net-mod-acl says = "Setting the value to 0 indicates this is the last fragment, and = setting the value to 1 indicates more fragments are coming.". I = think it means, if “flags->more” is set to zero and = offset is not zero then it indicates this is the last fragments; the = flags can be used in isolation without comparing if offset value is zero = or non-zero. We should check with netmod-acl authors for confirmation. =

 

[Jon5].  The netmod-acl text for flags and = offset is effectively a word for word copy out of RFC791 3.1 Internet = Header Format.  So I think it is meant to be interpreted as being = an exact match for the same – including the offset specific = value.

 

  Flags:  3 = bits

 

    Various Control = Flags.

 

      Bit 0: reserved, = must be zero

      Bit 1: (DF) 0 =3D = May Fragment,  1 =3D Don't Fragment.

      Bit 2: (MF) 0 =3D = Last Fragment, 1 =3D More Fragments.

 

        &= nbsp; 0   1   2

        = +---+---+---+

        = |   | D | M |

        | 0 | = F | F |

        = +---+---+---+

 

  Fragment Offset:  13 = bits

 

    This field indicates where in = the datagram this fragment belongs.

 

    The fragment offset is = measured in units of 8 octets (64 bits).  = The

    first fragment has offset = zero.

 

 

----

 

Versus

 

----

    leaf flags = {

      type bits = {

        bit = reserved {

        &= nbsp; position 0;

        &= nbsp; description

        &= nbsp;   "Reserved. Must be = zero.";

        = }

        bit = fragment {

        &= nbsp; position 1;

        &= nbsp; description

        &= nbsp;   "Setting value to 0 indicates may fragment, while = setting

        &= nbsp;    the value to 1 indicates do not = fragment.";

        = }

        bit = more {

        &= nbsp; position 2;

        &= nbsp; description

        &= nbsp;   "Setting the value to 0 indicates this is the = last fragment,

        &= nbsp;    and setting the value to 1 indicates more = fragments are

        &= nbsp;    coming.";

        = }

      = }

      = description

        = "Bit definitions for the flags field in IPv4 = header.";

    }

 

    leaf offset = {

      type uint16 = {

        range = "20..65535";

      = }

 

      = description

        = "The fragment offset is measured in units of 8 octets (64 = bits).

         = The first fragment has offset zero. The length is 13 = bits";

    }

 

[Jon4] So, = a L4 ACE without “flags->more” defined and = “allow”, followed by an ACE with = “flags->more” =3D 1 and “drop”, followed by = an ACE with “flags->more” =3D 0 and “drop” = will cause all fragmented packets to get dropped, but still allow = through the non-fragmented packet.  So, we have a solution = for

“allow all traffic to port 53, but drop = all fragmented packets”.

 

[TR3] I don’t think the above = solution will work. In the above line, I think you  meant L3 ACE, = and the first fragment will match the first entry and is allowed. =

 

[Jon5]No, = the first ACE is a L3/L4 match.  If you have (a1 allows through all = non-fragmented packets, a2 & a3 drops all fragmented packets) the = following

 

[TR4] The first fragment will have both L3 and L4 = information, and matches a1 and is allowed, but if the order is changed = to a3, a1 and a2 (a3 will drop all fragments except last-fragment, the = last fragment will not have L4 info, so will not match a1 but will match = a2 and get dropped).

 

[Jon6] = – Yes – I stand corrected, your ordering is correct.  = A2 no longer needs destination-port.

~jon6

 

-Tiru

 

…

{

       = "aces": [{

        &= nbsp;           &n= bsp;           &nb= sp;    "ace": {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       "name": = "a1",

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       "matches": = [{

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          = "ipv4": {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =              = "destination-network": = "1.2.3.0/24"

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          = },

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          "udp": = {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =              = "destination-port": 53

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          = }

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       }],

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       "actions": = {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          = "forwarding": "accept"

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       }

        &= nbsp;           &n= bsp;           &nb= sp;    }

        &= nbsp;           &n= bsp; },

        &= nbsp;           &n= bsp; {

        &= nbsp;           &n= bsp;           &nb= sp;    "ace": {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       "name": = "a2",

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       "matches": = [{

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          = "ipv4": {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =              = "flags": {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;   "destination-network": = "1.2.3.0/24",

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;   "more": 0

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =              = },

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =              = "udp": {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;   "destination-port": = 53

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =              = }

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          = }

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       }],

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       "actions": = {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          = "forwarding": "drop"

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       }

 

        &= nbsp;           &n= bsp;           &nb= sp;    }

        &= nbsp;           &n= bsp; },

        &= nbsp;           &n= bsp; {

        &= nbsp;           &n= bsp;           &nb= sp;    "ace": {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       "name": = "a3",

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       "matches": = [{

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          = "ipv4": {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =              = "flags": {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;   "more": 1

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =              = }

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          = }

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       }],

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       "actions": = {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          = "forwarding": "drop"

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       }

        &= nbsp;           &n= bsp;           &nb= sp;    }

        &= nbsp;           &n= bsp; }

       = ]

}

…

[Jon5] It = will work

 

-Tiru

 

~jon4

 

-Tiru

 

[Jon3] But = as the final fragment of the sequence could have any offset, the use of = the offset field is not that helpful here.  Even if we do go with = our DOTS fragments definition (but widened to cover all fragments), we = still cannot generate a netmod-acl entry for onward processing by an = upstream mitigator.

 

[Jon3] FYI, = for Juniper, you just need to set ‘first-fragment’ and = ‘is-fragment’ in their ACL.  BGP FlowSpec does support = fragmentation detection properly (RFC5575 Type 12 = Fragment).

 

 

-Tiru

------=_NextPart_000_00EA_01D3D317.CA48BEF0-- From nobody Fri Apr 13 05:25:03 2018 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 A16B51242F5 for ; Fri, 13 Apr 2018 05:25:01 -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, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-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 gATFjbVKflFg for ; Fri, 13 Apr 2018 05:24:59 -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 BCD9012420B for ; Fri, 13 Apr 2018 05:24:58 -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=1523622298; 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: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-microsoft-antispam: x-ms-traffictypediagnostic:x-microsoft-antispam-prvs: x-exchange-antispam-report-test:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Office365-Filtering-Correlation-Id: X-MS-Exchange-CrossTenant-Network-Message-Id: 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=A INDoxrQK9LwAdhUwKnVSTIfVfT+gxf0ibZLVYIjrf g=; b=C15CXI3lKxgiRVkb/pnH8lclUDNKw/IgDGRUieaTcjga AR8N4hEhHdE71oLkwMz9drs0/wMGaFoIKTX6AAdpFYaH7Wz/dW A7cpIsP+qLRIgUByhISdaIjhReZDkyk7Wrq5uB8A1nnbGq30TA AFPVE0+xXO9hF1cv2NOe8OxzMUo= Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 2776_4f6f_3d04240f_bb5d_4c89_8d55_401be55bc519; Fri, 13 Apr 2018 07:24:57 -0500 Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 13 Apr 2018 06:24:35 -0600 Received: from DNVEX10N01.corpzone.internalzone.com (10.44.82.192) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Fri, 13 Apr 2018 06:24:35 -0600 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEX10N01.corpzone.internalzone.com (10.44.82.192) with Microsoft SMTP Server (TLS) id 14.3.361.1; Fri, 13 Apr 2018 06:24:34 -0600 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (10.44.176.240) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 13 Apr 2018 06:24:33 -0600 Received: from BN6PR16MB1425.namprd16.prod.outlook.com (10.172.207.19) by BN6PR16MB1716.namprd16.prod.outlook.com (10.172.28.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.675.9; Fri, 13 Apr 2018 12:24:33 +0000 Received: from BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::4430:6104:630b:a067]) by BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::4430:6104:630b:a067%2]) with mapi id 15.20.0675.014; Fri, 13 Apr 2018 12:24:32 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: [Dots] Data Channel ACL fragments Thread-Index: AdPMHAMfDWFlXvb3TSeAr5MVkYUzIgAA3pEAAAKPJoAAIuTfcAADWaQAAADopUAAyEgtgAACNjegABYTlwAAEYzK0AAHIEOAAAC6rLAAAzlEAAAAT7KgAAMBYAAAjfWr8AADyrCAAAQ1fKA= Date: Fri, 13 Apr 2018 12:24:32 +0000 Message-ID: References: <016401d3cc1c$03321200$09963600$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7F97@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <01a701d3cc29$ba915b10$2fb41130$@jpshallow.com> <007501d3ccc2$b49f0b00$1ddd2100$@jpshallow.com> <021301d3cfe7$77e5cbe0$67b163a0$@jpshallow.com> <02b001d3d048$a2c68be0$e853a3a0$@jpshallow.com> <000001d3d0ab$547dec40$fd79c4c0$@jpshallow.com> <007701d3d0bb$2404c330$6c0e4990$@jpshallow.com> <00a801d3d0c8$67315800$35940800$@jpshallow.com> <00e901d3d30f$687eb1a0$397c14e0$@jpshallow.com> In-Reply-To: <00e901d3d30f$687eb1a0$397c14e0$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR16MB1716; 7:RTbd6bbkkbP4ujBfnmm5XQBftKSzT7ovH7HG2yBF+D44bgrQ6uICbkw4gXiArgJ5oCin75X5FjfgIdV7tmtxI1FVrZDGvXWzAgOxLQprcoHeL2AfWclt974ssU+8KYk23/YkC0ZhWRUYzKa6lWfvFGxWkWgi8ae7Ply98b3o2I7Igxzyn4UNgsg+/t3w9fiD/hnfM9CGKhJjJq7k7kVN2qkNAHWCzQzdaUu1XuR/5Wb5rCqssQW+qtJhWxA1WLwI x-ms-exchange-antispam-srfa-diagnostics: SOS; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BN6PR16MB1716; x-ms-traffictypediagnostic: BN6PR16MB1716: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(18271650672692)(21748063052155)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3231232)(944501327)(52105095)(93006095)(93001095)(3002001)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(20161123560045)(20161123558120)(6072148)(201708071742011); SRVR:BN6PR16MB1716; BCL:0; PCL:0; RULEID:; SRVR:BN6PR16MB1716; x-forefront-prvs: 0641678E68 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(396003)(346002)(376002)(39380400002)(189003)(199004)(69234005)(32952001)(486006)(11346002)(446003)(81156014)(81166006)(97736004)(5250100002)(8676002)(476003)(80792005)(2501003)(6436002)(2900100001)(54896002)(25786009)(186003)(19609705001)(106356001)(86362001)(53946003)(6306002)(9686003)(236005)(110136005)(6246003)(8936002)(55016002)(53936002)(2201001)(316002)(99286004)(7696005)(14454004)(478600001)(72206003)(33656002)(66066001)(3660700001)(229853002)(102836004)(105586002)(5660300001)(26005)(76176011)(74316002)(68736007)(7736002)(790700001)(6116002)(3846002)(6506007)(2906002)(59450400001)(3280700002)(93886005)(53546011)(85282002)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR16MB1716; H:BN6PR16MB1425.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: IZg1BqmkZ6FmRD3jncfKSgmIQBuz0QDEHNaAR86yml6eSVRu/LSH0NlQIXCWzkqjngNgjmfd68veC+gBFYyrrdH9VbTo3bWIQ571fbYYkPDTKp937fdqSnCUBL+Lh/YOTxL3zhVwHhrZq1IPFAEEtwJFeCksEFY9qf5NonMtGgFP1pKy89HK3dp4w4cf5EqnW2iygzSsCbXYFeo1dEAc8A== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR16MB1425DFC5475D456042FD6F11EAB30BN6PR16MB1425namp_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 396e64fa-37ec-4df3-fe6e-08d5a1398331 X-MS-Exchange-CrossTenant-Network-Message-Id: 396e64fa-37ec-4df3-fe6e-08d5a1398331 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Apr 2018 12:24:32.7217 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR16MB1716 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 <6264> : inlines <6559> : streams <1783905> : uri <2624806> Archived-At: Subject: Re: [Dots] Data Channel ACL fragments 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, 13 Apr 2018 12:25:01 -0000 --_000_BN6PR16MB1425DFC5475D456042FD6F11EAB30BN6PR16MB1425namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [Jon6] - Yes - I stand corrected, your ordering is correct. A2 no longer n= eeds destination-port. Yup. The summary of our discussion is to use the flags defined in netmod-ac= l-model to drop fragments (both initial and non-initial), and v4-fragments = and v6-fragments and the associated text added to drop non-initial fragment= s discussed in Section 4.1 will be removed from the draft. Cheers -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Friday, April 13, 2018 3:39 PM To: Konda, Tirumaleswar Reddy ; mohamed= .boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] Data Channel ACL fragments Hi Tiru, See inline [Jon6] Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 13 April 2018 10:03 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] Data Channel ACL fragments Hi Jon, Please see inline [TR4] From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Konda@mcafee.com= ] Sent: 10 April 2018 07:10 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] Data Channel ACL fragments [Jon2] The "flags->fragment" definition is ambiguous for an ACE (but valid = as to whether to allow a packet to get fragmented or not - is that really a= ACE?) which I would like to use. [TR] I don't get it. What purpose does it serve to create a ACE rule using = "fragment" bit ? [Jon3] Agreed - This definition has not been thought through for an ACE. I= think they have just emulated the DF bit in RFC791 as this general flags d= efinition is the same as for the flags in RFC791. [TR2] You may want to inform the authors of netmod-acl draft, surprisingly = BGP flowspec also uses "fragment" bit. [Jon4] On my ToDo list for a clean solution. But we do now have a solution= - see below. "Flags->more" definition covers all fragments but the last fragment. "Offse= t" is unfortunately not a range, but otherwise would get used for the final= fragment. ~jon2 [TR] It looks like two ACE entries are required to drop all the fragments (= "flags->more" set to 1 in the first ACE and "flags->more" set to 0 in the s= econd ACE). How to use the "Offset" field for the final fragment ? [Jon3] I read "flags-more" to refer to the IP_MF in the IP header (RFC791 M= F or more-fragments flag). This is set for all fragments apart from the fi= nal (as in last part of packet, not the order in which they are sent - fort= unately that early decision to send them in the wrong order was phased out,= but still there in some legacy systems!) [TR2] Yes, why can't "flags->more" be set to 0 as one ACE entry to drop the= final fragment along with "flags->more" set to 1 to drop the first fragmen= t as another ACE entry so as to drop all fragments to the target ? [Jon4] If "flags->more" is configured and it is configured with a value of = 0, this will match not only the final fragment, but also a non-fragmented p= acket. If "flags->more" is not configured, then this will match a non-frag= mented packet only. [TR3] net-mod-acl says "Setting the value to 0 indicates this is the last f= ragment, and setting the value to 1 indicates more fragments are coming.". = I think it means, if "flags->more" is set to zero and offset is not zero th= en it indicates this is the last fragments; the flags can be used in isolat= ion without comparing if offset value is zero or non-zero. We should check = with netmod-acl authors for confirmation. [Jon5]. The netmod-acl text for flags and offset is effectively a word for= word copy out of RFC791 3.1 Internet Header Format. So I think it is mean= t to be interpreted as being an exact match for the same - including the of= fset specific value. Flags: 3 bits Various Control Flags. Bit 0: reserved, must be zero Bit 1: (DF) 0 =3D May Fragment, 1 =3D Don't Fragment. Bit 2: (MF) 0 =3D Last Fragment, 1 =3D More Fragments. 0 1 2 +---+---+---+ | | D | M | | 0 | F | F | +---+---+---+ Fragment Offset: 13 bits This field indicates where in the datagram this fragment belongs. The fragment offset is measured in units of 8 octets (64 bits). The first fragment has offset zero. ---- Versus ---- leaf flags { type bits { bit reserved { position 0; description "Reserved. Must be zero."; } bit fragment { position 1; description "Setting value to 0 indicates may fragment, while setting the value to 1 indicates do not fragment."; } bit more { position 2; description "Setting the value to 0 indicates this is the last fragment, and setting the value to 1 indicates more fragments are coming."; } } description "Bit definitions for the flags field in IPv4 header."; } leaf offset { type uint16 { range "20..65535"; } description "The fragment offset is measured in units of 8 octets (64 bits). The first fragment has offset zero. The length is 13 bits"; } [Jon4] So, a L4 ACE without "flags->more" defined and "allow", followed by = an ACE with "flags->more" =3D 1 and "drop", followed by an ACE with "flags-= >more" =3D 0 and "drop" will cause all fragmented packets to get dropped, b= ut still allow through the non-fragmented packet. So, we have a solution f= or "allow all traffic to port 53, but drop all fragmented packets". [TR3] I don't think the above solution will work. In the above line, I thin= k you meant L3 ACE, and the first fragment will match the first entry and = is allowed. [Jon5]No, the first ACE is a L3/L4 match. If you have (a1 allows through a= ll non-fragmented packets, a2 & a3 drops all fragmented packets) the follow= ing [TR4] The first fragment will have both L3 and L4 information, and matches = a1 and is allowed, but if the order is changed to a3, a1 and a2 (a3 will dr= op all fragments except last-fragment, the last fragment will not have L4 i= nfo, so will not match a1 but will match a2 and get dropped). [Jon6] - Yes - I stand corrected, your ordering is correct. A2 no longer n= eeds destination-port. ~jon6 -Tiru ... { "aces": [{ "ace": { "name": "a1", "matches": [{ "ipv4": = { = "destination-network": "1.2.3.0/24" }, "udp": { = "destination-port": 53 } }], "actions": { "forward= ing": "accept" } } }, { "ace": { "name": "a2", "matches": [{ "ipv4": = { = "flags": { = "destination-network": "1.2.3.0/24", = "more": 0 = }, = "udp": { = "destination-port": 53 = } } }], "actions": { "forward= ing": "drop" } } }, { "ace": { "name": "a3", "matches": [{ "ipv4": = { = "flags": { = "more": 1 = } } }], "actions": { "forward= ing": "drop" } } } ] } ... [Jon5] It will work -Tiru ~jon4 -Tiru [Jon3] But as the final fragment of the sequence could have any offset, the= use of the offset field is not that helpful here. Even if we do go with o= ur DOTS fragments definition (but widened to cover all fragments), we still= cannot generate a netmod-acl entry for onward processing by an upstream mi= tigator. [Jon3] FYI, for Juniper, you just need to set 'first-fragment' and 'is-frag= ment' in their ACL. BGP FlowSpec does support fragmentation detection prop= erly (RFC5575 Type 12 Fragment). -Tiru --_000_BN6PR16MB1425DFC5475D456042FD6F11EAB30BN6PR16MB1425namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

[Jon6] – Yes = 211; I stand corrected, your ordering is correct.  A2 no longer needs = destination-port.

&nbs= p;

Yup. The = summary of our discussion is to use the flags defined in netmod-acl-model t= o drop fragments (both initial and non-initial), and v4-fragments and v6-fr= agments and the associated text added to drop non-initial fragments discussed in Section 4.1 will be removed fro= m the draft.

&nbs= p;

Cheers

-Tiru

 

From:<= /span> Jon Shallow [mailto:s= upjps-ietf@jpshallow.com]
Sent: Friday, April 13, 2018 3:39 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; mohamed.boucadair@orange.com; dots@ietf.org
Subject: RE: [Dots] Data Channel ACL fragments

 

Hi Tiru= ,

&n= bsp;

See inl= ine [Jon6]

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 13 April 2018 10:03
To: Jon Shallow; moh= amed.boucadair@orange.com; dots@ietf.org
Subject: Re: [Dots] Data Channel ACL fragments

 

Hi Jon,

&nbs= p;

Please se= e inline [TR4]

&nbs= p;

&n= bsp;

From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Kon= da@mcafee.com]
Sent: 10 April 2018 07:10
To: Jon Shallow; moh= amed.boucadair@orange.com; dots@ietf.org
Subject: RE: [Dots] Data Channel ACL fragments

 

[Jon2] The “flag= s->fragment” definition is ambiguous for an ACE (but valid as to w= hether to allow a packet to get fragmented or not – is that really a = ACE?) which I would like to use. 

 

[TR] I don’t get= it. What purpose does it serve to create a ACE rule using “fragment&= #8221; bit ?

[Jon3] Agreed – = This definition has not been thought through for an ACE.  I think they= have just emulated the DF bit in RFC791 as this general flags definition i= s the same as for the flags in RFC791.

 

[TR2] You may want to inform the authors of netmod-a= cl draft, surprisingly BGP flowspec also uses “fragment” bit.

[Jon4] On my ToDo list= for a clean solution.  But we do now have a solution – see belo= w.

 

 

“Flags->more&= #8221; definition covers all fragments but the last fragment. “Offset= ” is unfortunately not a range, but otherwise would get used for the = final fragment.

~jon2

 

[TR] It looks like two= ACE entries are required to drop all the fragments (“flags->more&= #8221; set to 1 in the first ACE and “flags->more” set to 0 = in the second ACE). How to use the “Offset”  field for the= final fragment ?

 

[Jon3] I read “f= lags-more” to refer to the IP_MF in the IP header (RFC791 MF or more-= fragments flag).  This is set for all fragments apart from the final (= as in last part of packet, not the order in which they are sent – fortunately that early decision to send them in the wrong= order was phased out, but still there in some legacy systems!)<= /span>

 

[TR2] Yes, why can’t “flags->moreR= 21; be set to 0 as one ACE entry to drop the final fragment along with R= 20;flags->more” set to 1 to drop the first fragment as another ACE= entry so as to drop all fragments to the target ?

[Jon4] If “flags= ->more” is configured and it is configured with a value of 0, this= will match not only the final fragment, but also a non-fragmented packet.&= nbsp; If “flags->more” is not configured, then this will match a non-fragmented packet only.

 

[TR3] net-mod-acl says "Setting the value to 0 = indicates this is the last fragment, and setting the value to 1 indicates m= ore fragments are coming.". I think it means, if “flags->more= ” is set to zero and offset is not zero then it indicates this is the last fragments; the flags can be used in isolation without com= paring if offset value is zero or non-zero. We should check with netmod-acl= authors for confirmation.

 

[Jon5].  The netm= od-acl text for flags and offset is effectively a word for word copy out of= RFC791 3.1 Internet Header Format.  So I think it is meant to be inte= rpreted as being an exact match for the same – including the offset specific value.

 

  Flags:  3 bits

 

    Various Control Flags.

 

      Bit 0: reserved, must be zero

      Bit 1: (DF) 0 =3D May Fragment, = 1 =3D Don't Fragment.

      Bit 2: (MF) 0 =3D Last Fragment, 1 = =3D More Fragments.

 

          0  = 1   2

        +---+---+---&= #43;

        |   | D | M |

        | 0 | F | F |<= /span>

        +---+---+---&= #43;

 

  Fragment Offset:  13 bits

 

    This field indicates where in the datagram this f= ragment belongs.

 

    The fragment offset is measured in units of 8 oct= ets (64 bits).  The

    first fragment has offset zero.=

 

 

----

 

Versus

 

----

    leaf flags {

      type bits {

        bit reserved {=

          position 0;

          description

            &= quot;Reserved. Must be zero.";

        }

        bit fragment {=

          position 1;

          description

            &= quot;Setting value to 0 indicates may fragment, while setting

           &n= bsp; the value to 1 indicates do not fragment.";

        }

        bit more {

          position 2;

          description

            &= quot;Setting the value to 0 indicates this is the last fragment,=

           &n= bsp; and setting the value to 1 indicates more fragments are

           &n= bsp; coming.";

        }

      }

      description

        "Bit definitions for= the flags field in IPv4 header.";

    }

 

    leaf offset {

      type uint16 {

        range "20..65535&quo= t;;

      }

 

      description

        "The fragment offset= is measured in units of 8 octets (64 bits).

         The first fragment = has offset zero. The length is 13 bits";

    }

 

[Jon4] So, a L4 ACE wi= thout “flags->more” defined and “allow”, followe= d by an ACE with “flags->more” =3D 1 and “drop”,= followed by an ACE with “flags->more” =3D 0 and “drop= ” will cause all fragmented packets to get dropped, but still allow through the non-fragmented packet.  So, we h= ave a solution for

“allow all traff= ic to port 53, but drop all fragmented packets”.

 

[TR3] I don’t think the above solution will wo= rk. In the above line, I think you  meant L3 ACE, and the first fragme= nt will match the first entry and is allowed.

 

[Jon5]No, the first AC= E is a L3/L4 match.  If you have (a1 allows through all non-fragmented= packets, a2 & a3 drops all fragmented packets) the following

 

[TR4] The first fragment will have both L3 and L4 in= formation, and matches a1 and is allowed, but if the order is changed to a3= , a1 and a2 (a3 will drop all fragments except last-fragment, the last frag= ment will not have L4 info, so will not match a1 but will match a2 and get dropped).

 

[Jon6] – Yes = 211; I stand corrected, your ordering is correct.  A2 no longer needs = destination-port.

~jon6

 

-Tiru

 

…

{

       "aces": [{=

           &n= bsp;            = ;             &= quot;ace": {

           &n= bsp;            = ;            &n= bsp;            = ;   "name": "a1",

           &n= bsp;            = ;            &n= bsp;            = ;   "matches": [{

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;     "ipv4": {

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;        "destination-network"= : "1.2.3.0/24"

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;     },

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;     "udp": {

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;        "destination-port": 5= 3

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;     }

           &n= bsp;            = ;            &n= bsp;            = ;   }],

           &n= bsp;            = ;            &n= bsp;            = ;   "actions": {

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;     "forwarding": "accept"

           &n= bsp;            = ;            &n= bsp;            = ;   }

           &n= bsp;            = ;             }=

           &n= bsp;          },

           &n= bsp;          {

           &n= bsp;            = ;             &= quot;ace": {

           &n= bsp;            = ;            &n= bsp;            = ;   "name": "a2",

           &n= bsp;            = ;            &n= bsp;            = ;   "matches": [{

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;     "ipv4": {

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;        "flags": {=

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;          "destinatio= n-network": "1.2.3.0/24",

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;          "more"= : 0

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;        },

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;        "udp": {

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;          "destinatio= n-port": 53

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;        }

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;     }

           &n= bsp;            = ;            &n= bsp;            = ;   }],

           &n= bsp;            = ;            &n= bsp;            = ;   "actions": {

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;     "forwarding": "drop"<= /o:p>

           &n= bsp;            = ;            &n= bsp;            = ;   }

 

           &n= bsp;            = ;             }=

           &n= bsp;          },

           &n= bsp;          {

           &n= bsp;            = ;             &= quot;ace": {

           &n= bsp;            = ;            &n= bsp;            = ;   "name": "a3",

           &n= bsp;            = ;            &n= bsp;            = ;   "matches": [{

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;     "ipv4": {

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;        "flags": {=

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;          "more"= : 1

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;        }

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;     }

           &n= bsp;            = ;            &n= bsp;            = ;   }],

           &n= bsp;            = ;            &n= bsp;            = ;   "actions": {

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;     "forwarding": "drop"<= /o:p>

           &n= bsp;            = ;            &n= bsp;            = ;   }

           &n= bsp;            = ;             }=

           &n= bsp;          }

       ]

}

…

[Jon5] It will work

 

-Tiru

 

~jon4

 

-Tiru

 

[Jon3] But as the fina= l fragment of the sequence could have any offset, the use of the offset fie= ld is not that helpful here.  Even if we do go with our DOTS fragments= definition (but widened to cover all fragments), we still cannot generate a netmod-acl entry for onward processing by an up= stream mitigator.

 

[Jon3] FYI, for Junipe= r, you just need to set ‘first-fragment’ and ‘is-fragment= ’ in their ACL.  BGP FlowSpec does support fragmentation detecti= on properly (RFC5575 Type 12 Fragment).

 

 

-Tiru

--_000_BN6PR16MB1425DFC5475D456042FD6F11EAB30BN6PR16MB1425namp_-- From nobody Fri Apr 13 05:29:38 2018 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 1ABE6127078 for ; Fri, 13 Apr 2018 05:29:37 -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 DScd53oVHMj1 for ; Fri, 13 Apr 2018 05:29:34 -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 07E8112420B for ; Fri, 13 Apr 2018 05:29:34 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.90_1) (envelope-from ) id 1f6xpc-0006w0-8V; Fri, 13 Apr 2018 13:29:32 +0100 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , , References: <016401d3cc1c$03321200$09963600$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7F97@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <01a701d3cc29$ba915b10$2fb41130$@jpshallow.com> <007501d3ccc2$b49f0b00$1ddd2100$@jpshallow.com> <021301d3cfe7$77e5cbe0$67b163a0$@jpshallow.com> <02b001d3d048$a2c68be0$e853a3a0$@jpshallow.com> <000001d3d0ab$547dec40$fd79c4c0$@jpshallow.com> <007701d3d0bb$2404c330$6c0e4990$@jpshallow.com> <00a801d3d0c8$67315800$35940800$@jpshallow.com> <00e901d3d30f$687eb1a0$397c14e0$@jpshallow.com> In-Reply-To: Date: Fri, 13 Apr 2018 13:29:33 +0100 Message-ID: <013201d3d323$141409d0$3c3c1d70$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0133_01D3D32B.75DEDA70" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEYhrWXRSNBek+fWBybzdJS41Z0KAI4GsKdAX18SvQDE9KikwNzyn9FAeCfBHcAmG/gMgGrGCDSAZ2/A+cCF5qWXQGy5AXbAg+JyVkByAAwbQHvg6xBAdFnBMIC/mI4iQC6rlcwA1dFhlmkYaSr0A== Content-Language: en-gb Archived-At: Subject: Re: [Dots] Data Channel ACL fragments 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, 13 Apr 2018 12:29:37 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0133_01D3D32B.75DEDA70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Tiru, Thanks. I think that we do need an example in the draft of how to do this though.. IPv6 will not be using flags, but looking instead for the next header of protocol 44. Regards Jon From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 13 April 2018 13:25 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] Data Channel ACL fragments [Jon6] - Yes - I stand corrected, your ordering is correct. A2 no longer needs destination-port. Yup. The summary of our discussion is to use the flags defined in netmod-acl-model to drop fragments (both initial and non-initial), and v4-fragments and v6-fragments and the associated text added to drop non-initial fragments discussed in Section 4.1 will be removed from the draft. Cheers -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Friday, April 13, 2018 3:39 PM To: Konda, Tirumaleswar Reddy ; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] Data Channel ACL fragments Hi Tiru, See inline [Jon6] Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 13 April 2018 10:03 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] Data Channel ACL fragments Hi Jon, Please see inline [TR4] From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Konda@mcafee.com] Sent: 10 April 2018 07:10 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] Data Channel ACL fragments [Jon2] The "flags->fragment" definition is ambiguous for an ACE (but valid as to whether to allow a packet to get fragmented or not - is that really a ACE?) which I would like to use. [TR] I don't get it. What purpose does it serve to create a ACE rule using "fragment" bit ? [Jon3] Agreed - This definition has not been thought through for an ACE. I think they have just emulated the DF bit in RFC791 as this general flags definition is the same as for the flags in RFC791. [TR2] You may want to inform the authors of netmod-acl draft, surprisingly BGP flowspec also uses "fragment" bit. [Jon4] On my ToDo list for a clean solution. But we do now have a solution - see below. "Flags->more" definition covers all fragments but the last fragment. "Offset" is unfortunately not a range, but otherwise would get used for the final fragment. ~jon2 [TR] It looks like two ACE entries are required to drop all the fragments ("flags->more" set to 1 in the first ACE and "flags->more" set to 0 in the second ACE). How to use the "Offset" field for the final fragment ? [Jon3] I read "flags-more" to refer to the IP_MF in the IP header (RFC791 MF or more-fragments flag). This is set for all fragments apart from the final (as in last part of packet, not the order in which they are sent - fortunately that early decision to send them in the wrong order was phased out, but still there in some legacy systems!) [TR2] Yes, why can't "flags->more" be set to 0 as one ACE entry to drop the final fragment along with "flags->more" set to 1 to drop the first fragment as another ACE entry so as to drop all fragments to the target ? [Jon4] If "flags->more" is configured and it is configured with a value of 0, this will match not only the final fragment, but also a non-fragmented packet. If "flags->more" is not configured, then this will match a non-fragmented packet only. [TR3] net-mod-acl says "Setting the value to 0 indicates this is the last fragment, and setting the value to 1 indicates more fragments are coming.". I think it means, if "flags->more" is set to zero and offset is not zero then it indicates this is the last fragments; the flags can be used in isolation without comparing if offset value is zero or non-zero. We should check with netmod-acl authors for confirmation. [Jon5]. The netmod-acl text for flags and offset is effectively a word for word copy out of RFC791 3.1 Internet Header Format. So I think it is meant to be interpreted as being an exact match for the same - including the offset specific value. Flags: 3 bits Various Control Flags. Bit 0: reserved, must be zero Bit 1: (DF) 0 = May Fragment, 1 = Don't Fragment. Bit 2: (MF) 0 = Last Fragment, 1 = More Fragments. 0 1 2 +---+---+---+ | | D | M | | 0 | F | F | +---+---+---+ Fragment Offset: 13 bits This field indicates where in the datagram this fragment belongs. The fragment offset is measured in units of 8 octets (64 bits). The first fragment has offset zero. ---- Versus ---- leaf flags { type bits { bit reserved { position 0; description "Reserved. Must be zero."; } bit fragment { position 1; description "Setting value to 0 indicates may fragment, while setting the value to 1 indicates do not fragment."; } bit more { position 2; description "Setting the value to 0 indicates this is the last fragment, and setting the value to 1 indicates more fragments are coming."; } } description "Bit definitions for the flags field in IPv4 header."; } leaf offset { type uint16 { range "20..65535"; } description "The fragment offset is measured in units of 8 octets (64 bits). The first fragment has offset zero. The length is 13 bits"; } [Jon4] So, a L4 ACE without "flags->more" defined and "allow", followed by an ACE with "flags->more" = 1 and "drop", followed by an ACE with "flags->more" = 0 and "drop" will cause all fragmented packets to get dropped, but still allow through the non-fragmented packet. So, we have a solution for "allow all traffic to port 53, but drop all fragmented packets". [TR3] I don't think the above solution will work. In the above line, I think you meant L3 ACE, and the first fragment will match the first entry and is allowed. [Jon5]No, the first ACE is a L3/L4 match. If you have (a1 allows through all non-fragmented packets, a2 & a3 drops all fragmented packets) the following [TR4] The first fragment will have both L3 and L4 information, and matches a1 and is allowed, but if the order is changed to a3, a1 and a2 (a3 will drop all fragments except last-fragment, the last fragment will not have L4 info, so will not match a1 but will match a2 and get dropped). [Jon6] - Yes - I stand corrected, your ordering is correct. A2 no longer needs destination-port. ~jon6 -Tiru . { "aces": [{ "ace": { "name": "a1", "matches": [{ "ipv4": { "destination-network": "1.2.3.0/24" }, "udp": { "destination-port": 53 } }], "actions": { "forwarding": "accept" } } }, { "ace": { "name": "a2", "matches": [{ "ipv4": { "flags": { "destination-network": "1.2.3.0/24", "more": 0 }, "udp": { "destination-port": 53 } } }], "actions": { "forwarding": "drop" } } }, { "ace": { "name": "a3", "matches": [{ "ipv4": { "flags": { "more": 1 } } }], "actions": { "forwarding": "drop" } } } ] } . [Jon5] It will work -Tiru ~jon4 -Tiru [Jon3] But as the final fragment of the sequence could have any offset, the use of the offset field is not that helpful here. Even if we do go with our DOTS fragments definition (but widened to cover all fragments), we still cannot generate a netmod-acl entry for onward processing by an upstream mitigator. [Jon3] FYI, for Juniper, you just need to set 'first-fragment' and 'is-fragment' in their ACL. BGP FlowSpec does support fragmentation detection properly (RFC5575 Type 12 Fragment). -Tiru ------=_NextPart_000_0133_01D3D32B.75DEDA70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

Thanks.

 

I think that we do need = an example in the draft of how to do this = though….

 

IPv6 will not be using = flags, but looking instead for the next header of protocol = 44.

 

Regards

 

Jon

 

From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 13 April 2018 = 13:25
To: Jon Shallow; mohamed.boucadair@orange.com; = dots@ietf.org
Subject: Re: [Dots] Data Channel ACL = fragments

 

[Jon6] – Yes – I stand = corrected, your ordering is correct.  A2 no longer needs = destination-port.

 

Yup. The summary of our discussion = is to use the flags defined in netmod-acl-model to drop fragments (both = initial and non-initial), and v4-fragments and v6-fragments and the = associated text added to drop non-initial fragments discussed in Section = 4.1 will be removed from the draft.

 

Cheers

-Tiru

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Friday, April 13, 2018 3:39 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: RE: = [Dots] Data Channel ACL fragments

 

Hi = Tiru,

 

See inline = [Jon6]

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 13 April 2018 = 10:03
To: Jon Shallow; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: Re: = [Dots] Data Channel ACL fragments

 

Hi = Jon,

 

Please see inline [TR4]

 

 

From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Kond= a@mcafee.com]
Sent: 10 April 2018 07:10
To: Jon = Shallow; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: RE: = [Dots] Data Channel ACL fragments

 

[Jon2] The = “flags->fragment” definition is ambiguous for an ACE (but = valid as to whether to allow a packet to get fragmented or not – = is that really a ACE?) which I would like to use.  =

 

[TR] I = don’t get it. What purpose does it serve to create a ACE rule = using “fragment” bit ?

[Jon3] = Agreed – This definition has not been thought through for an = ACE.  I think they have just emulated the DF bit in RFC791 as this = general flags definition is the same as for the flags in = RFC791.

 

[TR2] You may want to inform the authors of netmod-acl = draft, surprisingly BGP flowspec also uses “fragment” = bit.

[Jon4] On = my ToDo list for a clean solution.  But we do now have a solution = – see below.

 

 

“Flags->more” definition covers = all fragments but the last fragment. “Offset” is = unfortunately not a range, but otherwise would get used for the final = fragment.

~jon2

 

[TR] It = looks like two ACE entries are required to drop all the fragments = (“flags->more” set to 1 in the first ACE and = “flags->more” set to 0 in the second ACE). How to use the = “Offset”  field for the final fragment = ?

 

[Jon3] I = read “flags-more” to refer to the IP_MF in the IP header = (RFC791 MF or more-fragments flag).  This is set for all fragments = apart from the final (as in last part of packet, not the order in which = they are sent – fortunately that early decision to send them in = the wrong order was phased out, but still there in some legacy = systems!)

 

[TR2] Yes, why can’t “flags->more” be = set to 0 as one ACE entry to drop the final fragment along with = “flags->more” set to 1 to drop the first fragment as = another ACE entry so as to drop all fragments to the target = ?

[Jon4] If “flags->more” is = configured and it is configured with a value of 0, this will match not = only the final fragment, but also a non-fragmented packet.  If = “flags->more” is not configured, then this will match a = non-fragmented packet only.

 

[TR3] net-mod-acl says = "Setting the value to 0 indicates this is the last fragment, and = setting the value to 1 indicates more fragments are coming.". I = think it means, if “flags->more” is set to zero and = offset is not zero then it indicates this is the last fragments; the = flags can be used in isolation without comparing if offset value is zero = or non-zero. We should check with netmod-acl authors for confirmation. =

 

[Jon5].  The netmod-acl text for flags and = offset is effectively a word for word copy out of RFC791 3.1 Internet = Header Format.  So I think it is meant to be interpreted as being = an exact match for the same – including the offset specific = value.

 

  Flags:  3 = bits

 

    Various Control = Flags.

 

      Bit 0: reserved, = must be zero

      Bit 1: (DF) 0 =3D = May Fragment,  1 =3D Don't Fragment.

      Bit 2: (MF) 0 =3D = Last Fragment, 1 =3D More Fragments.

 

        &= nbsp; 0   1   2

        = +---+---+---+

        = |   | D | M |

        | 0 | = F | F |

        = +---+---+---+

 

  Fragment Offset:  13 = bits

 

    This field indicates where in = the datagram this fragment belongs.

 

    The fragment offset is = measured in units of 8 octets (64 bits).  = The

    first fragment has offset = zero.

 

 

----

 

Versus

 

----

    leaf flags = {

      type bits = {

        bit = reserved {

        &= nbsp; position 0;

        &= nbsp; description

        &= nbsp;   "Reserved. Must be = zero.";

        = }

        bit = fragment {

        &= nbsp; position 1;

        &= nbsp; description

        &= nbsp;   "Setting value to 0 indicates may fragment, while = setting

        &= nbsp;    the value to 1 indicates do not = fragment.";

        = }

        bit = more {

        &= nbsp; position 2;

        &= nbsp; description

        &= nbsp;   "Setting the value to 0 indicates this is the = last fragment,

        &= nbsp;    and setting the value to 1 indicates more = fragments are

        &= nbsp;    coming.";

        = }

      = }

      = description

        = "Bit definitions for the flags field in IPv4 = header.";

    }

 

    leaf offset = {

      type uint16 = {

        range = "20..65535";

      = }

 

      = description

        = "The fragment offset is measured in units of 8 octets (64 = bits).

         = The first fragment has offset zero. The length is 13 = bits";

    }

 

[Jon4] So, = a L4 ACE without “flags->more” defined and = “allow”, followed by an ACE with = “flags->more” =3D 1 and “drop”, followed by = an ACE with “flags->more” =3D 0 and “drop” = will cause all fragmented packets to get dropped, but still allow = through the non-fragmented packet.  So, we have a solution = for

“allow all traffic to port 53, but drop = all fragmented packets”.

 

[TR3] I don’t think the above = solution will work. In the above line, I think you  meant L3 ACE, = and the first fragment will match the first entry and is allowed. =

 

[Jon5]No, = the first ACE is a L3/L4 match.  If you have (a1 allows through all = non-fragmented packets, a2 & a3 drops all fragmented packets) the = following

 

[TR4] The first fragment will have both L3 and L4 = information, and matches a1 and is allowed, but if the order is changed = to a3, a1 and a2 (a3 will drop all fragments except last-fragment, the = last fragment will not have L4 info, so will not match a1 but will match = a2 and get dropped).

 

[Jon6] = – Yes – I stand corrected, your ordering is correct.  = A2 no longer needs destination-port.

~jon6

 

-Tiru

 

…

{

       = "aces": [{

        &= nbsp;           &n= bsp;           &nb= sp;    "ace": {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       "name": = "a1",

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       "matches": = [{

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          = "ipv4": {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =              = "destination-network": = "1.2.3.0/24"

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          = },

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          "udp": = {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =              = "destination-port": 53

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          = }

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       }],

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       "actions": = {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          = "forwarding": "accept"

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       }

        &= nbsp;           &n= bsp;           &nb= sp;    }

        &= nbsp;           &n= bsp; },

        &= nbsp;           &n= bsp; {

        &= nbsp;           &n= bsp;           &nb= sp;    "ace": {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       "name": = "a2",

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       "matches": = [{

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          = "ipv4": {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =              = "flags": {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;   "destination-network": = "1.2.3.0/24",

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;   "more": 0

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =              = },

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =              = "udp": {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;   "destination-port": = 53

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =              = }

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          = }

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       }],

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       "actions": = {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          = "forwarding": "drop"

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       }

 

        &= nbsp;           &n= bsp;           &nb= sp;    }

        &= nbsp;           &n= bsp; },

        &= nbsp;           &n= bsp; {

        &= nbsp;           &n= bsp;           &nb= sp;    "ace": {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       "name": = "a3",

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       "matches": = [{

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          = "ipv4": {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =              = "flags": {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;   "more": 1

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =              = }

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          = }

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       }],

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       "actions": = {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          = "forwarding": "drop"

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       }

        &= nbsp;           &n= bsp;           &nb= sp;    }

        &= nbsp;           &n= bsp; }

       = ]

}

…

[Jon5] It = will work

 

-Tiru

 

~jon4

 

-Tiru

 

[Jon3] But = as the final fragment of the sequence could have any offset, the use of = the offset field is not that helpful here.  Even if we do go with = our DOTS fragments definition (but widened to cover all fragments), we = still cannot generate a netmod-acl entry for onward processing by an = upstream mitigator.

 

[Jon3] FYI, = for Juniper, you just need to set ‘first-fragment’ and = ‘is-fragment’ in their ACL.  BGP FlowSpec does support = fragmentation detection properly (RFC5575 Type 12 = Fragment).

 

 

-Tiru

------=_NextPart_000_0133_01D3D32B.75DEDA70-- From nobody Fri Apr 13 21:48:13 2018 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 E19B212DA16 for ; Fri, 13 Apr 2018 21:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.809 X-Spam-Level: X-Spam-Status: No, score=-2.809 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_SORBS_WEB=1.5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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 yyw6ZuPkmSyg for ; Fri, 13 Apr 2018 21:48:09 -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 669CE12DA14 for ; Fri, 13 Apr 2018 21:48:09 -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=1523681288; 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: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-microsoft-antispam: x-ms-traffictypediagnostic:x-microsoft-antispam-prvs: x-exchange-antispam-report-test:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Office365-Filtering-Correlation-Id: X-MS-Exchange-CrossTenant-Network-Message-Id: 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=8 6DM+L4j85ZWHCBMqofkt6NzW6vbaekpAkHA4GawMx o=; b=K5zgFcm7OtBq51nAVXwfM7FCvqM70sYfjq88bq3R9VY5 Srpom4kSeAvItBSxv7apDFI5DQ3o3PR3XDgjb8VW0Q3ioux92y TIusJYHA65QEdrLYXll34Epz7eCQE1Q0ZyBsIyq60ucnErHQFR rX7hfNCzGunJwdezSVBPGT0aieg= Received: from DNVEXAPP1N04.corpzone.internalzone.com (unknown [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 60ff_1234_5d6a0e1c_4bea_4d4e_921e_2d0b7bd06b6f; Fri, 13 Apr 2018 23:48:08 -0500 Received: from DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 13 Apr 2018 22:47:54 -0600 Received: from DNVEXUSR1N11.corpzone.internalzone.com (10.44.48.84) by DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 13 Apr 2018 22:47:53 -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; Fri, 13 Apr 2018 22:47:53 -0600 Received: from NAM02-BL2-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.1347.2; Fri, 13 Apr 2018 22:47:52 -0600 Received: from BN6PR16MB1425.namprd16.prod.outlook.com (10.172.207.19) by BN6PR16MB0100.namprd16.prod.outlook.com (10.172.112.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.675.10; Sat, 14 Apr 2018 04:47:51 +0000 Received: from BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::4430:6104:630b:a067]) by BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::4430:6104:630b:a067%2]) with mapi id 15.20.0675.014; Sat, 14 Apr 2018 04:47:51 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: [Dots] Data Channel ACL fragments Thread-Index: AdPMHAMfDWFlXvb3TSeAr5MVkYUzIgAA3pEAAAKPJoAAIuTfcAADWaQAAADopUAAyEgtgAACNjegABYTlwAAEYzK0AAHIEOAAAC6rLAAAzlEAAAAT7KgAAMBYAAAjfWr8AADyrCAAAQ1fKAAALVegAAiFUnQ Date: Sat, 14 Apr 2018 04:47:51 +0000 Message-ID: References: <016401d3cc1c$03321200$09963600$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7F97@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <01a701d3cc29$ba915b10$2fb41130$@jpshallow.com> <007501d3ccc2$b49f0b00$1ddd2100$@jpshallow.com> <021301d3cfe7$77e5cbe0$67b163a0$@jpshallow.com> <02b001d3d048$a2c68be0$e853a3a0$@jpshallow.com> <000001d3d0ab$547dec40$fd79c4c0$@jpshallow.com> <007701d3d0bb$2404c330$6c0e4990$@jpshallow.com> <00a801d3d0c8$67315800$35940800$@jpshallow.com> <00e901d3d30f$687eb1a0$397c14e0$@jpshallow.com> <013201d3d323$141409d0$3c3c1d70$@jpshallow.com> In-Reply-To: <013201d3d323$141409d0$3c3c1d70$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [122.167.23.143] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR16MB0100; 7:qcNs0XwG5PhbtGkEsUF3I98ZPQfRzp7ZjdEDyHm5zRd+E280HcTAEEo7X8PJ3nXM+Z7oNTVDVUorj+7BCDFUsNsyNaS+b2tvQuNq+p0MvARV49E7kQ2LcvMOxUrH/DmTL9YoNiaI5NUVcTu0XxRoqzDfEfcPxus9+WoIJvg1hPpmNSceQCwgTyCKl9CiA8QRgNzscHtih/YOKMSeEW/RassjAxK/0VEuz3+Ak/RlXOGPG6pg8xjs+p7g27VpovaA x-ms-exchange-antispam-srfa-diagnostics: SOS; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BN6PR16MB0100; x-ms-traffictypediagnostic: BN6PR16MB0100: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(18271650672692)(21748063052155)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231232)(944501327)(52105095)(93006095)(93001095)(3002001)(10201501046)(6041310)(20161123558120)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011); SRVR:BN6PR16MB0100; BCL:0; PCL:0; RULEID:; SRVR:BN6PR16MB0100; x-forefront-prvs: 0642A5E7BA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39380400002)(346002)(366004)(39860400002)(376002)(396003)(32952001)(69234005)(189003)(51444003)(199004)(11346002)(6436002)(6506007)(7736002)(2906002)(3660700001)(110136005)(33656002)(2900100001)(3280700002)(186003)(8936002)(81156014)(81166006)(8676002)(93886005)(9686003)(53936002)(105586002)(74316002)(5660300001)(316002)(236005)(55016002)(53946003)(6246003)(54896002)(106356001)(6306002)(3846002)(19609705001)(80792005)(66066001)(478600001)(72206003)(14454004)(97736004)(2501003)(790700001)(6116002)(229853002)(5250100002)(25786009)(2201001)(53546011)(76176011)(476003)(102836004)(99286004)(68736007)(26005)(446003)(486006)(59450400001)(7696005)(86362001)(85282002)(579004)(559001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR16MB0100; H:BN6PR16MB1425.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: LxeEwzVhVHDDUOoq8FsDiCX5KQwHRjmjrq53sycl2ohTKwKzZPDn0DABnD+nmGs0v+0aCz4atvnw5sOgSggU7GjYZK8yuOidre2DfNRlbN+h3nr5BBUbiXeACmFmmXY3sgxbxOXxE+/dG2V/c5Iyiie9rswSd/12A1eji/WPqcAXT3y+MkhsQaSCN/8g9wBYOzGUVU2gE6SD5ifNsPUSDw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR16MB1425743EE912AC51BE5C7788EAB20BN6PR16MB1425namp_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: bccb0808-e6f5-4b60-32db-08d5a1c2e14c X-MS-Exchange-CrossTenant-Network-Message-Id: bccb0808-e6f5-4b60-32db-08d5a1c2e14c X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Apr 2018 04:47:51.6356 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR16MB0100 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 <6264> : inlines <6562> : streams <1783970> : uri <2625188> Archived-At: Subject: Re: [Dots] Data Channel ACL fragments 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, 14 Apr 2018 04:48:13 -0000 --_000_BN6PR16MB1425743EE912AC51BE5C7788EAB20BN6PR16MB1425namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sure, Appendix looks like the right place to add the filtering rule example= s for both IPv4 and IPv6. -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Friday, April 13, 2018 6:00 PM To: Konda, Tirumaleswar Reddy ; mohamed= .boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] Data Channel ACL fragments Hi Tiru, Thanks. I think that we do need an example in the draft of how to do this though...= . IPv6 will not be using flags, but looking instead for the next header of pr= otocol 44. Regards Jon From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of Konda, T= irumaleswar Reddy Sent: 13 April 2018 13:25 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] Data Channel ACL fragments [Jon6] - Yes - I stand corrected, your ordering is correct. A2 no longer n= eeds destination-port. Yup. The summary of our discussion is to use the flags defined in netmod-ac= l-model to drop fragments (both initial and non-initial), and v4-fragments = and v6-fragments and the associated text added to drop non-initial fragment= s discussed in Section 4.1 will be removed from the draft. Cheers -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Friday, April 13, 2018 3:39 PM To: Konda, Tirumaleswar Reddy >; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] Data Channel ACL fragments Hi Tiru, See inline [Jon6] Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 13 April 2018 10:03 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] Data Channel ACL fragments Hi Jon, Please see inline [TR4] From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Konda@mcafee.com= ] Sent: 10 April 2018 07:10 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] Data Channel ACL fragments [Jon2] The "flags->fragment" definition is ambiguous for an ACE (but valid = as to whether to allow a packet to get fragmented or not - is that really a= ACE?) which I would like to use. [TR] I don't get it. What purpose does it serve to create a ACE rule using = "fragment" bit ? [Jon3] Agreed - This definition has not been thought through for an ACE. I= think they have just emulated the DF bit in RFC791 as this general flags d= efinition is the same as for the flags in RFC791. [TR2] You may want to inform the authors of netmod-acl draft, surprisingly = BGP flowspec also uses "fragment" bit. [Jon4] On my ToDo list for a clean solution. But we do now have a solution= - see below. "Flags->more" definition covers all fragments but the last fragment. "Offse= t" is unfortunately not a range, but otherwise would get used for the final= fragment. ~jon2 [TR] It looks like two ACE entries are required to drop all the fragments (= "flags->more" set to 1 in the first ACE and "flags->more" set to 0 in the s= econd ACE). How to use the "Offset" field for the final fragment ? [Jon3] I read "flags-more" to refer to the IP_MF in the IP header (RFC791 M= F or more-fragments flag). This is set for all fragments apart from the fi= nal (as in last part of packet, not the order in which they are sent - fort= unately that early decision to send them in the wrong order was phased out,= but still there in some legacy systems!) [TR2] Yes, why can't "flags->more" be set to 0 as one ACE entry to drop the= final fragment along with "flags->more" set to 1 to drop the first fragmen= t as another ACE entry so as to drop all fragments to the target ? [Jon4] If "flags->more" is configured and it is configured with a value of = 0, this will match not only the final fragment, but also a non-fragmented p= acket. If "flags->more" is not configured, then this will match a non-frag= mented packet only. [TR3] net-mod-acl says "Setting the value to 0 indicates this is the last f= ragment, and setting the value to 1 indicates more fragments are coming.". = I think it means, if "flags->more" is set to zero and offset is not zero th= en it indicates this is the last fragments; the flags can be used in isolat= ion without comparing if offset value is zero or non-zero. We should check = with netmod-acl authors for confirmation. [Jon5]. The netmod-acl text for flags and offset is effectively a word for= word copy out of RFC791 3.1 Internet Header Format. So I think it is mean= t to be interpreted as being an exact match for the same - including the of= fset specific value. Flags: 3 bits Various Control Flags. Bit 0: reserved, must be zero Bit 1: (DF) 0 =3D May Fragment, 1 =3D Don't Fragment. Bit 2: (MF) 0 =3D Last Fragment, 1 =3D More Fragments. 0 1 2 +---+---+---+ | | D | M | | 0 | F | F | +---+---+---+ Fragment Offset: 13 bits This field indicates where in the datagram this fragment belongs. The fragment offset is measured in units of 8 octets (64 bits). The first fragment has offset zero. ---- Versus ---- leaf flags { type bits { bit reserved { position 0; description "Reserved. Must be zero."; } bit fragment { position 1; description "Setting value to 0 indicates may fragment, while setting the value to 1 indicates do not fragment."; } bit more { position 2; description "Setting the value to 0 indicates this is the last fragment, and setting the value to 1 indicates more fragments are coming."; } } description "Bit definitions for the flags field in IPv4 header."; } leaf offset { type uint16 { range "20..65535"; } description "The fragment offset is measured in units of 8 octets (64 bits). The first fragment has offset zero. The length is 13 bits"; } [Jon4] So, a L4 ACE without "flags->more" defined and "allow", followed by = an ACE with "flags->more" =3D 1 and "drop", followed by an ACE with "flags-= >more" =3D 0 and "drop" will cause all fragmented packets to get dropped, b= ut still allow through the non-fragmented packet. So, we have a solution f= or "allow all traffic to port 53, but drop all fragmented packets". [TR3] I don't think the above solution will work. In the above line, I thin= k you meant L3 ACE, and the first fragment will match the first entry and = is allowed. [Jon5]No, the first ACE is a L3/L4 match. If you have (a1 allows through a= ll non-fragmented packets, a2 & a3 drops all fragmented packets) the follow= ing [TR4] The first fragment will have both L3 and L4 information, and matches = a1 and is allowed, but if the order is changed to a3, a1 and a2 (a3 will dr= op all fragments except last-fragment, the last fragment will not have L4 i= nfo, so will not match a1 but will match a2 and get dropped). [Jon6] - Yes - I stand corrected, your ordering is correct. A2 no longer n= eeds destination-port. ~jon6 -Tiru ... { "aces": [{ "ace": { "name": "a1", "matches": [{ "ipv4": = { = "destination-network": "1.2.3.0/24" }, "udp": { = "destination-port": 53 } }], "actions": { "forward= ing": "accept" } } }, { "ace": { "name": "a2", "matches": [{ "ipv4": = { = "flags": { = "destination-network": "1.2.3.0/24", = "more": 0 = }, = "udp": { = "destination-port": 53 = } } }], "actions": { "forward= ing": "drop" } } }, { "ace": { "name": "a3", "matches": [{ "ipv4": = { = "flags": { = "more": 1 = } } }], "actions": { "forward= ing": "drop" } } } ] } ... [Jon5] It will work -Tiru ~jon4 -Tiru [Jon3] But as the final fragment of the sequence could have any offset, the= use of the offset field is not that helpful here. Even if we do go with o= ur DOTS fragments definition (but widened to cover all fragments), we still= cannot generate a netmod-acl entry for onward processing by an upstream mi= tigator. [Jon3] FYI, for Juniper, you just need to set 'first-fragment' and 'is-frag= ment' in their ACL. BGP FlowSpec does support fragmentation detection prop= erly (RFC5575 Type 12 Fragment). -Tiru --_000_BN6PR16MB1425743EE912AC51BE5C7788EAB20BN6PR16MB1425namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sure, App= endix looks like the right place to add the filtering rule examples for bot= h IPv4 and IPv6.

&nbs= p;

-Tiru

 

From:<= /span> Jon Shallow [mailto:s= upjps-ietf@jpshallow.com]
Sent: Friday, April 13, 2018 6:00 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; mohamed.boucadair@orange.com; dots@ietf.org
Subject: RE: [Dots] Data Channel ACL fragments

 

Hi Tiru= ,

&n= bsp;

Thanks.=

&n= bsp;

I think= that we do need an example in the draft of how to do this though….

&n= bsp;

IPv6 wi= ll not be using flags, but looking instead for the next header of protocol = 44.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 13 April 2018 13:25
To: Jon Shallow; moh= amed.boucadair@orange.com; dots@ietf.org
Subject: Re: [Dots] Data Channel ACL fragments

 

[Jon6] – Yes = 211; I stand corrected, your ordering is correct.  A2 no longer needs = destination-port.

&nbs= p;

Yup. The = summary of our discussion is to use the flags defined in netmod-acl-model t= o drop fragments (both initial and non-initial), and v4-fragments and v6-fr= agments and the associated text added to drop non-initial fragments discussed in Section 4.1 will be removed fro= m the draft.

&nbs= p;

Cheers

-Tiru

&nbs= p;

From:<= /span> Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Friday, April 13, 2018 3:39 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; mohamed.boucadair@orange.co= m; dots@ietf.org
Subject: RE: [Dots] Data Channel ACL fragments

 

Hi Tiru= ,

&n= bsp;

See inl= ine [Jon6]

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 13 April 2018 10:03
To: Jon Shallow; moh= amed.boucadair@orange.com; dots@ietf.org
Subject: Re: [Dots] Data Channel ACL fragments

 

Hi Jon,

&nbs= p;

Please se= e inline [TR4]

&nbs= p;

&n= bsp;

From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Kon= da@mcafee.com]
Sent: 10 April 2018 07:10
To: Jon Shallow; moh= amed.boucadair@orange.com; dots@ietf.org
Subject: RE: [Dots] Data Channel ACL fragments

 

[Jon2] The “flag= s->fragment” definition is ambiguous for an ACE (but valid as to w= hether to allow a packet to get fragmented or not – is that really a = ACE?) which I would like to use. 

 

[TR] I don’t get= it. What purpose does it serve to create a ACE rule using “fragment&= #8221; bit ?

[Jon3] Agreed – = This definition has not been thought through for an ACE.  I think they= have just emulated the DF bit in RFC791 as this general flags definition i= s the same as for the flags in RFC791.

 

[TR2] You may want to inform the authors of netmod-a= cl draft, surprisingly BGP flowspec also uses “fragment” bit.

[Jon4] On my ToDo list= for a clean solution.  But we do now have a solution – see belo= w.

 

 

“Flags->more&= #8221; definition covers all fragments but the last fragment. “Offset= ” is unfortunately not a range, but otherwise would get used for the = final fragment.

~jon2

 

[TR] It looks like two= ACE entries are required to drop all the fragments (“flags->more&= #8221; set to 1 in the first ACE and “flags->more” set to 0 = in the second ACE). How to use the “Offset”  field for the= final fragment ?

 

[Jon3] I read “f= lags-more” to refer to the IP_MF in the IP header (RFC791 MF or more-= fragments flag).  This is set for all fragments apart from the final (= as in last part of packet, not the order in which they are sent – fortunately that early decision to send them in the wrong= order was phased out, but still there in some legacy systems!)<= /span>

 

[TR2] Yes, why can’t “flags->moreR= 21; be set to 0 as one ACE entry to drop the final fragment along with R= 20;flags->more” set to 1 to drop the first fragment as another ACE= entry so as to drop all fragments to the target ?

[Jon4] If “flags= ->more” is configured and it is configured with a value of 0, this= will match not only the final fragment, but also a non-fragmented packet.&= nbsp; If “flags->more” is not configured, then this will match a non-fragmented packet only.

 

[TR3] net-mod-acl says "Setting the value to 0 = indicates this is the last fragment, and setting the value to 1 indicates m= ore fragments are coming.". I think it means, if “flags->more= ” is set to zero and offset is not zero then it indicates this is the last fragments; the flags can be used in isolation without com= paring if offset value is zero or non-zero. We should check with netmod-acl= authors for confirmation.

 

[Jon5].  The netm= od-acl text for flags and offset is effectively a word for word copy out of= RFC791 3.1 Internet Header Format.  So I think it is meant to be inte= rpreted as being an exact match for the same – including the offset specific value.

 

  Flags:  3 bits

 

    Various Control Flags.

 

      Bit 0: reserved, must be zero

      Bit 1: (DF) 0 =3D May Fragment, = 1 =3D Don't Fragment.

      Bit 2: (MF) 0 =3D Last Fragment, 1 = =3D More Fragments.

 

          0  = 1   2

        +---+---+---&= #43;

        |   | D | M |

        | 0 | F | F |<= /span>

        +---+---+---&= #43;

 

  Fragment Offset:  13 bits

 

    This field indicates where in the datagram this f= ragment belongs.

 

    The fragment offset is measured in units of 8 oct= ets (64 bits).  The

    first fragment has offset zero.=

 

 

----

 

Versus

 

----

    leaf flags {

      type bits {

        bit reserved {=

          position 0;

          description

            &= quot;Reserved. Must be zero.";

        }

        bit fragment {=

          position 1;

          description

            &= quot;Setting value to 0 indicates may fragment, while setting

           &n= bsp; the value to 1 indicates do not fragment.";

        }

        bit more {

          position 2;

          description

            &= quot;Setting the value to 0 indicates this is the last fragment,=

           &n= bsp; and setting the value to 1 indicates more fragments are

           &n= bsp; coming.";

        }

      }

      description

        "Bit definitions for= the flags field in IPv4 header.";

    }

 

    leaf offset {

      type uint16 {

        range "20..65535&quo= t;;

      }

 

      description

        "The fragment offset= is measured in units of 8 octets (64 bits).

         The first fragment = has offset zero. The length is 13 bits";

    }

 

[Jon4] So, a L4 ACE wi= thout “flags->more” defined and “allow”, followe= d by an ACE with “flags->more” =3D 1 and “drop”,= followed by an ACE with “flags->more” =3D 0 and “drop= ” will cause all fragmented packets to get dropped, but still allow through the non-fragmented packet.  So, we h= ave a solution for

“allow all traff= ic to port 53, but drop all fragmented packets”.

 

[TR3] I don’t think the above solution will wo= rk. In the above line, I think you  meant L3 ACE, and the first fragme= nt will match the first entry and is allowed.

 

[Jon5]No, the first AC= E is a L3/L4 match.  If you have (a1 allows through all non-fragmented= packets, a2 & a3 drops all fragmented packets) the following

 

[TR4] The first fragment will have both L3 and L4 in= formation, and matches a1 and is allowed, but if the order is changed to a3= , a1 and a2 (a3 will drop all fragments except last-fragment, the last frag= ment will not have L4 info, so will not match a1 but will match a2 and get dropped).

 

[Jon6] – Yes = 211; I stand corrected, your ordering is correct.  A2 no longer needs = destination-port.

~jon6

 

-Tiru

 

…

{

       "aces": [{=

           &n= bsp;            = ;             &= quot;ace": {

           &n= bsp;            = ;            &n= bsp;            = ;   "name": "a1",

           &n= bsp;            = ;            &n= bsp;            = ;   "matches": [{

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;     "ipv4": {

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;        "destination-network"= : "1.2.3.0/24"

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;     },

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;     "udp": {

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;        "destination-port": 5= 3

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;     }

           &n= bsp;            = ;            &n= bsp;            = ;   }],

           &n= bsp;            = ;            &n= bsp;            = ;   "actions": {

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;     "forwarding": "accept"

           &n= bsp;            = ;            &n= bsp;            = ;   }

           &n= bsp;            = ;             }=

           &n= bsp;          },

           &n= bsp;          {

           &n= bsp;            = ;             &= quot;ace": {

           &n= bsp;            = ;            &n= bsp;            = ;   "name": "a2",

           &n= bsp;            = ;            &n= bsp;            = ;   "matches": [{

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;     "ipv4": {

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;        "flags": {=

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;          "destinatio= n-network": "1.2.3.0/24",

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;          "more"= : 0

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;        },

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;        "udp": {

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;          "destinatio= n-port": 53

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;        }

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;     }

           &n= bsp;            = ;            &n= bsp;            = ;   }],

           &n= bsp;            = ;            &n= bsp;            = ;   "actions": {

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;     "forwarding": "drop"<= /o:p>

           &n= bsp;            = ;            &n= bsp;            = ;   }

 

           &n= bsp;            = ;             }=

           &n= bsp;          },

           &n= bsp;          {

           &n= bsp;            = ;             &= quot;ace": {

           &n= bsp;            = ;            &n= bsp;            = ;   "name": "a3",

           &n= bsp;            = ;            &n= bsp;            = ;   "matches": [{

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;     "ipv4": {

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;        "flags": {=

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;          "more"= : 1

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;        }

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;     }

           &n= bsp;            = ;            &n= bsp;            = ;   }],

           &n= bsp;            = ;            &n= bsp;            = ;   "actions": {

           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;     "forwarding": "drop"<= /o:p>

           &n= bsp;            = ;            &n= bsp;            = ;   }

           &n= bsp;            = ;             }=

           &n= bsp;          }

       ]

}

…

[Jon5] It will work

 

-Tiru

 

~jon4

 

-Tiru

 

[Jon3] But as the fina= l fragment of the sequence could have any offset, the use of the offset fie= ld is not that helpful here.  Even if we do go with our DOTS fragments= definition (but widened to cover all fragments), we still cannot generate a netmod-acl entry for onward processing by an up= stream mitigator.

 

[Jon3] FYI, for Junipe= r, you just need to set ‘first-fragment’ and ‘is-fragment= ’ in their ACL.  BGP FlowSpec does support fragmentation detecti= on properly (RFC5575 Type 12 Fragment).

 

 

-Tiru

--_000_BN6PR16MB1425743EE912AC51BE5C7788EAB20BN6PR16MB1425namp_-- From nobody Sun Apr 15 18:03:31 2018 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 9BF2012D872; Sun, 15 Apr 2018 18:03:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.78.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152384060560.20846.4190989513831892435@ietfa.amsl.com> Date: Sun, 15 Apr 2018 18:03:25 -0700 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-use-cases-12.txt 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, 16 Apr 2018 01:03:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DDoS Open Threat Signaling WG of the IETF. Title : Use cases for DDoS Open Threat Signaling Authors : Roland Dobbins Daniel Migault Stefan Fouant Robert Moskowitz Nik Teague Liang Xia Kaname Nishizuka Filename : draft-ietf-dots-use-cases-12.txt Pages : 14 Date : 2018-04-15 Abstract: The DDoS Open Threat Signaling (DOTS) effort is intended to provide protocols to facilitate interoperability across disparate DDoS mitigation solutions. This document presents use cases which describe the interactions expected between the DOTS components as well as DOTS messaging exchanges. These use cases are meant to identify the interacting DOTS components, how they collaborate and what are the typical information to be exchanged. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-use-cases/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-use-cases-12 https://datatracker.ietf.org/doc/html/draft-ietf-dots-use-cases-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-use-cases-12 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Apr 15 18:13:16 2018 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 AB16A12D874 for ; Sun, 15 Apr 2018 18:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 T4Ri2k-q1bXA for ; Sun, 15 Apr 2018 18:13:13 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (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 E35FF12D872 for ; Sun, 15 Apr 2018 18:13:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1523841192; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=5bO8oG5P4cx911pmRxPd0zXb5cKCWomMIVOOp5G+UGY=; b=etfxwr8XNR7Y/1DkhvJ6/soLRs5OX3eeUa4c1w31uN2ghgONNoxhRIM2dGKtL1av 4xYqA/2z5nmNyw4z2rsX6wGRWKTjDRPn32LQiwJbcAwOLprDbsMQ5FE+Vqgv4fJP i36liclGhvU6oQwOaN5YDcOWaRQq3KrrDQe1aaFO5Kg=; X-AuditID: c6180641-1d3ff70000003b41-b3-5ad3f8a86d71 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 66.AE.15169.8A8F3DA5; Mon, 16 Apr 2018 03:13:12 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0382.000; Sun, 15 Apr 2018 21:13:11 -0400 From: Daniel Migault To: "dots@ietf.org" Thread-Topic: New Version Notification for draft-ietf-dots-use-cases-12.txt Thread-Index: AQHT1R68DM74YADLzECR19A4brbyvKQClArA Date: Mon, 16 Apr 2018 01:13:10 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118E33C02@eusaamb107.ericsson.se> References: <152384060577.20846.13118562341786042179.idtracker@ietfa.amsl.com> In-Reply-To: <152384060577.20846.13118562341786042179.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.221] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyuXSPt+6KH5ejDB7uFLdY++YIqwOjx5Il P5kCGKO4bFJSczLLUov07RK4MiYfLi64IVVxrWsNewNjg1QXIyeHhICJxM62nexdjFwcQgJH GSVaztxkhXCWM0o8ON3LAlLFJmAk0Xaonx3EFhFQltjZdJcRxBYW8JL4/P4bC0TcW+Jf3xNW CNtIYu6bF2A2i4CqxOHVDWA1vAK+EtvO9zOB2EICfhJX521m62Lk4OAU8JeYfkQHJMwoICbx /dQasBJmAXGJW0/mM0EcKiCxZM95ZghbVOLl43+sELayxPVVV1hAxjALaEqs36UP0aooMaX7 ITvEVkGJkzOfsExgFJmFZOoshI5ZSDpmIelYwMiyipGjtLggJzfdyHATIzC0j0mwOe5g3Nvr eYhRgINRiYeX69nlKCHWxLLiytxDjBIczEoivMsSgUK8KYmVValF+fFFpTmpxYcYpTlYlMR5 z3nyRgkJpCeWpGanphakFsFkmTg4pRoYLSZufnffrTzhcI1p/sPuj+a2C9fm31RYYnq1+i/v NuVPua3Nn3sOsX170iT4+umV3znfLr4/yrjj+Pwn3Y7W1hPelatmNz3+c26FqtfpmUqMcz6t C943Y3dW3JkFbVLrPjxLWNV7wIzb73ko/+Z70bJ/b042Yys9lnv++5SGs+Knnl5+lN369oAS S3FGoqEWc1FxIgBCNe7AaQIAAA== Archived-At: Subject: [Dots] FW: New Version Notification for draft-ietf-dots-use-cases-12.txt 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, 16 Apr 2018 01:13:15 -0000 SGksIA0KDQpQbGVhc2UgZmluZCBhbiB1cGRhdGUgb2YgdGhlIHVzZSBjYXNlIGRyYWZ0LiBXZSBo YXZlIGFkZHJlc3NlZCBhbGwgY29tbWVudHMgcmVjZWl2ZWQgc28gZmFyIGV4Y2VwdCB0aGUgcmVw bGFjZW1lbnQgb2YgRERvUyBNaXRpZ2F0aW9uIGJ5IEREb1MgbWl0aWdhdGlvbi4gVGhlIGN1cnJl bnQgZHJhZnQgdXNlcyBERG9TIE1pdGlnYXRpb24gYXMgdGhlIHRlcm0gaGFzIGJlZW4gZGVmaW5l ZCBpbiB0aGUgdGVybWlub2xvZ3kgc2VjdGlvbi4gSSBhbSBoYXBweSB0byBtb3ZlIHQgdG8gRERv UyBtaXRpZ2F0aW9uIGlmIHRoaXMgaXMgYmV0dGVyIGFzIHdlbGwuIEFwYXJ0IGZvcm0gdGhpcyBJ IGJlbGlldmUgdGhlIGRvY3VtZW50IGlzIHJlYWR5IGZvciBXR0xDLiANCg0KVGhhbmsgeW91IGFs bCBmb3IgeW91ciByZXZpZXdzIHNvIGZhciwgYW5kIHdlIGV4cGVjdCBhZGRpdGlvbmFsIHJldmll d3MgZHVyaW5nIHRoZSBXR0xDLiANCg0KWW91cnMsIA0KRGFuaWVsDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IFN1bmRheSwgQXByaWwgMTUsIDIwMTggOTowMyBQ TQ0KVG86IEthbmFtZSBOaXNoaXp1a2EgPGthbmFtZUBudHR2Ni5qcD47IE5payBUZWFndWUgPG50 ZWFndWVAdmVyaXNpZ24uY29tPjsgRGFuaWVsIE1pZ2F1bHQgPGRhbmllbC5taWdhdWx0QGVyaWNz c29uLmNvbT47IFJvYmVydCBNb3Nrb3dpdHogPHJnbUBsYWJzLmh0dC1jb25zdWx0LmNvbT47IFN0 ZWZhbiBGb3VhbnQgPHN0ZWZhbi5mb3VhbnRAY29wcGVycml2ZXJpdC5jb20+OyBkb3RzLWNoYWly c0BpZXRmLm9yZzsgUm9sYW5kIERvYmJpbnMgPHJkb2JiaW5zQGFyYm9yLm5ldD47IExpYW5nIFhp YSA8ZnJhbmsueGlhbGlhbmdAaHVhd2VpLmNvbT47IExpYW5nIFhpYSA8RnJhbmsueGlhbGlhbmdA aHVhd2VpLmNvbT4NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQt aWV0Zi1kb3RzLXVzZS1jYXNlcy0xMi50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJh ZnQtaWV0Zi1kb3RzLXVzZS1jYXNlcy0xMi50eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1p dHRlZCBieSBEYW5pZWwgTWlnYXVsdCBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnku DQoNCk5hbWU6CQlkcmFmdC1pZXRmLWRvdHMtdXNlLWNhc2VzDQpSZXZpc2lvbjoJMTINClRpdGxl OgkJVXNlIGNhc2VzIGZvciBERG9TIE9wZW4gVGhyZWF0IFNpZ25hbGluZw0KRG9jdW1lbnQgZGF0 ZToJMjAxOC0wNC0xNQ0KR3JvdXA6CQlkb3RzDQpQYWdlczoJCTE0DQpVUkw6ICAgICAgICAgICAg aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtZG90cy11c2Ut Y2FzZXMtMTIudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtaWV0Zi1kb3RzLXVzZS1jYXNlcy8NCkh0bWxpemVkOiAgICAgICBodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1kb3RzLXVzZS1jYXNlcy0xMg0KSHRtbGl6 ZWQ6ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0 Zi1kb3RzLXVzZS1jYXNlcw0KRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3Jm Y2RpZmY/dXJsMj1kcmFmdC1pZXRmLWRvdHMtdXNlLWNhc2VzLTEyDQoNCkFic3RyYWN0Og0KICAg VGhlIEREb1MgT3BlbiBUaHJlYXQgU2lnbmFsaW5nIChET1RTKSBlZmZvcnQgaXMgaW50ZW5kZWQg dG8gcHJvdmlkZQ0KICAgcHJvdG9jb2xzIHRvIGZhY2lsaXRhdGUgaW50ZXJvcGVyYWJpbGl0eSBh Y3Jvc3MgZGlzcGFyYXRlIEREb1MNCiAgIG1pdGlnYXRpb24gc29sdXRpb25zLiAgVGhpcyBkb2N1 bWVudCBwcmVzZW50cyB1c2UgY2FzZXMgd2hpY2gNCiAgIGRlc2NyaWJlIHRoZSBpbnRlcmFjdGlv bnMgZXhwZWN0ZWQgYmV0d2VlbiB0aGUgRE9UUyBjb21wb25lbnRzIGFzDQogICB3ZWxsIGFzIERP VFMgbWVzc2FnaW5nIGV4Y2hhbmdlcy4gIFRoZXNlIHVzZSBjYXNlcyBhcmUgbWVhbnQgdG8NCiAg IGlkZW50aWZ5IHRoZSBpbnRlcmFjdGluZyBET1RTIGNvbXBvbmVudHMsIGhvdyB0aGV5IGNvbGxh Ym9yYXRlIGFuZA0KICAgd2hhdCBhcmUgdGhlIHR5cGljYWwgaW5mb3JtYXRpb24gdG8gYmUgZXhj aGFuZ2VkLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhh dCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlz c2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0 IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Mon Apr 16 04:11:21 2018 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 C644712D80F for ; Mon, 16 Apr 2018 04:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1tNoUMxKoU7F for ; Mon, 16 Apr 2018 04:11:15 -0700 (PDT) Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5054A12D80E for ; Mon, 16 Apr 2018 04:11:15 -0700 (PDT) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id D45631807DF; Mon, 16 Apr 2018 13:11:13 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.27]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 97DBB1A0054; Mon, 16 Apr 2018 13:11:13 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7C.corporate.adroot.infra.ftgroup ([fe80::8007:17b:c3b4:d68b%19]) with mapi id 14.03.0389.001; Mon, 16 Apr 2018 13:11:13 +0200 From: To: "Konda, Tirumaleswar Reddy" , "Jon Shallow" , "dots@ietf.org" Thread-Topic: [Dots] Data Channel ACL fragments Thread-Index: AdPMHAMfDWFlXvb3TSeAr5MVkYUzIgAA3pEAAAKPJoAAIuTfcAADWaQAAADopUAAyEgtgAACNjegABYTlwAAEYzK0AAHIEOAAAC6rLAAAzlEAAAAT7KgAAMBYAAAjfWr8AADyrCAAAQ1fKAAALVegAAiFUnQAHGmZqA= Date: Mon, 16 Apr 2018 11:11:12 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DF0B47F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <016401d3cc1c$03321200$09963600$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7F97@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <01a701d3cc29$ba915b10$2fb41130$@jpshallow.com> <007501d3ccc2$b49f0b00$1ddd2100$@jpshallow.com> <021301d3cfe7$77e5cbe0$67b163a0$@jpshallow.com> <02b001d3d048$a2c68be0$e853a3a0$@jpshallow.com> <000001d3d0ab$547dec40$fd79c4c0$@jpshallow.com> <007701d3d0bb$2404c330$6c0e4990$@jpshallow.com> <00a801d3d0c8$67315800$35940800$@jpshallow.com> <00e901d3d30f$687eb1a0$397c14e0$@jpshallow.com> <013201d3d323$141409d0$3c3c1d70$@jpshallow.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93302DF0B47FOPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Data Channel ACL fragments 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, 16 Apr 2018 11:11:20 -0000 --_000_787AE7BB302AE849A7480A190F8B93302DF0B47FOPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, I do agree with the conclusion of this thread for IPv4 but not for IPv6. For example, a DOTS client may send this POST request to filter fragmented = packets (including atomic ones): { "ietf-dots-data-channel:acls": { "acl": [ { "name": "dns-fragments", "type": "ipv6-acl-type", "aces": { "ace": [ { "name": "drop-all-fragments", "matches": { "ipv6": { "protocol": 44 } }, "actions": { "forwarding": "drop" } } ] "ace": [ { "name": "allow-dns-packets", "matches": { "ipv6": { "destination-ipv6-network": "2001:db8::/32" } "udp": { "destination-port": { "operator": "eq", "port": 53 } } }, "actions": { "forwarding": "accept" } } ] } } ] } } But these ACEs are efficient only if the next-header of the IPv6 header poi= nts to 44. If the IPv6 packet includes other EHs and the Fragment header is= not the one which is immediately preceding the base header, then fragmente= d packets won't match the "drop-all-fragments" ACE. Cheers, Med De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] Envoy=E9 : samedi 14 avril 2018 06:48 =C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: [Dots] Data Channel ACL fragments Sure, Appendix looks like the right place to add the filtering rule example= s for both IPv4 and IPv6. -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Friday, April 13, 2018 6:00 PM To: Konda, Tirumaleswar Reddy >; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] Data Channel ACL fragments Hi Tiru, Thanks. I think that we do need an example in the draft of how to do this though...= . IPv6 will not be using flags, but looking instead for the next header of pr= otocol 44. Regards Jon From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of Konda, T= irumaleswar Reddy Sent: 13 April 2018 13:25 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] Data Channel ACL fragments [Jon6] - Yes - I stand corrected, your ordering is correct. A2 no longer n= eeds destination-port. Yup. The summary of our discussion is to use the flags defined in netmod-ac= l-model to drop fragments (both initial and non-initial), and v4-fragments = and v6-fragments and the associated text added to drop non-initial fragment= s discussed in Section 4.1 will be removed from the draft. Cheers -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Friday, April 13, 2018 3:39 PM To: Konda, Tirumaleswar Reddy >; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] Data Channel ACL fragments Hi Tiru, See inline [Jon6] Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 13 April 2018 10:03 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] Data Channel ACL fragments Hi Jon, Please see inline [TR4] From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Konda@mcafee.com= ] Sent: 10 April 2018 07:10 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] Data Channel ACL fragments [Jon2] The "flags->fragment" definition is ambiguous for an ACE (but valid = as to whether to allow a packet to get fragmented or not - is that really a= ACE?) which I would like to use. [TR] I don't get it. What purpose does it serve to create a ACE rule using = "fragment" bit ? [Jon3] Agreed - This definition has not been thought through for an ACE. I= think they have just emulated the DF bit in RFC791 as this general flags d= efinition is the same as for the flags in RFC791. [TR2] You may want to inform the authors of netmod-acl draft, surprisingly = BGP flowspec also uses "fragment" bit. [Jon4] On my ToDo list for a clean solution. But we do now have a solution= - see below. "Flags->more" definition covers all fragments but the last fragment. "Offse= t" is unfortunately not a range, but otherwise would get used for the final= fragment. ~jon2 [TR] It looks like two ACE entries are required to drop all the fragments (= "flags->more" set to 1 in the first ACE and "flags->more" set to 0 in the s= econd ACE). How to use the "Offset" field for the final fragment ? [Jon3] I read "flags-more" to refer to the IP_MF in the IP header (RFC791 M= F or more-fragments flag). This is set for all fragments apart from the fi= nal (as in last part of packet, not the order in which they are sent - fort= unately that early decision to send them in the wrong order was phased out,= but still there in some legacy systems!) [TR2] Yes, why can't "flags->more" be set to 0 as one ACE entry to drop the= final fragment along with "flags->more" set to 1 to drop the first fragmen= t as another ACE entry so as to drop all fragments to the target ? [Jon4] If "flags->more" is configured and it is configured with a value of = 0, this will match not only the final fragment, but also a non-fragmented p= acket. If "flags->more" is not configured, then this will match a non-frag= mented packet only. [TR3] net-mod-acl says "Setting the value to 0 indicates this is the last f= ragment, and setting the value to 1 indicates more fragments are coming.". = I think it means, if "flags->more" is set to zero and offset is not zero th= en it indicates this is the last fragments; the flags can be used in isolat= ion without comparing if offset value is zero or non-zero. We should check = with netmod-acl authors for confirmation. [Jon5]. The netmod-acl text for flags and offset is effectively a word for= word copy out of RFC791 3.1 Internet Header Format. So I think it is mean= t to be interpreted as being an exact match for the same - including the of= fset specific value. Flags: 3 bits Various Control Flags. Bit 0: reserved, must be zero Bit 1: (DF) 0 =3D May Fragment, 1 =3D Don't Fragment. Bit 2: (MF) 0 =3D Last Fragment, 1 =3D More Fragments. 0 1 2 +---+---+---+ | | D | M | | 0 | F | F | +---+---+---+ Fragment Offset: 13 bits This field indicates where in the datagram this fragment belongs. The fragment offset is measured in units of 8 octets (64 bits). The first fragment has offset zero. ---- Versus ---- leaf flags { type bits { bit reserved { position 0; description "Reserved. Must be zero."; } bit fragment { position 1; description "Setting value to 0 indicates may fragment, while setting the value to 1 indicates do not fragment."; } bit more { position 2; description "Setting the value to 0 indicates this is the last fragment, and setting the value to 1 indicates more fragments are coming."; } } description "Bit definitions for the flags field in IPv4 header."; } leaf offset { type uint16 { range "20..65535"; } description "The fragment offset is measured in units of 8 octets (64 bits). The first fragment has offset zero. The length is 13 bits"; } [Jon4] So, a L4 ACE without "flags->more" defined and "allow", followed by = an ACE with "flags->more" =3D 1 and "drop", followed by an ACE with "flags-= >more" =3D 0 and "drop" will cause all fragmented packets to get dropped, b= ut still allow through the non-fragmented packet. So, we have a solution f= or "allow all traffic to port 53, but drop all fragmented packets". [TR3] I don't think the above solution will work. In the above line, I thin= k you meant L3 ACE, and the first fragment will match the first entry and = is allowed. [Jon5]No, the first ACE is a L3/L4 match. If you have (a1 allows through a= ll non-fragmented packets, a2 & a3 drops all fragmented packets) the follow= ing [TR4] The first fragment will have both L3 and L4 information, and matches = a1 and is allowed, but if the order is changed to a3, a1 and a2 (a3 will dr= op all fragments except last-fragment, the last fragment will not have L4 i= nfo, so will not match a1 but will match a2 and get dropped). [Jon6] - Yes - I stand corrected, your ordering is correct. A2 no longer n= eeds destination-port. ~jon6 -Tiru ... { "aces": [{ "ace": { "name": "a1", "matches": [{ "ipv4": = { = "destination-network": "1.2.3.0/24" }, "udp": { = "destination-port": 53 } }], "actions": { "forward= ing": "accept" } } }, { "ace": { "name": "a2", "matches": [{ "ipv4": = { = "flags": { = "destination-network": "1.2.3.0/24", = "more": 0 = }, = "udp": { = "destination-port": 53 = } } }], "actions": { "forward= ing": "drop" } } }, { "ace": { "name": "a3", "matches": [{ "ipv4": = { = "flags": { = "more": 1 = } } }], "actions": { "forward= ing": "drop" } } } ] } ... [Jon5] It will work -Tiru ~jon4 -Tiru [Jon3] But as the final fragment of the sequence could have any offset, the= use of the offset field is not that helpful here. Even if we do go with o= ur DOTS fragments definition (but widened to cover all fragments), we still= cannot generate a netmod-acl entry for onward processing by an upstream mi= tigator. [Jon3] FYI, for Juniper, you just need to set 'first-fragment' and 'is-frag= ment' in their ACL. BGP FlowSpec does support fragmentation detection prop= erly (RFC5575 Type 12 Fragment). -Tiru --_000_787AE7BB302AE849A7480A190F8B93302DF0B47FOPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I do agree with the conclusion = of this thread for IPv4 but not for IPv6.

 

For example, a DOTS client may = send this POST request to filter fragmented packets (including atomic ones)= :

 

{

  "ietf-dots-data-cha= nnel:acls": {

    "acl&qu= ot;: [

      = {

     &= nbsp;  "name": "dns-fragments",<= /p>

     &= nbsp;  "type": "ipv6-acl-type",<= /p>

     &= nbsp;  "aces": {

     &= nbsp;    "ace": [

     &= nbsp;      {

     &= nbsp;        "name": "dro= p-all-fragments",

     &= nbsp;        "matches": {=

     &= nbsp;          "ipv6"= ;: {

     &= nbsp;            &qu= ot;protocol": 44

     &= nbsp;          }

     &= nbsp;        },

     &= nbsp;        "actions": {=

     &= nbsp;          "forwardin= g": "drop"

     &= nbsp;        }

     &= nbsp;      }

     &= nbsp;    ]

     &= nbsp;    "ace": [

     &= nbsp;      {

     &= nbsp;        "name": "all= ow-dns-packets",

     &= nbsp;        "matches": {=

     &= nbsp;          "ipv6"= ;: {

     &= nbsp;            &qu= ot;destination-ipv6-network": "2001:db8::/32"

     &= nbsp;          }

       &nbs= p;        "udp": {<= /span>

       &nbs= p;          "destination-= port": {

       &nbs= p;            "= operator": "eq",

       &nbs= p;            "= port": 53

       &nbs= p;          }

     &= nbsp;          }

     &= nbsp;        },

     &= nbsp;        "actions": {=

     &= nbsp;          "forwardin= g": "accept"

     &= nbsp;        }

     &= nbsp;      }

     &= nbsp;    ]

     &= nbsp;  }

      = }

    ]=

  }

}

 

But these ACEs are efficient on= ly if the next-header of the IPv6 header points to 44. If the IPv6 packet i= ncludes other EHs and the Fragment header is not the one which is immediately preceding the base header, then fragmented pa= ckets won’t match the "drop-all-fragments" ACE.<= /span>

 

Cheers,

Med

 

De : Konda, Tirumaleswar Reddy [mail= to:TirumaleswarReddy_Konda@McAfee.com]
Envoy=E9 : samedi 14 avril 2018 06:48
=C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: [Dots] Data Channel ACL fragments=

 

Sure, Appendix looks like the right place to add the filtering rule e= xamples for both IPv4 and IPv6.

 

-Tiru

 

From: Jon Shallow [mailto:s= upjps-ietf@jpshallow.com]
Sent: Friday, April 13, 2018 6:00 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; mohamed.boucadair@orange.co= m; dots@ietf.org
Subject: RE: [Dots] Data Channel ACL fragments

 

Hi Tiru= ,

&n= bsp;

Thanks.=

&n= bsp;

I think= that we do need an example in the draft of how to do this though….

&n= bsp;

IPv6 wi= ll not be using flags, but looking instead for the next header of protocol = 44.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto:ietf-sup= jps-dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 13 April 2018 13:25
To: Jon Shallow; moh= amed.boucadair@orange.com; dots@ietf.org
Subject: Re: [Dots] Data Channel ACL fragments

 

[Jon6] = – Yes – I stand corrected, your ordering is correct.  A2 n= o longer needs destination-port.

 

Yup. The summary of our discussion is to use the flags defined in net= mod-acl-model to drop fragments (both initial and non-initial), and v4-frag= ments and v6-fragments and the associated text added to drop non-initial fragments discussed in Section 4.1 will be = removed from the draft.

 

Cheers

-Tiru

 

From: Jon Shallow [mailto:s= upjps-ietf@jpshallow.com]
Sent: Friday, April 13, 2018 3:39 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; mohamed.boucadair@orange.co= m; dots@ietf.org
Subject: RE: [Dots] Data Channel ACL fragments

 

Hi Tiru= ,

&n= bsp;

See inl= ine [Jon6]

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 13 April 2018 10:03
To: Jon Shallow; moh= amed.boucadair@orange.com; dots@ietf.org
Subject: Re: [Dots] Data Channel ACL fragments

 

Hi Jon,

 

Please see inline [TR4]

 

&n= bsp;

From:= Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Konda@mcafee.com]
Sent: 10 April 2018 07:10
To: Jon Shallow; moh= amed.boucadair@orange.com; dots@ietf.org
Subject: RE: [Dots] Data Channel ACL fragments

 

[Jon2] = The “flags->fragment” definition is ambiguous for an ACE (bu= t valid as to whether to allow a packet to get fragmented or not – is= that really a ACE?) which I would like to use. 

&n= bsp;

[TR] I = don’t get it. What purpose does it serve to create a ACE rule using &= #8220;fragment” bit ?

[Jon3] = Agreed – This definition has not been thought through for an ACE.&nbs= p; I think they have just emulated the DF bit in RFC791 as this general fla= gs definition is the same as for the flags in RFC791.

 

[TR2] You may want to inform th= e authors of netmod-acl draft, surprisingly BGP flowspec also uses “f= ragment” bit.<= /p>

[Jon4] = On my ToDo list for a clean solution.  But we do now have a solution &= #8211; see below.

 

&n= bsp;

“= Flags->more” definition covers all fragments but the last fragment= . “Offset” is unfortunately not a range, but otherwise would ge= t used for the final fragment.

~jon2

&n= bsp;

[TR] It= looks like two ACE entries are required to drop all the fragments (“= flags->more” set to 1 in the first ACE and “flags->more&#= 8221; set to 0 in the second ACE). How to use the “Offset” &nbs= p;field for the final fragment ?

&n= bsp;

[Jon3] = I read “flags-more” to refer to the IP_MF in the IP header (RFC= 791 MF or more-fragments flag).  This is set for all fragments apart f= rom the final (as in last part of packet, not the order in which they are sent – fortunately that early decision to send the= m in the wrong order was phased out, but still there in some legacy systems= !)

 

[TR2] Yes, why can’t R= 20;flags->more” be set to 0 as one ACE entry to drop the final fra= gment along with “flags->more” set to 1 to drop the first fr= agment as another ACE entry so as to drop all fragments to the target ?

[Jon4] = If “flags->more” is configured and it is configured with a v= alue of 0, this will match not only the final fragment, but also a non-frag= mented packet.  If “flags->more” is not configured, the= n this will match a non-fragmented packet only.

 

[TR3] net-mod-acl says "Se= tting the value to 0 indicates this is the last fragment, and setting the v= alue to 1 indicates more fragments are coming.". I think it means, if = “flags->more” is set to zero and offset is not zero then it indicates this is the last fragments; the flags can be used i= n isolation without comparing if offset value is zero or non-zero. We shoul= d check with netmod-acl authors for confirmation.

&n= bsp;

[Jon5].=   The netmod-acl text for flags and offset is effectively a word for w= ord copy out of RFC791 3.1 Internet Header Format.  So I think it is m= eant to be interpreted as being an exact match for the same – including the offset specific value.

&n= bsp;

  Flags:  3 bits

 

    Various Control Flags.<= /span>

 

      Bit 0: reserved, must = be zero

      Bit 1: (DF) 0 =3D May = Fragment,  1 =3D Don't Fragment.

      Bit 2: (MF) 0 =3D Last= Fragment, 1 =3D More Fragments.

 

         = ; 0   1   2

        +---&#= 43;---+---+

        | &nb= sp; | D | M |

        | 0 | F | = F |

        +---&#= 43;---+---+

 

  Fragment Offset:  13 bits

 

    This field indicates where in the = datagram this fragment belongs.

 

    The fragment offset is measured in= units of 8 octets (64 bits).  The

    first fragment has offset zero.

 

 

----

 

Versus

 

----

    leaf flags {

      type bits {=

        bit reserv= ed {

         = ; position 0;

         = ; description

         = ;   "Reserved. Must be zero.";

        }

        bit fragme= nt {

         = ; position 1;

         = ; description

         = ;   "Setting value to 0 indicates may fragment, while settin= g

         = ;    the value to 1 indicates do not fragment.";

        }

        bit more {=

         = ; position 2;

         = ; description

         = ;   "Setting the value to 0 indicates this is the last fragm= ent,

         = ;    and setting the value to 1 indicates more fragments are=

         = ;    coming.";

        }

      }

      description=

        "Bit = definitions for the flags field in IPv4 header.";

    }

 

    leaf offset {

      type uint16 {

        range &quo= t;20..65535";

      }

 

      description=

        "The = fragment offset is measured in units of 8 octets (64 bits).

         The = first fragment has offset zero. The length is 13 bits";

    }

&n= bsp;

[Jon4] = So, a L4 ACE without “flags->more” defined and “allow&= #8221;, followed by an ACE with “flags->more” =3D 1 and R= 20;drop”, followed by an ACE with “flags->more” =3D 0 = and “drop” will cause all fragmented packets to get dropped, but still allow through the non-fragmented packet.=   So, we have a solution for

“= allow all traffic to port 53, but drop all fragmented packets”.<= /o:p>

 

[TR3] I don’t think the a= bove solution will work. In the above line, I think you  meant L3 ACE,= and the first fragment will match the first entry and is allowed.

&n= bsp;

[Jon5]N= o, the first ACE is a L3/L4 match.  If you have (a1 allows through all= non-fragmented packets, a2 & a3 drops all fragmented packets) the foll= owing

 

[TR4] The first fragment will h= ave both L3 and L4 information, and matches a1 and is allowed, but if the o= rder is changed to a3, a1 and a2 (a3 will drop all fragments except last-fr= agment, the last fragment will not have L4 info, so will not match a1 but will match a2 and get dropped).

&n= bsp;

[Jon6] = – Yes – I stand corrected, your ordering is correct.  A2 n= o longer needs destination-port.

~jon6

 

-Tiru

&n= bsp;

…=

{

       "aces"= : [{

         = ;            &n= bsp;            = ;   "ace": {

         = ;            &n= bsp;            = ;            &n= bsp;     "name": "a1",

         = ;            &n= bsp;            = ;            &n= bsp;     "matches": [{

         = ;            &n= bsp;            = ;            &n= bsp;            = ;        "ipv4": {<= /span>

         = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;          "destinatio= n-network": "1.2.3.0/24"

         = ;            &n= bsp;            = ;            &n= bsp;            = ;        },

         = ;            &n= bsp;            = ;            &n= bsp;            = ;        "udp": {

         = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;          "destinatio= n-port": 53

         = ;            &n= bsp;            = ;            &n= bsp;            = ;        }

         = ;            &n= bsp;            = ;            &n= bsp;     }],

         = ;            &n= bsp;            = ;            &n= bsp;     "actions": {

         = ;            &n= bsp;            = ;            &n= bsp;            = ;        "forwarding": "a= ccept"

         = ;            &n= bsp;            = ;            &n= bsp;     }

         = ;            &n= bsp;            = ;   }

         = ;             }= ,

         = ;             {=

         = ;            &n= bsp;            = ;   "ace": {

         = ;            &n= bsp;            = ;            &n= bsp;     "name": "a2",

         = ;            &n= bsp;            = ;            &n= bsp;     "matches": [{

         = ;            &n= bsp;            = ;            &n= bsp;            = ;        "ipv4": {<= /span>

         = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;          "flags"= ;: {

         = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;             &= quot;destination-network": "1.2.3.0/24",

         = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;             &= quot;more": 0

         = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;          },

         = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;          "udp":= {

         = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;             &= quot;destination-port": 53

         = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;          }

         = ;            &n= bsp;            = ;            &n= bsp;            = ;        }

         = ;            &n= bsp;            = ;            &n= bsp;     }],

         = ;            &n= bsp;            = ;            &n= bsp;     "actions": {

         = ;            &n= bsp;            = ;            &n= bsp;            = ;        "forwarding": "d= rop"

         = ;            &n= bsp;            = ;            &n= bsp;     }

 

         = ;            &n= bsp;            = ;   }

         = ;             }= ,

         = ;             {=

         = ;            &n= bsp;            = ;   "ace": {

         = ;            &n= bsp;            = ;            &n= bsp;     "name": "a3",

         = ;            &n= bsp;            = ;            &n= bsp;     "matches": [{

         = ;            &n= bsp;            = ;            &n= bsp;            = ;        "ipv4": {<= /span>

         = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;          "flags"= ;: {

         = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;             &= quot;more": 1

         = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;          }

         = ;            &n= bsp;            = ;            &n= bsp;            = ;        }

         = ;            &n= bsp;            = ;            &n= bsp;     }],

         = ;            &n= bsp;            = ;            &n= bsp;     "actions": {

         = ;            &n= bsp;            = ;            &n= bsp;            = ;        "forwarding": "d= rop"

         = ;            &n= bsp;            = ;            &n= bsp;     }

         = ;            &n= bsp;            = ;   }

         = ;             }=

       ]

}<= /o:p>

…=

[Jon5] = It will work

 

-Tiru

 

~jon4

 

-Tiru

&n= bsp;

[Jon3] = But as the final fragment of the sequence could have any offset, the use of= the offset field is not that helpful here.  Even if we do go with our= DOTS fragments definition (but widened to cover all fragments), we still cannot generate a netmod-acl entry for onwa= rd processing by an upstream mitigator.

&n= bsp;

[Jon3] = FYI, for Juniper, you just need to set ‘first-fragment’ and = 216;is-fragment’ in their ACL.  BGP FlowSpec does support fragme= ntation detection properly (RFC5575 Type 12 Fragment).

 

&n= bsp;

-Tiru<= /span>

--_000_787AE7BB302AE849A7480A190F8B93302DF0B47FOPEXCLILMA3corp_-- From nobody Mon Apr 16 05:08:14 2018 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 1D3611241FC for ; Mon, 16 Apr 2018 05:08:13 -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 BCAvspgCxJAc for ; Mon, 16 Apr 2018 05:08:07 -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 CC849124D68 for ; Mon, 16 Apr 2018 05:08:06 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.90_1) (envelope-from ) id 1f82vS-0000Yc-QP; Mon, 16 Apr 2018 13:08:03 +0100 From: "Jon Shallow" To: , "Konda, Tirumaleswar Reddy" , References: <016401d3cc1c$03321200$09963600$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7F97@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <01a701d3cc29$ba915b10$2fb41130$@jpshallow.com> <007501d3ccc2$b49f0b00$1ddd2100$@jpshallow.com> <021301d3cfe7$77e5cbe0$67b163a0$@jpshallow.com> <02b001d3d048$a2c68be0$e853a3a0$@jpshallow.com> <000001d3d0ab$547dec40$fd79c4c0$@jpshallow.com> <007701d3d0bb$2404c330$6c0e4990$@jpshallow.com> <00a801d3d0c8$67315800$35940800$@jpshallow.com> <00e901d3d30f$687eb1a0$397c14e0$@jpshallow.com> <013201d3d323$141409d0$3c3c1d70$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DF0B47F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DF0B47F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Mon, 16 Apr 2018 13:08:03 +0100 Message-ID: <002101d3d57b$920ebf10$b62c3d30$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0022_01D3D583.F3DC27C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEYhrWXRSNBek+fWBybzdJS41Z0KAI4GsKdAX18SvQDE9KikwNzyn9FAeCfBHcAmG/gMgGrGCDSAZ2/A+cCF5qWXQGy5AXbAg+JyVkByAAwbQHvg6xBAdFnBMIC/mI4iQC6rlcwA1dFhlkCJgU3iQMvoFDAAcXEWBekLXKbQA== Content-Language: en-gb Archived-At: Subject: Re: [Dots] Data Channel ACL fragments 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, 16 Apr 2018 12:08:13 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0022_01D3D583.F3DC27C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Med, =20 Currently we disagree over IPv6 and fragmentation. =20 As per https://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_p= ape r0900aecd8054d37d.html , ACL filtering does work on =93fragments=94. =20 Filtering Based on Extension Header Type =20 Routers can be explicitly instructed to look at and act on traffic that contains certain extension header types. This functionality is available = on Cisco platforms and can be configured with the help of IPv6 Access List options: =20 deny protocol {source-ipv6-prefix/prefix-length | any | host source-ipv6-address} [operator [port-number]] {destination-ipv6-prefix/prefix-length | any | host destination-ipv6-address} [operator [port-number]] [dest-option-type [doh-number | doh-type]] [dscp value] [flow-label value] [fragments] = [log] [log-input] [mobility] [mobility-type [mh-number | mh-type]] [routing] [routing-type routing-number] [sequence value] [time-range name] [undetermined-transport] =20 Example 1: Access List Filtering based on Extension Header Type ipv6 access-list EH-type deny ipv6 any 2001:2B8:1:1::/64 routing =20 In order to permit or deny certain types of extension headers, routers = are configured with the ACL features listed above to filter based on the = "Header Type" value (see Table 1). =20 Note that in this case, the content of the EH is not processed and the router simply makes a decision based on the presence of a certain EH = type. Software platforms can also analyze and filter based on additional EH = fields such as the "Type Field". These filtering capabilities are very useful = in implementing, for instance, security policies such as blocking source routing. =85 Since this functionality is implemented through ACLs, platforms that = support hardware forwarding when ACLs are applied, will be able to handle the = IPv6 traffic with EHs in hardware as well (Figure 7). =20 Juniper appears to support this on the MX router (see https://www.juniper.net/documentation/en_US/junos/topics/reference/genera= l/f irewall-filter-match-conditions-for-ipv6-traffic.html)=20 =20 extension-headers header-type =20 Match an extension header type that is contained in the packet by identifying a Next Header value. Note: This match condition is only supported on MPCs in MX Series = routers. =20 In the first fragment of a packet, the filter searches for a match in = any of the extension header types. When a packet with a fragment header is = found (a subsequent fragment), the filter only searches for a match of the next extension header type because the location of other extension headers is unpredictable. In place of the numeric value, you can specify one of the following text synonyms (the field values are also listed): ah (51), destination (60), = esp (50), fragment (44), hop-by-hop (0), mobility (135), or routing (43). To match any value for the extension header option, use the text synonym any. For MX Series routers with MPCs, initialize new firewall filters that include this condition by walking the corresponding SNMP MIB. =20 So, no matter where the fragment header is (even with subsequent = extended headers (to me the Authenticating Header, or ESP header is the actual protocol)) before the actual protocol, matching on protocol 44 works and = is map-able to Cisco/Juniper ALCs where they do not need to use the control plane =96 or am I missing something here? =20 Regards =20 Jon =20 From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of ietf-supjps-mohamed.boucadair@orange.com Sent: 16 April 2018 12:11 To: Konda, Tirumaleswar Reddy; Jon Shallow; dots@ietf.org Subject: Re: [Dots] Data Channel ACL fragments =20 Hi all,=20 =20 I do agree with the conclusion of this thread for IPv4 but not for IPv6. = =20 For example, a DOTS client may send this POST request to filter = fragmented packets (including atomic ones):=20 =20 { "ietf-dots-data-channel:acls": { "acl": [ { "name": "dns-fragments", "type": "ipv6-acl-type", "aces": { "ace": [ { "name": "drop-all-fragments", "matches": { "ipv6": { "protocol": 44 } }, "actions": { "forwarding": "drop" } } ] "ace": [ { "name": "allow-dns-packets", "matches": { "ipv6": { "destination-ipv6-network": "2001:db8::/32" } "udp": { "destination-port": { "operator": "eq", "port": 53 } } }, "actions": { "forwarding": "accept" } } ] } } ] } } =20 But these ACEs are efficient only if the next-header of the IPv6 header points to 44. If the IPv6 packet includes other EHs and the Fragment = header is not the one which is immediately preceding the base header, then fragmented packets won=92t match the "drop-all-fragments" ACE. =20 Cheers, Med =20 De : Konda, Tirumaleswar Reddy = [mailto:TirumaleswarReddy_Konda@McAfee.com]=20 Envoy=E9 : samedi 14 avril 2018 06:48 =C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: [Dots] Data Channel ACL fragments =20 Sure, Appendix looks like the right place to add the filtering rule = examples for both IPv4 and IPv6. =20 -Tiru =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Friday, April 13, 2018 6:00 PM To: Konda, Tirumaleswar Reddy ; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] Data Channel ACL fragments =20 Hi Tiru, =20 Thanks. =20 I think that we do need an example in the draft of how to do this = though=85. =20 IPv6 will not be using flags, but looking instead for the next header of protocol 44. =20 Regards =20 Jon =20 From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of = Konda, Tirumaleswar Reddy Sent: 13 April 2018 13:25 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] Data Channel ACL fragments =20 [Jon6] =96 Yes =96 I stand corrected, your ordering is correct. A2 no = longer needs destination-port. =20 Yup. The summary of our discussion is to use the flags defined in netmod-acl-model to drop fragments (both initial and non-initial), and v4-fragments and v6-fragments and the associated text added to drop non-initial fragments discussed in Section 4.1 will be removed from the draft. =20 Cheers -Tiru =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Friday, April 13, 2018 3:39 PM To: Konda, Tirumaleswar Reddy ; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] Data Channel ACL fragments =20 Hi Tiru, =20 See inline [Jon6] =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 13 April 2018 10:03 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] Data Channel ACL fragments =20 Hi Jon, =20 Please see inline [TR4] =20 =20 From: Konda, Tirumaleswar Reddy [mailto: = TirumaleswarReddy_Konda@mcafee.com] Sent: 10 April 2018 07:10 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] Data Channel ACL fragments =20 [Jon2] The =93flags->fragment=94 definition is ambiguous for an ACE (but = valid as to whether to allow a packet to get fragmented or not =96 is that = really a ACE?) which I would like to use. =20 =20 [TR] I don=92t get it. What purpose does it serve to create a ACE rule = using =93fragment=94 bit ? [Jon3] Agreed =96 This definition has not been thought through for an = ACE. I think they have just emulated the DF bit in RFC791 as this general flags definition is the same as for the flags in RFC791. =20 [TR2] You may want to inform the authors of netmod-acl draft, = surprisingly BGP flowspec also uses =93fragment=94 bit. [Jon4] On my ToDo list for a clean solution. But we do now have a = solution =96 see below. =20 =20 =93Flags->more=94 definition covers all fragments but the last = fragment.. =93Offset=94 is unfortunately not a range, but otherwise would get used = for the final fragment. ~jon2 =20 [TR] It looks like two ACE entries are required to drop all the = fragments (=93flags->more=94 set to 1 in the first ACE and =93flags->more=94 set = to 0 in the second ACE). How to use the =93Offset=94 field for the final fragment ? =20 [Jon3] I read =93flags-more=94 to refer to the IP_MF in the IP header = (RFC791 MF or more-fragments flag). This is set for all fragments apart from the = final (as in last part of packet, not the order in which they are sent =96 fortunately that early decision to send them in the wrong order was = phased out, but still there in some legacy systems!) =20 [TR2] Yes, why can=92t =93flags->more=94 be set to 0 as one ACE entry to = drop the final fragment along with =93flags->more=94 set to 1 to drop the first = fragment as another ACE entry so as to drop all fragments to the target ? [Jon4] If =93flags->more=94 is configured and it is configured with a = value of 0, this will match not only the final fragment, but also a = non-fragmented packet. If =93flags->more=94 is not configured, then this will match a non-fragmented packet only. =20 [TR3] net-mod-acl says "Setting the value to 0 indicates this is the = last fragment, and setting the value to 1 indicates more fragments are = coming.". I think it means, if =93flags->more=94 is set to zero and offset is not = zero then it indicates this is the last fragments; the flags can be used in isolation without comparing if offset value is zero or non-zero. We = should check with netmod-acl authors for confirmation.=20 =20 [Jon5]. The netmod-acl text for flags and offset is effectively a word = for word copy out of RFC791 3.1 Internet Header Format. So I think it is = meant to be interpreted as being an exact match for the same =96 including the offset specific value. =20 Flags: 3 bits =20 Various Control Flags. =20 Bit 0: reserved, must be zero Bit 1: (DF) 0 =3D May Fragment, 1 =3D Don't Fragment. Bit 2: (MF) 0 =3D Last Fragment, 1 =3D More Fragments. =20 0 1 2 +---+---+---+ | | D | M | | 0 | F | F | +---+---+---+ =20 Fragment Offset: 13 bits =20 This field indicates where in the datagram this fragment belongs. =20 The fragment offset is measured in units of 8 octets (64 bits). The first fragment has offset zero. =20 =20 ---- =20 Versus =20 ---- leaf flags { type bits { bit reserved { position 0; description "Reserved. Must be zero."; } bit fragment { position 1; description "Setting value to 0 indicates may fragment, while setting the value to 1 indicates do not fragment."; } bit more { position 2; description "Setting the value to 0 indicates this is the last fragment, and setting the value to 1 indicates more fragments are coming."; } } description "Bit definitions for the flags field in IPv4 header."; } =20 leaf offset { type uint16 { range "20..65535"; } =20 description "The fragment offset is measured in units of 8 octets (64 bits). The first fragment has offset zero. The length is 13 bits"; } =20 [Jon4] So, a L4 ACE without =93flags->more=94 defined and =93allow=94, = followed by an ACE with =93flags->more=94 =3D 1 and =93drop=94, followed by an ACE = with =93flags->more=94 =3D 0 and =93drop=94 will cause all fragmented packets = to get dropped, but still allow through the non-fragmented packet. So, we have = a solution for =93allow all traffic to port 53, but drop all fragmented packets=94. =20 [TR3] I don=92t think the above solution will work. In the above line, I = think you meant L3 ACE, and the first fragment will match the first entry and = is allowed.=20 =20 [Jon5]No, the first ACE is a L3/L4 match. If you have (a1 allows = through all non-fragmented packets, a2 & a3 drops all fragmented packets) the following=20 =20 [TR4] The first fragment will have both L3 and L4 information, and = matches a1 and is allowed, but if the order is changed to a3, a1 and a2 (a3 will drop all fragments except last-fragment, the last fragment will not have = L4 info, so will not match a1 but will match a2 and get dropped). =20 [Jon6] =96 Yes =96 I stand corrected, your ordering is correct. A2 no = longer needs destination-port. ~jon6 =20 -Tiru =20 =85 { "aces": [{ "ace": { "name": "a1", "matches": [{ = "ipv4": { =20 "destination-network": "1.2.3.0/24" }, = "udp": { =20 "destination-port": 53 } }], "actions": { =20 "forwarding": "accept" } } }, { "ace": { "name": "a2", "matches": [{ = "ipv4": { =20 "flags": { =20 "destination-network": "1.2.3.0/24", =20 "more": 0 =20 }, =20 "udp": { =20 "destination-port": 53 =20 } } }], "actions": { =20 "forwarding": "drop" } =20 } }, { "ace": { "name": "a3", "matches": [{ = "ipv4": { =20 "flags": { =20 "more": 1 =20 } } }], "actions": { =20 "forwarding": "drop" } } } ] } =85 [Jon5] It will work =20 -Tiru =20 ~jon4 =20 -Tiru =20 [Jon3] But as the final fragment of the sequence could have any offset, = the use of the offset field is not that helpful here. Even if we do go with = our DOTS fragments definition (but widened to cover all fragments), we still cannot generate a netmod-acl entry for onward processing by an upstream mitigator. =20 [Jon3] FYI, for Juniper, you just need to set =91first-fragment=92 and =91is-fragment=92 in their ACL. BGP FlowSpec does support fragmentation detection properly (RFC5575 Type 12 Fragment). =20 =20 -Tiru ------=_NextPart_000_0022_01D3D583.F3DC27C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Med,

 

Currently we disagree = over IPv6 and fragmentation.

 

As per https://www.cisco.com/en/US/technologi= es/tk648/tk872/technologies_white_paper0900aecd8054d37d.html , ACL = filtering does work on “fragments”.

 

Filtering Based on Extension Header = Type

 

Routers can be explicitly instructed to look at and = act on traffic that contains certain extension header types. This = functionality is available on Cisco platforms and can be configured with = the help of IPv6 Access List options:

 

deny protocol {source-ipv6-prefix/prefix-length | = any | host source-ipv6-address} [operator [port-number]] = {destination-ipv6-prefix/prefix-length | any | host = destination-ipv6-address} [operator [port-number]] [dest-option-type = [doh-number | doh-type]] [dscp value] [flow-label value] [fragments] = [log] [log-input] [mobility] [mobility-type [mh-number | mh-type]] = [routing] [routing-type routing-number] [sequence value] [time-range = name] [undetermined-transport]

 

Example 1: Access List Filtering based on Extension = Header Type

ipv6 = access-list EH-type

deny = ipv6 any 2001:2B8:1:1::/64 routing

 

In order to permit or deny certain types of = extension headers, routers are configured with the ACL features listed = above to filter based on the "Header Type" value (see Table = 1).

 

Note that in this case, the content of the EH is not = processed and the router simply makes a decision based on the presence = of a certain EH type. Software platforms can also analyze and filter = based on additional EH fields such as the "Type Field". These = filtering capabilities are very useful in implementing, for instance, = security policies such as blocking source = routing.

…

Since this functionality is implemented through = ACLs, platforms that support hardware forwarding when ACLs are applied, = will be able to handle the IPv6 traffic with EHs in hardware as well = (Figure 7).

 

Juniper appears to = support this on the MX router (see https:/= /www.juniper.net/documentation/en_US/junos/topics/reference/general/firew= all-filter-match-conditions-for-ipv6-traffic.html) =

 

extension-headers = header-type

 

Match an extension header type that is contained in = the packet by identifying a Next Header value.

Note: This match condition is only supported on MPCs = in MX Series routers.

 

In the first fragment of a packet, the filter = searches for a match in any of the extension header types. When a packet = with a fragment header is found (a subsequent fragment), the filter only = searches for a match of the next extension header type because the = location of other extension headers is = unpredictable.

In = place of the numeric value, you can specify one of the following text = synonyms (the field values are also listed): ah (51), destination (60), = esp (50), fragment (44), hop-by-hop (0), mobility (135), or routing = (43).

To = match any value for the extension header option, use the text synonym = any.

For MX = Series routers with MPCs, initialize new firewall filters that include = this condition by walking the corresponding SNMP = MIB.

 

So, no matter where the = fragment header is (even with subsequent extended headers (to me the = Authenticating Header, or ESP header is the actual protocol)) before the = actual protocol, matching on protocol 44 works and is map-able to = Cisco/Juniper ALCs where they do not need to use the control plane = – or am I missing something here?

 

Regards

 

Jon

 

From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On = Behalf Of ietf-supjps-mohamed.boucadair@orange.com
Sent: = 16 April 2018 12:11
To: Konda, Tirumaleswar Reddy; Jon = Shallow; dots@ietf.org
Subject: Re: [Dots] Data Channel ACL = fragments

 

Hi all,

 

I do agree with the conclusion of this thread for IPv4 = but not for IPv6.

 

For example, a DOTS client may send this POST request = to filter fragmented packets (including atomic ones): =

 

{

  "ietf-dots-data-channel:acls": = {

    "acl": = [

      = {

        = "name": "dns-fragments",

        = "type": "ipv6-acl-type",

        = "aces": {

          = "ace": [

         &= nbsp;  {

         &= nbsp;    "name": = "drop-all-fragments",

         &= nbsp;    "matches": {

         &= nbsp;      "ipv6": = {

         &= nbsp;        "protocol": = 44

         &= nbsp;      }

         &= nbsp;    },

         &= nbsp;    "actions": {

         &= nbsp;      "forwarding": = "drop"

         &= nbsp;    }

         &= nbsp;  }

          = ]

          = "ace": [

         &= nbsp;  {

         &= nbsp;    "name": = "allow-dns-packets",

         &= nbsp;    "matches": {

         &= nbsp;      "ipv6": = {

         &= nbsp;        = "destination-ipv6-network": = "2001:db8::/32"

         &= nbsp;      }

         &= nbsp;      "udp": = {

         &= nbsp;        = "destination-port": {

         &= nbsp;          = "operator": "eq",

         &= nbsp;          = "port": 53

         &= nbsp;        }

         &= nbsp;      }

         &= nbsp;    },

         &= nbsp;    "actions": {

         &= nbsp;      "forwarding": = "accept"

         &= nbsp;    }

         &= nbsp;  }

          = ]

        = }

      = }

    ]

  = }

}

 

But these ACEs are efficient only if the next-header = of the IPv6 header points to 44. If the IPv6 packet includes other EHs = and the Fragment header is not the one which is immediately preceding = the base header, then fragmented packets won’t match the = "drop-all-fragments" ACE.

 

Cheers,

Med

 

De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarRed= dy_Konda@McAfee.com]
Envoy=E9 : samedi 14 avril 2018 = 06:48
=C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : = RE: [Dots] Data Channel ACL = fragments

 

Sure, Appendix looks = like the right place to add the filtering rule examples for both IPv4 = and IPv6.

 

-Tiru

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Friday, April 13, 2018 6:00 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: RE: = [Dots] Data Channel ACL fragments

 

Hi = Tiru,

 

Thanks.

 

I think that we do need = an example in the draft of how to do this = though….

 

IPv6 will not be using = flags, but looking instead for the next header of protocol = 44.

 

Regards

 

Jon

 

From: Dots [mailto:ietf-supjps-dots= -bounces@ietf.org] On Behalf Of Konda, Tirumaleswar = Reddy
Sent: 13 April 2018 13:25
To: Jon Shallow; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: Re: = [Dots] Data Channel ACL fragments

 

[Jon6] – Yes – I stand = corrected, your ordering is correct.  A2 no longer needs = destination-port.

 

Yup. The summary of our discussion = is to use the flags defined in netmod-acl-model to drop fragments (both = initial and non-initial), and v4-fragments and v6-fragments and the = associated text added to drop non-initial fragments discussed in Section = 4.1 will be removed from the draft.

 

Cheers

-Tiru

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Friday, April 13, 2018 3:39 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: RE: = [Dots] Data Channel ACL fragments

 

Hi = Tiru,

 

See inline = [Jon6]

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 13 April 2018 = 10:03
To: Jon Shallow; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: Re: = [Dots] Data Channel ACL fragments

 

Hi = Jon,

 

Please see inline [TR4]

 

 

From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Kond= a@mcafee.com]
Sent: 10 April 2018 07:10
To: Jon = Shallow; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: RE: = [Dots] Data Channel ACL fragments

 

[Jon2] The = “flags->fragment” definition is ambiguous for an ACE (but = valid as to whether to allow a packet to get fragmented or not – = is that really a ACE?) which I would like to use.  =

 

[TR] I = don’t get it. What purpose does it serve to create a ACE rule = using “fragment” bit ?

[Jon3] = Agreed – This definition has not been thought through for an = ACE.  I think they have just emulated the DF bit in RFC791 as this = general flags definition is the same as for the flags in = RFC791.

 

[TR2] You may want to inform the authors of netmod-acl = draft, surprisingly BGP flowspec also uses “fragment” = bit.

[Jon4] On = my ToDo list for a clean solution.  But we do now have a solution = – see below.

 

 

“Flags->more” definition covers = all fragments but the last fragment.. “Offset” is = unfortunately not a range, but otherwise would get used for the final = fragment.

~jon2

 

[TR] It = looks like two ACE entries are required to drop all the fragments = (“flags->more” set to 1 in the first ACE and = “flags->more” set to 0 in the second ACE). How to use the = “Offset”  field for the final fragment = ?

 

[Jon3] I = read “flags-more” to refer to the IP_MF in the IP header = (RFC791 MF or more-fragments flag).  This is set for all fragments = apart from the final (as in last part of packet, not the order in which = they are sent – fortunately that early decision to send them in = the wrong order was phased out, but still there in some legacy = systems!)

 

[TR2] Yes, why can’t “flags->more” be = set to 0 as one ACE entry to drop the final fragment along with = “flags->more” set to 1 to drop the first fragment as = another ACE entry so as to drop all fragments to the target = ?

[Jon4] If “flags->more” is = configured and it is configured with a value of 0, this will match not = only the final fragment, but also a non-fragmented packet.  If = “flags->more” is not configured, then this will match a = non-fragmented packet only.

 

[TR3] net-mod-acl says = "Setting the value to 0 indicates this is the last fragment, and = setting the value to 1 indicates more fragments are coming.". I = think it means, if “flags->more” is set to zero and = offset is not zero then it indicates this is the last fragments; the = flags can be used in isolation without comparing if offset value is zero = or non-zero. We should check with netmod-acl authors for confirmation. =

 

[Jon5].  The netmod-acl text for flags and = offset is effectively a word for word copy out of RFC791 3.1 Internet = Header Format.  So I think it is meant to be interpreted as being = an exact match for the same – including the offset specific = value.

 

  Flags:  3 = bits

 

    Various Control = Flags.

 

      Bit 0: reserved, = must be zero

      Bit 1: (DF) 0 =3D = May Fragment,  1 =3D Don't Fragment.

      Bit 2: (MF) 0 =3D = Last Fragment, 1 =3D More Fragments.

 

        &= nbsp; 0   1   2

        = +---+---+---+

        = |   | D | M |

        | 0 | = F | F |

        = +---+---+---+

 

  Fragment Offset:  13 = bits

 

    This field indicates where in = the datagram this fragment belongs.

 

    The fragment offset is = measured in units of 8 octets (64 bits).  = The

    first fragment has offset = zero.

 

 

----

 

Versus

 

----

    leaf flags = {

      type bits = {

        bit = reserved {

        &= nbsp; position 0;

        &= nbsp; description

        &= nbsp;   "Reserved. Must be = zero.";

        = }

        bit = fragment {

        &= nbsp; position 1;

        &= nbsp; description

        &= nbsp;   "Setting value to 0 indicates may fragment, while = setting

        &= nbsp;    the value to 1 indicates do not = fragment.";

        = }

        bit = more {

        &= nbsp; position 2;

        &= nbsp; description

        &= nbsp;   "Setting the value to 0 indicates this is the = last fragment,

        &= nbsp;    and setting the value to 1 indicates more = fragments are

        &= nbsp;    coming.";

        = }

      = }

      = description

        = "Bit definitions for the flags field in IPv4 = header.";

    }

 

    leaf offset = {

      type uint16 = {

        range = "20..65535";

      = }

 

      = description

        = "The fragment offset is measured in units of 8 octets (64 = bits).

         = The first fragment has offset zero. The length is 13 = bits";

    }

 

[Jon4] So, = a L4 ACE without “flags->more” defined and = “allow”, followed by an ACE with = “flags->more” =3D 1 and “drop”, followed by = an ACE with “flags->more” =3D 0 and “drop” = will cause all fragmented packets to get dropped, but still allow = through the non-fragmented packet.  So, we have a solution = for

“allow all traffic to port 53, but drop = all fragmented packets”.

 

[TR3] I don’t think the above = solution will work. In the above line, I think you  meant L3 ACE, = and the first fragment will match the first entry and is allowed. =

 

[Jon5]No, = the first ACE is a L3/L4 match.  If you have (a1 allows through all = non-fragmented packets, a2 & a3 drops all fragmented packets) the = following

 

[TR4] The first fragment will have both L3 and L4 = information, and matches a1 and is allowed, but if the order is changed = to a3, a1 and a2 (a3 will drop all fragments except last-fragment, the = last fragment will not have L4 info, so will not match a1 but will match = a2 and get dropped).

 

[Jon6] = – Yes – I stand corrected, your ordering is correct.  = A2 no longer needs destination-port.

~jon6

 

-Tiru

 

…

{

       = "aces": [{

        &= nbsp;           &n= bsp;           &nb= sp;    "ace": {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       "name": = "a1",

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       "matches": = [{

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          = "ipv4": {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =              = "destination-network": = "1.2.3.0/24"

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          = },

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          "udp": = {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =              = "destination-port": 53

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          = }

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       }],

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       "actions": = {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          = "forwarding": "accept"

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       }

        &= nbsp;           &n= bsp;           &nb= sp;    }

        &= nbsp;           &n= bsp; },

        &= nbsp;           &n= bsp; {

        &= nbsp;           &n= bsp;           &nb= sp;    "ace": {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       "name": = "a2",

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       "matches": = [{

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          = "ipv4": {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =              = "flags": {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;   "destination-network": = "1.2.3.0/24",

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;   "more": 0

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =              = },

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =              = "udp": {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;   "destination-port": = 53

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =              = }

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          = }

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       }],

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       "actions": = {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          = "forwarding": "drop"

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       }

 

        &= nbsp;           &n= bsp;           &nb= sp;    }

        &= nbsp;           &n= bsp; },

        &= nbsp;           &n= bsp; {

        &= nbsp;           &n= bsp;           &nb= sp;    "ace": {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       "name": = "a3",

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       "matches": = [{

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          = "ipv4": {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =              = "flags": {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;   "more": 1

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =              = }

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          = }

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       }],

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       "actions": = {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          = "forwarding": "drop"

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       }

        &= nbsp;           &n= bsp;           &nb= sp;    }

        &= nbsp;           &n= bsp; }

       = ]

}

…

[Jon5] It = will work

 

-Tiru

 

~jon4

 

-Tiru

 

[Jon3] But = as the final fragment of the sequence could have any offset, the use of = the offset field is not that helpful here.  Even if we do go with = our DOTS fragments definition (but widened to cover all fragments), we = still cannot generate a netmod-acl entry for onward processing by an = upstream mitigator.

 

[Jon3] FYI, = for Juniper, you just need to set ‘first-fragment’ and = ‘is-fragment’ in their ACL.  BGP FlowSpec does support = fragmentation detection properly (RFC5575 Type 12 = Fragment).

 

 

-Tiru

------=_NextPart_000_0022_01D3D583.F3DC27C0-- From nobody Mon Apr 16 05:23:36 2018 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 0346F126E64 for ; Mon, 16 Apr 2018 05:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6TBoTPURMelq for ; Mon, 16 Apr 2018 05:23:30 -0700 (PDT) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11BD0127137 for ; Mon, 16 Apr 2018 05:23:30 -0700 (PDT) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id AB2A0A03DC; Mon, 16 Apr 2018 14:23:28 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.27]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 756A51A007F; Mon, 16 Apr 2018 14:23:28 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7C.corporate.adroot.infra.ftgroup ([fe80::8007:17b:c3b4:d68b%19]) with mapi id 14.03.0389.001; Mon, 16 Apr 2018 14:23:28 +0200 From: To: Jon Shallow , "Konda, Tirumaleswar Reddy" , "dots@ietf.org" Thread-Topic: [Dots] Data Channel ACL fragments Thread-Index: AQEYhrWXRSNBek+fWBybzdJS41Z0KAI4GsKdAX18SvQDE9KikwNzyn9FAeCfBHcAmG/gMgGrGCDSAZ2/A+cCF5qWXQGy5AXbAg+JyVkByAAwbQHvg6xBAdFnBMIC/mI4iQC6rlcwA1dFhlkCJgU3iQMvoFDAAcXEWBekLXKbQIAACdFg Date: Mon, 16 Apr 2018 12:23:27 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DF0B4F1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <016401d3cc1c$03321200$09963600$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7F97@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <01a701d3cc29$ba915b10$2fb41130$@jpshallow.com> <007501d3ccc2$b49f0b00$1ddd2100$@jpshallow.com> <021301d3cfe7$77e5cbe0$67b163a0$@jpshallow.com> <02b001d3d048$a2c68be0$e853a3a0$@jpshallow.com> <000001d3d0ab$547dec40$fd79c4c0$@jpshallow.com> <007701d3d0bb$2404c330$6c0e4990$@jpshallow.com> <00a801d3d0c8$67315800$35940800$@jpshallow.com> <00e901d3d30f$687eb1a0$397c14e0$@jpshallow.com> <013201d3d323$141409d0$3c3c1d70$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DF0B47F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <002101d3d57b$920ebf10$b62c3d30$@jpshallow.com> In-Reply-To: <002101d3d57b$920ebf10$b62c3d30$@jpshallow.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93302DF0B4F1OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Data Channel ACL fragments 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, 16 Apr 2018 12:23:35 -0000 --_000_787AE7BB302AE849A7480A190F8B93302DF0B4F1OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Jon, I'm afraid the current netmod-acl does not allow to appropriately handle IP= v6 fragments (and more filtering based on Extension Header Types in general= ). At least, the text is not clear whether "protocol" applies for the next-= header of the base header or the one of any enclosed EH. The use of v6-fragment keyword (in the data-channel draft) solves this by p= erforming a check whether a Fragment header is present. "ace": [ { "name": "drop-all-fragments", "matches": { "ipv6": { "v6-fragment" } }, "actions": { "forwarding": "drop" } } ] This check is exactly what Cisco and Juniper are doing in the excerpts you = provided. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : lundi 16 avril 2018 14:08 =C0 : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; dots@ietf.org Objet : RE: [Dots] Data Channel ACL fragments Hi Med, Currently we disagree over IPv6 and fragmentation. As per https://www.cisco.com/en/US/technologies/tk648/tk872/technologies_wh= ite_paper0900aecd8054d37d.html , ACL filtering does work on "fragments". Filtering Based on Extension Header Type Routers can be explicitly instructed to look at and act on traffic that con= tains certain extension header types. This functionality is available on Ci= sco platforms and can be configured with the help of IPv6 Access List optio= ns: deny protocol {source-ipv6-prefix/prefix-length | any | host source-ipv6-ad= dress} [operator [port-number]] {destination-ipv6-prefix/prefix-length | an= y | host destination-ipv6-address} [operator [port-number]] [dest-option-ty= pe [doh-number | doh-type]] [dscp value] [flow-label value] [fragments] [lo= g] [log-input] [mobility] [mobility-type [mh-number | mh-type]] [routing] [= routing-type routing-number] [sequence value] [time-range name] [undetermin= ed-transport] Example 1: Access List Filtering based on Extension Header Type ipv6 access-list EH-type deny ipv6 any 2001:2B8:1:1::/64 routing In order to permit or deny certain types of extension headers, routers are = configured with the ACL features listed above to filter based on the "Heade= r Type" value (see Table 1). Note that in this case, the content of the EH is not processed and the rout= er simply makes a decision based on the presence of a certain EH type. Soft= ware platforms can also analyze and filter based on additional EH fields su= ch as the "Type Field". These filtering capabilities are very useful in imp= lementing, for instance, security policies such as blocking source routing. ... Since this functionality is implemented through ACLs, platforms that suppor= t hardware forwarding when ACLs are applied, will be able to handle the IPv= 6 traffic with EHs in hardware as well (Figure 7). Juniper appears to support this on the MX router (see https://www.juniper.n= et/documentation/en_US/junos/topics/reference/general/firewall-filter-match= -conditions-for-ipv6-traffic.html) extension-headers header-type Match an extension header type that is contained in the packet by identifyi= ng a Next Header value. Note: This match condition is only supported on MPCs in MX Series routers. In the first fragment of a packet, the filter searches for a match in any o= f the extension header types. When a packet with a fragment header is found= (a subsequent fragment), the filter only searches for a match of the next = extension header type because the location of other extension headers is un= predictable. In place of the numeric value, you can specify one of the following text sy= nonyms (the field values are also listed): ah (51), destination (60), esp (= 50), fragment (44), hop-by-hop (0), mobility (135), or routing (43). To match any value for the extension header option, use the text synonym an= y. For MX Series routers with MPCs, initialize new firewall filters that inclu= de this condition by walking the corresponding SNMP MIB. So, no matter where the fragment header is (even with subsequent extended h= eaders (to me the Authenticating Header, or ESP header is the actual protoc= ol)) before the actual protocol, matching on protocol 44 works and is map-a= ble to Cisco/Juniper ALCs where they do not need to use the control plane -= or am I missing something here? Regards Jon From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of ietf-sup= jps-mohamed.boucadair@orange.com Sent: 16 April 2018 12:11 To: Konda, Tirumaleswar Reddy; Jon Shallow; dots@ietf.org Subject: Re: [Dots] Data Channel ACL fragments Hi all, I do agree with the conclusion of this thread for IPv4 but not for IPv6. For example, a DOTS client may send this POST request to filter fragmented = packets (including atomic ones): { "ietf-dots-data-channel:acls": { "acl": [ { "name": "dns-fragments", "type": "ipv6-acl-type", "aces": { "ace": [ { "name": "drop-all-fragments", "matches": { "ipv6": { "protocol": 44 } }, "actions": { "forwarding": "drop" } } ] "ace": [ { "name": "allow-dns-packets", "matches": { "ipv6": { "destination-ipv6-network": "2001:db8::/32" } "udp": { "destination-port": { "operator": "eq", "port": 53 } } }, "actions": { "forwarding": "accept" } } ] } } ] } } But these ACEs are efficient only if the next-header of the IPv6 header poi= nts to 44. If the IPv6 packet includes other EHs and the Fragment header is= not the one which is immediately preceding the base header, then fragmente= d packets won't match the "drop-all-fragments" ACE. Cheers, Med De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] Envoy=E9 : samedi 14 avril 2018 06:48 =C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: [Dots] Data Channel ACL fragments Sure, Appendix looks like the right place to add the filtering rule example= s for both IPv4 and IPv6. -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Friday, April 13, 2018 6:00 PM To: Konda, Tirumaleswar Reddy >; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] Data Channel ACL fragments Hi Tiru, Thanks. I think that we do need an example in the draft of how to do this though...= . IPv6 will not be using flags, but looking instead for the next header of pr= otocol 44. Regards Jon From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of Konda, T= irumaleswar Reddy Sent: 13 April 2018 13:25 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] Data Channel ACL fragments [Jon6] - Yes - I stand corrected, your ordering is correct. A2 no longer n= eeds destination-port. Yup. The summary of our discussion is to use the flags defined in netmod-ac= l-model to drop fragments (both initial and non-initial), and v4-fragments = and v6-fragments and the associated text added to drop non-initial fragment= s discussed in Section 4.1 will be removed from the draft. Cheers -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Friday, April 13, 2018 3:39 PM To: Konda, Tirumaleswar Reddy >; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] Data Channel ACL fragments Hi Tiru, See inline [Jon6] Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 13 April 2018 10:03 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] Data Channel ACL fragments Hi Jon, Please see inline [TR4] From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Konda@mcafee.com= ] Sent: 10 April 2018 07:10 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] Data Channel ACL fragments [Jon2] The "flags->fragment" definition is ambiguous for an ACE (but valid = as to whether to allow a packet to get fragmented or not - is that really a= ACE?) which I would like to use. [TR] I don't get it. What purpose does it serve to create a ACE rule using = "fragment" bit ? [Jon3] Agreed - This definition has not been thought through for an ACE. I= think they have just emulated the DF bit in RFC791 as this general flags d= efinition is the same as for the flags in RFC791. [TR2] You may want to inform the authors of netmod-acl draft, surprisingly = BGP flowspec also uses "fragment" bit. [Jon4] On my ToDo list for a clean solution. But we do now have a solution= - see below. "Flags->more" definition covers all fragments but the last fragment.. "Offs= et" is unfortunately not a range, but otherwise would get used for the fina= l fragment. ~jon2 [TR] It looks like two ACE entries are required to drop all the fragments (= "flags->more" set to 1 in the first ACE and "flags->more" set to 0 in the s= econd ACE). How to use the "Offset" field for the final fragment ? [Jon3] I read "flags-more" to refer to the IP_MF in the IP header (RFC791 M= F or more-fragments flag). This is set for all fragments apart from the fi= nal (as in last part of packet, not the order in which they are sent - fort= unately that early decision to send them in the wrong order was phased out,= but still there in some legacy systems!) [TR2] Yes, why can't "flags->more" be set to 0 as one ACE entry to drop the= final fragment along with "flags->more" set to 1 to drop the first fragmen= t as another ACE entry so as to drop all fragments to the target ? [Jon4] If "flags->more" is configured and it is configured with a value of = 0, this will match not only the final fragment, but also a non-fragmented p= acket. If "flags->more" is not configured, then this will match a non-frag= mented packet only. [TR3] net-mod-acl says "Setting the value to 0 indicates this is the last f= ragment, and setting the value to 1 indicates more fragments are coming.". = I think it means, if "flags->more" is set to zero and offset is not zero th= en it indicates this is the last fragments; the flags can be used in isolat= ion without comparing if offset value is zero or non-zero. We should check = with netmod-acl authors for confirmation. [Jon5]. The netmod-acl text for flags and offset is effectively a word for= word copy out of RFC791 3.1 Internet Header Format. So I think it is mean= t to be interpreted as being an exact match for the same - including the of= fset specific value. Flags: 3 bits Various Control Flags. Bit 0: reserved, must be zero Bit 1: (DF) 0 =3D May Fragment, 1 =3D Don't Fragment. Bit 2: (MF) 0 =3D Last Fragment, 1 =3D More Fragments. 0 1 2 +---+---+---+ | | D | M | | 0 | F | F | +---+---+---+ Fragment Offset: 13 bits This field indicates where in the datagram this fragment belongs. The fragment offset is measured in units of 8 octets (64 bits). The first fragment has offset zero. ---- Versus ---- leaf flags { type bits { bit reserved { position 0; description "Reserved. Must be zero."; } bit fragment { position 1; description "Setting value to 0 indicates may fragment, while setting the value to 1 indicates do not fragment."; } bit more { position 2; description "Setting the value to 0 indicates this is the last fragment, and setting the value to 1 indicates more fragments are coming."; } } description "Bit definitions for the flags field in IPv4 header."; } leaf offset { type uint16 { range "20..65535"; } description "The fragment offset is measured in units of 8 octets (64 bits). The first fragment has offset zero. The length is 13 bits"; } [Jon4] So, a L4 ACE without "flags->more" defined and "allow", followed by = an ACE with "flags->more" =3D 1 and "drop", followed by an ACE with "flags-= >more" =3D 0 and "drop" will cause all fragmented packets to get dropped, b= ut still allow through the non-fragmented packet. So, we have a solution f= or "allow all traffic to port 53, but drop all fragmented packets". [TR3] I don't think the above solution will work. In the above line, I thin= k you meant L3 ACE, and the first fragment will match the first entry and = is allowed. [Jon5]No, the first ACE is a L3/L4 match. If you have (a1 allows through a= ll non-fragmented packets, a2 & a3 drops all fragmented packets) the follow= ing [TR4] The first fragment will have both L3 and L4 information, and matches = a1 and is allowed, but if the order is changed to a3, a1 and a2 (a3 will dr= op all fragments except last-fragment, the last fragment will not have L4 i= nfo, so will not match a1 but will match a2 and get dropped). [Jon6] - Yes - I stand corrected, your ordering is correct. A2 no longer n= eeds destination-port. ~jon6 -Tiru ... { "aces": [{ "ace": { "name": "a1", "matches": [{ "ipv4": = { = "destination-network": "1.2.3.0/24" }, "udp": { = "destination-port": 53 } }], "actions": { "forward= ing": "accept" } } }, { "ace": { "name": "a2", "matches": [{ "ipv4": = { = "flags": { = "destination-network": "1.2.3.0/24", = "more": 0 = }, = "udp": { = "destination-port": 53 = } } }], "actions": { "forward= ing": "drop" } } }, { "ace": { "name": "a3", "matches": [{ "ipv4": = { = "flags": { = "more": 1 = } } }], "actions": { "forward= ing": "drop" } } } ] } ... [Jon5] It will work -Tiru ~jon4 -Tiru [Jon3] But as the final fragment of the sequence could have any offset, the= use of the offset field is not that helpful here. Even if we do go with o= ur DOTS fragments definition (but widened to cover all fragments), we still= cannot generate a netmod-acl entry for onward processing by an upstream mi= tigator. [Jon3] FYI, for Juniper, you just need to set 'first-fragment' and 'is-frag= ment' in their ACL. BGP FlowSpec does support fragmentation detection prop= erly (RFC5575 Type 12 Fragment). -Tiru --_000_787AE7BB302AE849A7480A190F8B93302DF0B4F1OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Jon,

 

I’m afraid the current ne= tmod-acl does not allow to appropriately handle IPv6 fragments (and more fi= ltering based on Extension Header Types in general). At least, the text is not clear whether “protocol” applies for th= e next-header of the base header or the one of any enclosed EH.

 

The use of v6-fragment keyword = (in the data-channel draft) solves this by performing a check whether a Fra= gment header is present.

 

     &= nbsp;    "ace": [

     &= nbsp;      {

     &= nbsp;        "name": "dro= p-all-fragments",

     &= nbsp;        "matches": {=

     &= nbsp;          "ipv6"= ;: {

     &= nbsp;            &qu= ot;v6-fragment"

     &= nbsp;          }

     &= nbsp;        },

     &= nbsp;        "actions": {=

     &= nbsp;          "forwardin= g": "drop"

     &= nbsp;        }

     &= nbsp;      }

     &= nbsp;    ]

 

This check is exactly what Cisc= o and Juniper are doing in the excerpts you provided.

 

Cheers,

Med

 

J= on Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : lundi 16 = avril 2018 14:08
=C0 : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; dot= s@ietf.org
Objet : RE: [Dots] Data Channel ACL fragments=

 

Hi Med,=

&n= bsp;

Current= ly we disagree over IPv6 and fragmentation.

&n= bsp;

As per = https://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_pap= er0900aecd8054d37d.html , ACL filtering does work on “fragments&#= 8221;.

&n= bsp;

Filtering Based on Extension H= eader Type

 

Routers can be explicitly inst= ructed to look at and act on traffic that contains certain extension header= types. This functionality is available on Cisco platforms and can be configured with the help of IPv6 Access List options:=

 

deny protocol {source-ipv6-pre= fix/prefix-length | any | host source-ipv6-address} [operator [port-number]= ] {destination-ipv6-prefix/prefix-length | any | host destination-ipv6-address} [operator [port-number]] [dest-option-type = [doh-number | doh-type]] [dscp value] [flow-label value] [fragments] [log] = [log-input] [mobility] [mobility-type [mh-number | mh-type]] [routing] [rou= ting-type routing-number] [sequence value] [time-range name] [undetermined-transport]

 

Example 1: Access List Filteri= ng based on Extension Header Type

ipv6 access-list EH-type<= /o:p>

deny ipv6 any 2001:2B8:1:1::/6= 4 routing

 

In order to permit or deny cer= tain types of extension headers, routers are configured with the ACL featur= es listed above to filter based on the "Header Type" value (see Table 1).

 

Note that in this case, the co= ntent of the EH is not processed and the router simply makes a decision bas= ed on the presence of a certain EH type. Software platforms can also analyze and filter based on additional EH fields such a= s the "Type Field". These filtering capabilities are very useful = in implementing, for instance, security policies such as blocking source ro= uting.

…

Since this functionality is im= plemented through ACLs, platforms that support hardware forwarding when ACL= s are applied, will be able to handle the IPv6 traffic with EHs in hardware as well (Figure 7).

&n= bsp;

Juniper= appears to support this on the MX router (see https://www.juniper.net/documentation/en_US/junos/topics/reference/general/= firewall-filter-match-conditions-for-ipv6-traffic.html)

&n= bsp;

extension-headers header-type<= o:p>

 

Match an extension header type= that is contained in the packet by identifying a Next Header value.

Note: This match condition is = only supported on MPCs in MX Series routers.

 

In the first fragment of a pac= ket, the filter searches for a match in any of the extension header types. = When a packet with a fragment header is found (a subsequent fragment), the filter only searches for a match of the next ext= ension header type because the location of other extension headers is unpre= dictable.

In place of the numeric value,= you can specify one of the following text synonyms (the field values are a= lso listed): ah (51), destination (60), esp (50), fragment (44), hop-by-hop (0), mobility (135), or routing (43).=

To match any value for the ext= ension header option, use the text synonym any.

For MX Series routers with MPC= s, initialize new firewall filters that include this condition by walking t= he corresponding SNMP MIB.

&n= bsp;

So, no = matter where the fragment header is (even with subsequent extended headers = (to me the Authenticating Header, or ESP header is the actual protocol)) be= fore the actual protocol, matching on protocol 44 works and is map-able to Cisco/Juniper ALCs where they do not = need to use the control plane – or am I missing something here?<= /o:p>

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto:ietf-sup= jps-dots-bounces@ietf.org] On Behalf Of ietf-supjps-mohamed.boucadair@orange.com
Sent: 16 April 2018 12:11
To: Konda, Tirumaleswar Reddy; Jon Shallow; dots@ietf.org
Subject: Re: [Dots] Data Channel ACL fragments

 

Hi all,

 

I do agree with the conclusion = of this thread for IPv4 but not for IPv6.

 

For example, a DOTS client may = send this POST request to filter fragmented packets (including atomic ones)= :

 

{

  "ietf-dots-data-cha= nnel:acls": {

    "acl&qu= ot;: [

      = {

     &= nbsp;  "name": "dns-fragments",<= /p>

     &= nbsp;  "type": "ipv6-acl-type",<= /p>

     &= nbsp;  "aces": {

     &= nbsp;    "ace": [

     &= nbsp;      {

     &= nbsp;        "name": "dro= p-all-fragments",

     &= nbsp;        "matches": {=

     &= nbsp;          "ipv6"= ;: {

     &= nbsp;            &qu= ot;protocol": 44

     &= nbsp;          }

     &= nbsp;        },

     &= nbsp;        "actions": {=

     &= nbsp;          "forwardin= g": "drop"

     &= nbsp;        }

     &= nbsp;      }

     &= nbsp;    ]

     &= nbsp;    "ace": [

     &= nbsp;      {

     &= nbsp;        "name": "all= ow-dns-packets",

     &= nbsp;        "matches": {=

     &= nbsp;          "ipv6"= ;: {

     &= nbsp;            &qu= ot;destination-ipv6-network": "2001:db8::/32"

     &= nbsp;          }

       &nbs= p;        "udp": {<= /span>

       &nbs= p;          "destination-= port": {

       &nbs= p;            "= operator": "eq",

       &nbs= p;            "= port": 53

       &nbs= p;          }

     &= nbsp;          }

     &= nbsp;        },

     &= nbsp;        "actions": {=

     &= nbsp;          "forwardin= g": "accept"

     &= nbsp;        }

     &= nbsp;      }

     &= nbsp;    ]

     &= nbsp;  }

      = }

    ]=

  }

}

 

But these ACEs are efficient on= ly if the next-header of the IPv6 header points to 44. If the IPv6 packet i= ncludes other EHs and the Fragment header is not the one which is immediately preceding the base header, then fragmented pa= ckets won’t match the "drop-all-fragments" ACE.<= /span>

 

Cheers,

Med

 

De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_= Konda@McAfee.com]
Envoy=E9 : samedi 14 avril 2018 06:48
=C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: [Dots] Data Channel ACL fragments=

 

Sure, Appendix looks like the right place to add the filtering rule e= xamples for both IPv4 and IPv6.

 

-Tiru

 

From: Jon Shallow [mailto:s= upjps-ietf@jpshallow.com]
Sent: Friday, April 13, 2018 6:00 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; mohamed.boucadair@orange.co= m; dots@ietf.org
Subject: RE: [Dots] Data Channel ACL fragments

 

Hi Tiru= ,

&n= bsp;

Thanks.=

&n= bsp;

I think= that we do need an example in the draft of how to do this though….

&n= bsp;

IPv6 wi= ll not be using flags, but looking instead for the next header of protocol = 44.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto:ietf-sup= jps-dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 13 April 2018 13:25
To: Jon Shallow; moh= amed.boucadair@orange.com; dots@ietf.org
Subject: Re: [Dots] Data Channel ACL fragments

 

[Jon6] = – Yes – I stand corrected, your ordering is correct.  A2 n= o longer needs destination-port.

 

Yup. The summary of our discussion is to use the flags defined in net= mod-acl-model to drop fragments (both initial and non-initial), and v4-frag= ments and v6-fragments and the associated text added to drop non-initial fragments discussed in Section 4.1 will be = removed from the draft.

 

Cheers

-Tiru

 

From: Jon Shallow [mailto:s= upjps-ietf@jpshallow.com]
Sent: Friday, April 13, 2018 3:39 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; mohamed.boucadair@orange.co= m; dots@ietf.org
Subject: RE: [Dots] Data Channel ACL fragments

 

Hi Tiru= ,

&n= bsp;

See inl= ine [Jon6]

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 13 April 2018 10:03
To: Jon Shallow; moh= amed.boucadair@orange.com; dots@ietf.org
Subject: Re: [Dots] Data Channel ACL fragments

 

Hi Jon,

 

Please see inline [TR4]

 

&n= bsp;

From:= Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Konda@mcafee.com]
Sent: 10 April 2018 07:10
To: Jon Shallow; moh= amed.boucadair@orange.com; dots@ietf.org
Subject: RE: [Dots] Data Channel ACL fragments

 

[Jon2] = The “flags->fragment” definition is ambiguous for an ACE (bu= t valid as to whether to allow a packet to get fragmented or not – is= that really a ACE?) which I would like to use. 

&n= bsp;

[TR] I = don’t get it. What purpose does it serve to create a ACE rule using &= #8220;fragment” bit ?

[Jon3] = Agreed – This definition has not been thought through for an ACE.&nbs= p; I think they have just emulated the DF bit in RFC791 as this general fla= gs definition is the same as for the flags in RFC791.

 

[TR2] You may want to inform th= e authors of netmod-acl draft, surprisingly BGP flowspec also uses “f= ragment” bit.<= /p>

[Jon4] = On my ToDo list for a clean solution.  But we do now have a solution &= #8211; see below.

 

&n= bsp;

“= Flags->more” definition covers all fragments but the last fragment= .. “Offset” is unfortunately not a range, but otherwise would g= et used for the final fragment.

~jon2

&n= bsp;

[TR] It= looks like two ACE entries are required to drop all the fragments (“= flags->more” set to 1 in the first ACE and “flags->more&#= 8221; set to 0 in the second ACE). How to use the “Offset” &nbs= p;field for the final fragment ?

&n= bsp;

[Jon3] = I read “flags-more” to refer to the IP_MF in the IP header (RFC= 791 MF or more-fragments flag).  This is set for all fragments apart f= rom the final (as in last part of packet, not the order in which they are sent – fortunately that early decision to send the= m in the wrong order was phased out, but still there in some legacy systems= !)

 

[TR2] Yes, why can’t R= 20;flags->more” be set to 0 as one ACE entry to drop the final fra= gment along with “flags->more” set to 1 to drop the first fr= agment as another ACE entry so as to drop all fragments to the target ?

[Jon4] = If “flags->more” is configured and it is configured with a v= alue of 0, this will match not only the final fragment, but also a non-frag= mented packet.  If “flags->more” is not configured, the= n this will match a non-fragmented packet only.

 

[TR3] net-mod-acl says "Se= tting the value to 0 indicates this is the last fragment, and setting the v= alue to 1 indicates more fragments are coming.". I think it means, if = “flags->more” is set to zero and offset is not zero then it indicates this is the last fragments; the flags can be used i= n isolation without comparing if offset value is zero or non-zero. We shoul= d check with netmod-acl authors for confirmation.

&n= bsp;

[Jon5].=   The netmod-acl text for flags and offset is effectively a word for w= ord copy out of RFC791 3.1 Internet Header Format.  So I think it is m= eant to be interpreted as being an exact match for the same – including the offset specific value.

&n= bsp;

  Flags:  3 bits

 

    Various Control Flags.<= /span>

 

      Bit 0: reserved, must = be zero

      Bit 1: (DF) 0 =3D May = Fragment,  1 =3D Don't Fragment.

      Bit 2: (MF) 0 =3D Last= Fragment, 1 =3D More Fragments.

 

         = ; 0   1   2

        +---&#= 43;---+---+

        | &nb= sp; | D | M |

        | 0 | F | = F |

        +---&#= 43;---+---+

 

  Fragment Offset:  13 bits

 

    This field indicates where in the = datagram this fragment belongs.

 

    The fragment offset is measured in= units of 8 octets (64 bits).  The

    first fragment has offset zero.

 

 

----

 

Versus

 

----

    leaf flags {

      type bits {=

        bit reserv= ed {

         = ; position 0;

         = ; description

         = ;   "Reserved. Must be zero.";

        }

        bit fragme= nt {

         = ; position 1;

         = ; description

         = ;   "Setting value to 0 indicates may fragment, while settin= g

         = ;    the value to 1 indicates do not fragment.";

        }

        bit more {=

         = ; position 2;

         = ; description

         = ;   "Setting the value to 0 indicates this is the last fragm= ent,

         = ;    and setting the value to 1 indicates more fragments are=

         = ;    coming.";

        }

      }

      description=

        "Bit = definitions for the flags field in IPv4 header.";

    }

 

    leaf offset {

      type uint16 {

        range &quo= t;20..65535";

      }

 

      description=

        "The = fragment offset is measured in units of 8 octets (64 bits).

         The = first fragment has offset zero. The length is 13 bits";

    }

&n= bsp;

[Jon4] = So, a L4 ACE without “flags->more” defined and “allow&= #8221;, followed by an ACE with “flags->more” =3D 1 and R= 20;drop”, followed by an ACE with “flags->more” =3D 0 = and “drop” will cause all fragmented packets to get dropped, but still allow through the non-fragmented packet.=   So, we have a solution for

“= allow all traffic to port 53, but drop all fragmented packets”.<= /o:p>

 

[TR3] I don’t think the a= bove solution will work. In the above line, I think you  meant L3 ACE,= and the first fragment will match the first entry and is allowed.

&n= bsp;

[Jon5]N= o, the first ACE is a L3/L4 match.  If you have (a1 allows through all= non-fragmented packets, a2 & a3 drops all fragmented packets) the foll= owing

 

[TR4] The first fragment will h= ave both L3 and L4 information, and matches a1 and is allowed, but if the o= rder is changed to a3, a1 and a2 (a3 will drop all fragments except last-fr= agment, the last fragment will not have L4 info, so will not match a1 but will match a2 and get dropped).

&n= bsp;

[Jon6] = – Yes – I stand corrected, your ordering is correct.  A2 n= o longer needs destination-port.

~jon6

 

-Tiru

&n= bsp;

…=

{

       "aces"= : [{

         = ;            &n= bsp;            = ;   "ace": {

         = ;            &n= bsp;            = ;            &n= bsp;     "name": "a1",

         = ;            &n= bsp;            = ;            &n= bsp;     "matches": [{

         = ;            &n= bsp;            = ;            &n= bsp;            = ;        "ipv4": {<= /span>

         = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;          "destinatio= n-network": "1.2.3.0/24"

         = ;            &n= bsp;            = ;            &n= bsp;            = ;        },

         = ;            &n= bsp;            = ;            &n= bsp;            = ;        "udp": {

         = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;          "destinatio= n-port": 53

         = ;            &n= bsp;            = ;            &n= bsp;            = ;        }

         = ;            &n= bsp;            = ;            &n= bsp;     }],

         = ;            &n= bsp;            = ;            &n= bsp;     "actions": {

         = ;            &n= bsp;            = ;            &n= bsp;            = ;        "forwarding": "a= ccept"

         = ;            &n= bsp;            = ;            &n= bsp;     }

         = ;            &n= bsp;            = ;   }

         = ;             }= ,

         = ;             {=

         = ;            &n= bsp;            = ;   "ace": {

         = ;            &n= bsp;            = ;            &n= bsp;     "name": "a2",

         = ;            &n= bsp;            = ;            &n= bsp;     "matches": [{

         = ;            &n= bsp;            = ;            &n= bsp;            = ;        "ipv4": {<= /span>

         = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;          "flags"= ;: {

         = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;             &= quot;destination-network": "1.2.3.0/24",

         = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;             &= quot;more": 0

         = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;          },

         = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;          "udp":= {

         = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;             &= quot;destination-port": 53

         = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;          }

         = ;            &n= bsp;            = ;            &n= bsp;            = ;        }

         = ;            &n= bsp;            = ;            &n= bsp;     }],

         = ;            &n= bsp;            = ;            &n= bsp;     "actions": {

         = ;            &n= bsp;            = ;            &n= bsp;            = ;        "forwarding": "d= rop"

         = ;            &n= bsp;            = ;            &n= bsp;     }

 

         = ;            &n= bsp;            = ;   }

         = ;             }= ,

         = ;             {=

         = ;            &n= bsp;            = ;   "ace": {

         = ;            &n= bsp;            = ;            &n= bsp;     "name": "a3",

         = ;            &n= bsp;            = ;            &n= bsp;     "matches": [{

         = ;            &n= bsp;            = ;            &n= bsp;            = ;        "ipv4": {<= /span>

         = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;          "flags"= ;: {

         = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;             &= quot;more": 1

         = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;          }

         = ;            &n= bsp;            = ;            &n= bsp;            = ;        }

         = ;            &n= bsp;            = ;            &n= bsp;     }],

         = ;            &n= bsp;            = ;            &n= bsp;     "actions": {

         = ;            &n= bsp;            = ;            &n= bsp;            = ;        "forwarding": "d= rop"

         = ;            &n= bsp;            = ;            &n= bsp;     }

         = ;            &n= bsp;            = ;   }

         = ;             }=

       ]

}<= /o:p>

…=

[Jon5] = It will work

 

-Tiru

 

~jon4

 

-Tiru

&n= bsp;

[Jon3] = But as the final fragment of the sequence could have any offset, the use of= the offset field is not that helpful here.  Even if we do go with our= DOTS fragments definition (but widened to cover all fragments), we still cannot generate a netmod-acl entry for onwa= rd processing by an upstream mitigator.

&n= bsp;

[Jon3] = FYI, for Juniper, you just need to set ‘first-fragment’ and = 216;is-fragment’ in their ACL.  BGP FlowSpec does support fragme= ntation detection properly (RFC5575 Type 12 Fragment).

 

&n= bsp;

-Tiru<= /span>

--_000_787AE7BB302AE849A7480A190F8B93302DF0B4F1OPEXCLILMA3corp_-- From nobody Mon Apr 16 07:46:21 2018 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 42C1212DA26 for ; Mon, 16 Apr 2018 07:46: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 fmCzT7lx-IMy for ; Mon, 16 Apr 2018 07:46: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 0C01A12DA49 for ; Mon, 16 Apr 2018 07:46:12 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.90_1) (envelope-from ) id 1f85OU-0000eA-1O; Mon, 16 Apr 2018 15:46:10 +0100 From: "Jon Shallow" To: , "Konda, Tirumaleswar Reddy" , References: <016401d3cc1c$03321200$09963600$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7F97@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <01a701d3cc29$ba915b10$2fb41130$@jpshallow.com> <007501d3ccc2$b49f0b00$1ddd2100$@jpshallow.com> <021301d3cfe7$77e5cbe0$67b163a0$@jpshallow.com> <02b001d3d048$a2c68be0$e853a3a0$@jpshallow.com> <000001d3d0ab$547dec40$fd79c4c0$@jpshallow.com> <007701d3d0bb$2404c330$6c0e4990$@jpshallow.com> <00a801d3d0c8$67315800$35940800$@jpshallow.com> <00e901d3d30f$687eb1a0$397c14e0$@jpshallow.com> <013201d3d323$141409d0$3c3c1d70$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DF0B47F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <002101d3d57b$920ebf10$b62c3d30$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DF0B4F1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DF0B4F1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Mon, 16 Apr 2018 15:46:10 +0100 Message-ID: <006001d3d591$a8d2ae30$fa780a90$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0061_01D3D59A.0A9FA1B0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEYhrWXRSNBek+fWBybzdJS41Z0KAI4GsKdAX18SvQDE9KikwNzyn9FAeCfBHcAmG/gMgGrGCDSAZ2/A+cCF5qWXQGy5AXbAg+JyVkByAAwbQHvg6xBAdFnBMIB5XW0gQC6rlcwA1dFhlkCJgU3iQMvoFDAAcXEWBcCAjRLagJU5IDlpBOsveA= Content-Language: en-gb Archived-At: Subject: Re: [Dots] Data Channel ACL fragments 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, 16 Apr 2018 14:46:18 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0061_01D3D59A.0A9FA1B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Med, =20 I think that this comes down to external integration. Whilst out of = scope, the data model communication method for transferring the ACL/ACEs = between a DOTS Server and a DOTS Mitigator cannot be using standard netmod-acl as there is no way to define how to handle fragmentation usage in it = (following your reasoning/interpretation of netmod-acl) unless there is a separate augmentation in that data model to include fragments definitions.=20 =20 Perhaps the right answer is to get the text in netmod-acl tightened up = for clarity between protocol and next-header (along with what is flags-> fragment really meant to do for an ACL in grouping = acl-ipv4-header-fields). =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 16 April 2018 13:23 To: Jon Shallow; Konda, Tirumaleswar Reddy; dots@ietf.org Subject: Re: [Dots] Data Channel ACL fragments =20 Jon,=20 =20 I=92m afraid the current netmod-acl does not allow to appropriately = handle IPv6 fragments (and more filtering based on Extension Header Types in general). At least, the text is not clear whether =93protocol=94 applies = for the next-header of the base header or the one of any enclosed EH.=20 =20 The use of v6-fragment keyword (in the data-channel draft) solves this = by performing a check whether a Fragment header is present.=20 =20 "ace": [ { "name": "drop-all-fragments", "matches": { "ipv6": { "v6-fragment" } }, "actions": { "forwarding": "drop" } } ] =20 This check is exactly what Cisco and Juniper are doing in the excerpts = you provided.=20 =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : lundi 16 avril 2018 14:08 =C0 : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; = dots@ietf.org Objet : RE: [Dots] Data Channel ACL fragments =20 Hi Med, =20 Currently we disagree over IPv6 and fragmentation. =20 As per https://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_p= ape r0900aecd8054d37d.html , ACL filtering does work on =93fragments=94. =20 Filtering Based on Extension Header Type =20 Routers can be explicitly instructed to look at and act on traffic that contains certain extension header types. This functionality is available = on Cisco platforms and can be configured with the help of IPv6 Access List options: =20 deny protocol {source-ipv6-prefix/prefix-length | any | host source-ipv6-address} [operator [port-number]] {destination-ipv6-prefix/prefix-length | any | host destination-ipv6-address} [operator [port-number]] [dest-option-type [doh-number | doh-type]] [dscp value] [flow-label value] [fragments] = [log] [log-input] [mobility] [mobility-type [mh-number | mh-type]] [routing] [routing-type routing-number] [sequence value] [time-range name] [undetermined-transport] =20 Example 1: Access List Filtering based on Extension Header Type ipv6 access-list EH-type deny ipv6 any 2001:2B8:1:1::/64 routing =20 In order to permit or deny certain types of extension headers, routers = are configured with the ACL features listed above to filter based on the = "Header Type" value (see Table 1). =20 Note that in this case, the content of the EH is not processed and the router simply makes a decision based on the presence of a certain EH = type. Software platforms can also analyze and filter based on additional EH = fields such as the "Type Field". These filtering capabilities are very useful = in implementing, for instance, security policies such as blocking source routing. =85 Since this functionality is implemented through ACLs, platforms that = support hardware forwarding when ACLs are applied, will be able to handle the = IPv6 traffic with EHs in hardware as well (Figure 7). =20 Juniper appears to support this on the MX router (see https://www.juniper.net/documentation/en_US/junos/topics/reference/genera= l/f irewall-filter-match-conditions-for-ipv6-traffic.html)=20 =20 extension-headers header-type =20 Match an extension header type that is contained in the packet by identifying a Next Header value. Note: This match condition is only supported on MPCs in MX Series = routers. =20 In the first fragment of a packet, the filter searches for a match in = any of the extension header types. When a packet with a fragment header is = found (a subsequent fragment), the filter only searches for a match of the next extension header type because the location of other extension headers is unpredictable. In place of the numeric value, you can specify one of the following text synonyms (the field values are also listed): ah (51), destination (60), = esp (50), fragment (44), hop-by-hop (0), mobility (135), or routing (43). To match any value for the extension header option, use the text synonym any. For MX Series routers with MPCs, initialize new firewall filters that include this condition by walking the corresponding SNMP MIB. =20 So, no matter where the fragment header is (even with subsequent = extended headers (to me the Authenticating Header, or ESP header is the actual protocol)) before the actual protocol, matching on protocol 44 works and = is map-able to Cisco/Juniper ALCs where they do not need to use the control plane =96 or am I missing something here? =20 Regards =20 Jon =20 From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of ietf-supjps-mohamed.boucadair@orange.com Sent: 16 April 2018 12:11 To: Konda, Tirumaleswar Reddy; Jon Shallow; dots@ietf.org Subject: Re: [Dots] Data Channel ACL fragments =20 Hi all,=20 =20 I do agree with the conclusion of this thread for IPv4 but not for IPv6. = =20 For example, a DOTS client may send this POST request to filter = fragmented packets (including atomic ones):=20 =20 { "ietf-dots-data-channel:acls": { "acl": [ { "name": "dns-fragments", "type": "ipv6-acl-type", "aces": { "ace": [ { "name": "drop-all-fragments", "matches": { "ipv6": { "protocol": 44 } }, "actions": { "forwarding": "drop" } } ] "ace": [ { "name": "allow-dns-packets", "matches": { "ipv6": { "destination-ipv6-network": "2001:db8::/32" } "udp": { "destination-port": { "operator": "eq", "port": 53 } } }, "actions": { "forwarding": "accept" } } ] } } ] } } =20 But these ACEs are efficient only if the next-header of the IPv6 header points to 44. If the IPv6 packet includes other EHs and the Fragment = header is not the one which is immediately preceding the base header, then fragmented packets won=92t match the "drop-all-fragments" ACE. =20 Cheers, Med =20 De : Konda, Tirumaleswar Reddy = [mailto:TirumaleswarReddy_Konda@McAfee.com]=20 Envoy=E9 : samedi 14 avril 2018 06:48 =C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: [Dots] Data Channel ACL fragments =20 Sure, Appendix looks like the right place to add the filtering rule = examples for both IPv4 and IPv6. =20 -Tiru =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Friday, April 13, 2018 6:00 PM To: Konda, Tirumaleswar Reddy ; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] Data Channel ACL fragments =20 Hi Tiru, =20 Thanks. =20 I think that we do need an example in the draft of how to do this = though=85. =20 IPv6 will not be using flags, but looking instead for the next header of protocol 44. =20 Regards =20 Jon =20 From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of = Konda, Tirumaleswar Reddy Sent: 13 April 2018 13:25 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] Data Channel ACL fragments =20 [Jon6] =96 Yes =96 I stand corrected, your ordering is correct. A2 no = longer needs destination-port. =20 Yup. The summary of our discussion is to use the flags defined in netmod-acl-model to drop fragments (both initial and non-initial), and v4-fragments and v6-fragments and the associated text added to drop non-initial fragments discussed in Section 4.1 will be removed from the draft. =20 Cheers -Tiru =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Friday, April 13, 2018 3:39 PM To: Konda, Tirumaleswar Reddy ; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] Data Channel ACL fragments =20 Hi Tiru, =20 See inline [Jon6] =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 13 April 2018 10:03 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] Data Channel ACL fragments =20 Hi Jon, =20 Please see inline [TR4] =20 =20 From: Konda, Tirumaleswar Reddy [mailto: = TirumaleswarReddy_Konda@mcafee.com] Sent: 10 April 2018 07:10 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] Data Channel ACL fragments =20 [Jon2] The =93flags->fragment=94 definition is ambiguous for an ACE (but = valid as to whether to allow a packet to get fragmented or not =96 is that = really a ACE?) which I would like to use. =20 =20 [TR] I don=92t get it. What purpose does it serve to create a ACE rule = using =93fragment=94 bit ? [Jon3] Agreed =96 This definition has not been thought through for an = ACE. I think they have just emulated the DF bit in RFC791 as this general flags definition is the same as for the flags in RFC791. =20 [TR2] You may want to inform the authors of netmod-acl draft, = surprisingly BGP flowspec also uses =93fragment=94 bit. [Jon4] On my ToDo list for a clean solution. But we do now have a = solution =96 see below. =20 =20 =93Flags->more=94 definition covers all fragments but the last = fragment... =93Offset=94 is unfortunately not a range, but otherwise would get used = for the final fragment. ~jon2 =20 [TR] It looks like two ACE entries are required to drop all the = fragments (=93flags->more=94 set to 1 in the first ACE and =93flags->more=94 set = to 0 in the second ACE). How to use the =93Offset=94 field for the final fragment ? =20 [Jon3] I read =93flags-more=94 to refer to the IP_MF in the IP header = (RFC791 MF or more-fragments flag). This is set for all fragments apart from the = final (as in last part of packet, not the order in which they are sent =96 fortunately that early decision to send them in the wrong order was = phased out, but still there in some legacy systems!) =20 [TR2] Yes, why can=92t =93flags->more=94 be set to 0 as one ACE entry to = drop the final fragment along with =93flags->more=94 set to 1 to drop the first = fragment as another ACE entry so as to drop all fragments to the target ? [Jon4] If =93flags->more=94 is configured and it is configured with a = value of 0, this will match not only the final fragment, but also a = non-fragmented packet. If =93flags->more=94 is not configured, then this will match a non-fragmented packet only. =20 [TR3] net-mod-acl says "Setting the value to 0 indicates this is the = last fragment, and setting the value to 1 indicates more fragments are = coming.". I think it means, if =93flags->more=94 is set to zero and offset is not = zero then it indicates this is the last fragments; the flags can be used in isolation without comparing if offset value is zero or non-zero. We = should check with netmod-acl authors for confirmation.=20 =20 [Jon5]. The netmod-acl text for flags and offset is effectively a word = for word copy out of RFC791 3.1 Internet Header Format. So I think it is = meant to be interpreted as being an exact match for the same =96 including the offset specific value. =20 Flags: 3 bits =20 Various Control Flags. =20 Bit 0: reserved, must be zero Bit 1: (DF) 0 =3D May Fragment, 1 =3D Don't Fragment. Bit 2: (MF) 0 =3D Last Fragment, 1 =3D More Fragments. =20 0 1 2 +---+---+---+ | | D | M | | 0 | F | F | +---+---+---+ =20 Fragment Offset: 13 bits =20 This field indicates where in the datagram this fragment belongs. =20 The fragment offset is measured in units of 8 octets (64 bits). The first fragment has offset zero. =20 =20 ---- =20 Versus =20 ---- leaf flags { type bits { bit reserved { position 0; description "Reserved. Must be zero."; } bit fragment { position 1; description "Setting value to 0 indicates may fragment, while setting the value to 1 indicates do not fragment."; } bit more { position 2; description "Setting the value to 0 indicates this is the last fragment, and setting the value to 1 indicates more fragments are coming."; } } description "Bit definitions for the flags field in IPv4 header."; } =20 leaf offset { type uint16 { range "20..65535"; } =20 description "The fragment offset is measured in units of 8 octets (64 bits). The first fragment has offset zero. The length is 13 bits"; } =20 [Jon4] So, a L4 ACE without =93flags->more=94 defined and =93allow=94, = followed by an ACE with =93flags->more=94 =3D 1 and =93drop=94, followed by an ACE = with =93flags->more=94 =3D 0 and =93drop=94 will cause all fragmented packets = to get dropped, but still allow through the non-fragmented packet. So, we have = a solution for =93allow all traffic to port 53, but drop all fragmented packets=94. =20 [TR3] I don=92t think the above solution will work. In the above line, I = think you meant L3 ACE, and the first fragment will match the first entry and = is allowed.=20 =20 [Jon5]No, the first ACE is a L3/L4 match. If you have (a1 allows = through all non-fragmented packets, a2 & a3 drops all fragmented packets) the following=20 =20 [TR4] The first fragment will have both L3 and L4 information, and = matches a1 and is allowed, but if the order is changed to a3, a1 and a2 (a3 will drop all fragments except last-fragment, the last fragment will not have = L4 info, so will not match a1 but will match a2 and get dropped). =20 [Jon6] =96 Yes =96 I stand corrected, your ordering is correct. A2 no = longer needs destination-port. ~jon6 =20 -Tiru =20 =85 { "aces": [{ "ace": { "name": "a1", "matches": [{ = "ipv4": { =20 "destination-network": "1.2.3.0/24" }, = "udp": { =20 "destination-port": 53 } }], "actions": { =20 "forwarding": "accept" } } }, { "ace": { "name": "a2", "matches": [{ = "ipv4": { =20 "flags": { =20 "destination-network": "1.2.3.0/24", =20 "more": 0 =20 }, =20 "udp": { =20 "destination-port": 53 =20 } } }], "actions": { =20 "forwarding": "drop" } =20 } }, { "ace": { "name": "a3", "matches": [{ = "ipv4": { =20 "flags": { =20 "more": 1 =20 } } }], "actions": { =20 "forwarding": "drop" } } } ] } =85 [Jon5] It will work =20 -Tiru =20 ~jon4 =20 -Tiru =20 [Jon3] But as the final fragment of the sequence could have any offset, = the use of the offset field is not that helpful here. Even if we do go with = our DOTS fragments definition (but widened to cover all fragments), we still cannot generate a netmod-acl entry for onward processing by an upstream mitigator. =20 [Jon3] FYI, for Juniper, you just need to set =91first-fragment=92 and =91is-fragment=92 in their ACL. BGP FlowSpec does support fragmentation detection properly (RFC5575 Type 12 Fragment). =20 =20 -Tiru ------=_NextPart_000_0061_01D3D59A.0A9FA1B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Med,

 

I think that this comes = down to external integration.=A0 Whilst out of scope, the data model = communication method for transferring the ACL/ACEs between a DOTS Server = and a DOTS Mitigator cannot be using standard netmod-acl as there is no = way to define how to handle fragmentation usage in it (following your = reasoning/interpretation of netmod-acl) unless there is a separate = augmentation in that data model to include fragments definitions. =

 

Perhaps the right answer = is to get the text in netmod-acl tightened up for clarity between = protocol and next-header (along with what is flags-> fragment really = meant to do for an ACL in grouping = acl-ipv4-header-fields).

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com
Sent: 16 April 2018 = 13:23
To: Jon Shallow; Konda, Tirumaleswar Reddy; = dots@ietf.org
Subject: Re: [Dots] Data Channel ACL = fragments

 

Jon,

 

I’m afraid the current netmod-acl does not allow = to appropriately handle IPv6 fragments (and more filtering based on = Extension Header Types in general). At least, the text is not clear = whether “protocol” applies for the next-header of the base = header or the one of any enclosed EH.

 

The use of v6-fragment keyword (in the data-channel = draft) solves this by performing a check whether a Fragment header is = present.

 

          = "ace": [

         &= nbsp;  {

         &= nbsp;    "name": = "drop-all-fragments",

         &= nbsp;    "matches": {

         &= nbsp;      "ipv6": = {

         &= nbsp;        = "v6-fragment"

         &= nbsp;      }

         &= nbsp;    },

         &= nbsp;    "actions": {

         &= nbsp;      "forwarding": = "drop"

         &= nbsp;    }

         &= nbsp;  }

          = ]

 

This check is exactly what Cisco and Juniper are doing = in the excerpts you provided.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Envoy=E9 : lundi 16 avril 2018 14:08
=C0 : BOUCADAIR Mohamed = IMT/OLN; Konda, Tirumaleswar Reddy; dots@ietf.org
Objet : = RE: [Dots] Data Channel ACL = fragments

 

Hi Med,

 

Currently we disagree = over IPv6 and fragmentation.

 

As per https://www.cisco.com/en/US/technologi= es/tk648/tk872/technologies_white_paper0900aecd8054d37d.html , ACL = filtering does work on “fragments”.

 

Filtering Based on Extension Header = Type

 

Routers can be explicitly instructed to look at and = act on traffic that contains certain extension header types. This = functionality is available on Cisco platforms and can be configured with = the help of IPv6 Access List options:

 

deny protocol {source-ipv6-prefix/prefix-length | = any | host source-ipv6-address} [operator [port-number]] = {destination-ipv6-prefix/prefix-length | any | host = destination-ipv6-address} [operator [port-number]] [dest-option-type = [doh-number | doh-type]] [dscp value] [flow-label value] [fragments] = [log] [log-input] [mobility] [mobility-type [mh-number | mh-type]] = [routing] [routing-type routing-number] [sequence value] [time-range = name] [undetermined-transport]

 

Example 1: Access List Filtering based on Extension = Header Type

ipv6 = access-list EH-type

deny = ipv6 any 2001:2B8:1:1::/64 routing

 

In order to permit or deny certain types of = extension headers, routers are configured with the ACL features listed = above to filter based on the "Header Type" value (see Table = 1).

 

Note that in this case, the content of the EH is not = processed and the router simply makes a decision based on the presence = of a certain EH type. Software platforms can also analyze and filter = based on additional EH fields such as the "Type Field". These = filtering capabilities are very useful in implementing, for instance, = security policies such as blocking source = routing.

…

Since this functionality is implemented through = ACLs, platforms that support hardware forwarding when ACLs are applied, = will be able to handle the IPv6 traffic with EHs in hardware as well = (Figure 7).

 

Juniper appears to = support this on the MX router (see https:/= /www.juniper.net/documentation/en_US/junos/topics/reference/general/firew= all-filter-match-conditions-for-ipv6-traffic.html) =

 

extension-headers = header-type

 

Match an extension header type that is contained in = the packet by identifying a Next Header value.

Note: This match condition is only supported on MPCs = in MX Series routers.

 

In the first fragment of a packet, the filter = searches for a match in any of the extension header types. When a packet = with a fragment header is found (a subsequent fragment), the filter only = searches for a match of the next extension header type because the = location of other extension headers is = unpredictable.

In = place of the numeric value, you can specify one of the following text = synonyms (the field values are also listed): ah (51), destination (60), = esp (50), fragment (44), hop-by-hop (0), mobility (135), or routing = (43).

To = match any value for the extension header option, use the text synonym = any.

For MX = Series routers with MPCs, initialize new firewall filters that include = this condition by walking the corresponding SNMP = MIB.

 

So, no matter where the = fragment header is (even with subsequent extended headers (to me the = Authenticating Header, or ESP header is the actual protocol)) before the = actual protocol, matching on protocol 44 works and is map-able to = Cisco/Juniper ALCs where they do not need to use the control plane = – or am I missing something here?

 

Regards

 

Jon

 

From: Dots [mailto:ietf-supjps-dots= -bounces@ietf.org] On Behalf Of ietf-supjps-moha= med.boucadair@orange.com
Sent: 16 April 2018 = 12:11
To: Konda, Tirumaleswar Reddy; Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] Data Channel ACL fragments

 

Hi all,

 

I do agree with the conclusion of this thread for IPv4 = but not for IPv6.

 

For example, a DOTS client may send this POST request = to filter fragmented packets (including atomic ones): =

 

{

  "ietf-dots-data-channel:acls": = {

    "acl": = [

      = {

        = "name": "dns-fragments",

        = "type": "ipv6-acl-type",

        = "aces": {

          = "ace": [

         &= nbsp;  {

         &= nbsp;    "name": = "drop-all-fragments",

         &= nbsp;    "matches": {

         &= nbsp;      "ipv6": = {

         &= nbsp;        "protocol": = 44

         &= nbsp;      }

         &= nbsp;    },

         &= nbsp;    "actions": {

         &= nbsp;      "forwarding": = "drop"

         &= nbsp;    }

         &= nbsp;  }

          = ]

          = "ace": [

         &= nbsp;  {

         &= nbsp;    "name": = "allow-dns-packets",

         &= nbsp;    "matches": {

         &= nbsp;      "ipv6": = {

         &= nbsp;        = "destination-ipv6-network": = "2001:db8::/32"

         &= nbsp;      }

         &= nbsp;      "udp": = {

         &= nbsp;        = "destination-port": {

         &= nbsp;          = "operator": "eq",

         &= nbsp;          = "port": 53

         &= nbsp;        }

         &= nbsp;      }

         &= nbsp;    },

         &= nbsp;    "actions": {

         &= nbsp;      "forwarding": = "accept"

         &= nbsp;    }

         &= nbsp;  }

          = ]

        = }

      = }

    ]

  = }

}

 

But these ACEs are efficient only if the next-header = of the IPv6 header points to 44. If the IPv6 packet includes other EHs = and the Fragment header is not the one which is immediately preceding = the base header, then fragmented packets won’t match the = "drop-all-fragments" ACE.

 

Cheers,

Med

 

De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarRed= dy_Konda@McAfee.com]
Envoy=E9 : samedi 14 avril 2018 = 06:48
=C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : = RE: [Dots] Data Channel ACL = fragments

 

Sure, Appendix looks = like the right place to add the filtering rule examples for both IPv4 = and IPv6.

 

-Tiru

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Friday, April 13, 2018 6:00 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: RE: = [Dots] Data Channel ACL fragments

 

Hi = Tiru,

 

Thanks.

 

I think that we do need = an example in the draft of how to do this = though….

 

IPv6 will not be using = flags, but looking instead for the next header of protocol = 44.

 

Regards

 

Jon

 

From: Dots [mailto:ietf-supjps-dots= -bounces@ietf.org] On Behalf Of Konda, Tirumaleswar = Reddy
Sent: 13 April 2018 13:25
To: Jon Shallow; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: Re: = [Dots] Data Channel ACL fragments

 

[Jon6] – Yes – I stand = corrected, your ordering is correct.  A2 no longer needs = destination-port.

 

Yup. The summary of our discussion = is to use the flags defined in netmod-acl-model to drop fragments (both = initial and non-initial), and v4-fragments and v6-fragments and the = associated text added to drop non-initial fragments discussed in Section = 4.1 will be removed from the draft.

 

Cheers

-Tiru

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Friday, April 13, 2018 3:39 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: RE: = [Dots] Data Channel ACL fragments

 

Hi = Tiru,

 

See inline = [Jon6]

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 13 April 2018 = 10:03
To: Jon Shallow; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: Re: = [Dots] Data Channel ACL fragments

 

Hi = Jon,

 

Please see inline [TR4]

 

 

From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Kond= a@mcafee.com]
Sent: 10 April 2018 07:10
To: Jon = Shallow; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: RE: = [Dots] Data Channel ACL fragments

 

[Jon2] The = “flags->fragment” definition is ambiguous for an ACE (but = valid as to whether to allow a packet to get fragmented or not – = is that really a ACE?) which I would like to use.  =

 

[TR] I = don’t get it. What purpose does it serve to create a ACE rule = using “fragment” bit ?

[Jon3] = Agreed – This definition has not been thought through for an = ACE.  I think they have just emulated the DF bit in RFC791 as this = general flags definition is the same as for the flags in = RFC791.

 

[TR2] You may want to inform the authors of netmod-acl = draft, surprisingly BGP flowspec also uses “fragment” = bit.

[Jon4] On = my ToDo list for a clean solution.  But we do now have a solution = – see below.

 

 

“Flags->more” definition covers = all fragments but the last fragment... “Offset” is = unfortunately not a range, but otherwise would get used for the final = fragment.

~jon2

 

[TR] It = looks like two ACE entries are required to drop all the fragments = (“flags->more” set to 1 in the first ACE and = “flags->more” set to 0 in the second ACE). How to use the = “Offset”  field for the final fragment = ?

 

[Jon3] I = read “flags-more” to refer to the IP_MF in the IP header = (RFC791 MF or more-fragments flag).  This is set for all fragments = apart from the final (as in last part of packet, not the order in which = they are sent – fortunately that early decision to send them in = the wrong order was phased out, but still there in some legacy = systems!)

 

[TR2] Yes, why can’t “flags->more” be = set to 0 as one ACE entry to drop the final fragment along with = “flags->more” set to 1 to drop the first fragment as = another ACE entry so as to drop all fragments to the target = ?

[Jon4] If “flags->more” is = configured and it is configured with a value of 0, this will match not = only the final fragment, but also a non-fragmented packet.  If = “flags->more” is not configured, then this will match a = non-fragmented packet only.

 

[TR3] net-mod-acl says = "Setting the value to 0 indicates this is the last fragment, and = setting the value to 1 indicates more fragments are coming.". I = think it means, if “flags->more” is set to zero and = offset is not zero then it indicates this is the last fragments; the = flags can be used in isolation without comparing if offset value is zero = or non-zero. We should check with netmod-acl authors for confirmation. =

 

[Jon5].  The netmod-acl text for flags and = offset is effectively a word for word copy out of RFC791 3.1 Internet = Header Format.  So I think it is meant to be interpreted as being = an exact match for the same – including the offset specific = value.

 

  Flags:  3 = bits

 

    Various Control = Flags.

 

      Bit 0: reserved, = must be zero

      Bit 1: (DF) 0 =3D = May Fragment,  1 =3D Don't Fragment.

      Bit 2: (MF) 0 =3D = Last Fragment, 1 =3D More Fragments.

 

        &= nbsp; 0   1   2

        = +---+---+---+

        = |   | D | M |

        | 0 | = F | F |

        = +---+---+---+

 

  Fragment Offset:  13 = bits

 

    This field indicates where in = the datagram this fragment belongs.

 

    The fragment offset is = measured in units of 8 octets (64 bits).  = The

    first fragment has offset = zero.

 

 

----

 

Versus

 

----

    leaf flags = {

      type bits = {

        bit = reserved {

        &= nbsp; position 0;

        &= nbsp; description

        &= nbsp;   "Reserved. Must be = zero.";

        = }

        bit = fragment {

        &= nbsp; position 1;

        &= nbsp; description

        &= nbsp;   "Setting value to 0 indicates may fragment, while = setting

        &= nbsp;    the value to 1 indicates do not = fragment.";

        = }

        bit = more {

        &= nbsp; position 2;

        &= nbsp; description

        &= nbsp;   "Setting the value to 0 indicates this is the = last fragment,

        &= nbsp;    and setting the value to 1 indicates more = fragments are

        &= nbsp;    coming.";

        = }

      = }

      = description

        = "Bit definitions for the flags field in IPv4 = header.";

    }

 

    leaf offset = {

      type uint16 = {

        range = "20..65535";

      = }

 

      = description

        = "The fragment offset is measured in units of 8 octets (64 = bits).

         = The first fragment has offset zero. The length is 13 = bits";

    }

 

[Jon4] So, = a L4 ACE without “flags->more” defined and = “allow”, followed by an ACE with = “flags->more” =3D 1 and “drop”, followed by = an ACE with “flags->more” =3D 0 and “drop” = will cause all fragmented packets to get dropped, but still allow = through the non-fragmented packet.  So, we have a solution = for

“allow all traffic to port 53, but drop = all fragmented packets”.

 

[TR3] I don’t think the above = solution will work. In the above line, I think you  meant L3 ACE, = and the first fragment will match the first entry and is allowed. =

 

[Jon5]No, = the first ACE is a L3/L4 match.  If you have (a1 allows through all = non-fragmented packets, a2 & a3 drops all fragmented packets) the = following

 

[TR4] The first fragment will have both L3 and L4 = information, and matches a1 and is allowed, but if the order is changed = to a3, a1 and a2 (a3 will drop all fragments except last-fragment, the = last fragment will not have L4 info, so will not match a1 but will match = a2 and get dropped).

 

[Jon6] = – Yes – I stand corrected, your ordering is correct.  = A2 no longer needs destination-port.

~jon6

 

-Tiru

 

…

{

       = "aces": [{

        &= nbsp;           &n= bsp;           &nb= sp;    "ace": {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       "name": = "a1",

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       "matches": = [{

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          = "ipv4": {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =              = "destination-network": = "1.2.3.0/24"

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          = },

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          "udp": = {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =              = "destination-port": 53

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          = }

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       }],

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       "actions": = {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          = "forwarding": "accept"

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       }

        &= nbsp;           &n= bsp;           &nb= sp;    }

        &= nbsp;           &n= bsp; },

        &= nbsp;           &n= bsp; {

        &= nbsp;           &n= bsp;           &nb= sp;    "ace": {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       "name": = "a2",

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       "matches": = [{

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          = "ipv4": {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =              = "flags": {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;   "destination-network": = "1.2.3.0/24",

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;   "more": 0

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =              = },

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =              = "udp": {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;   "destination-port": = 53

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =              = }

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          = }

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       }],

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       "actions": = {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          = "forwarding": "drop"

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       }

 

        &= nbsp;           &n= bsp;           &nb= sp;    }

        &= nbsp;           &n= bsp; },

        &= nbsp;           &n= bsp; {

        &= nbsp;           &n= bsp;           &nb= sp;    "ace": {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       "name": = "a3",

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       "matches": = [{

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          = "ipv4": {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =              = "flags": {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;   "more": 1

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =              = }

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          = }

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       }],

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       "actions": = {

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;          = "forwarding": "drop"

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       }

        &= nbsp;           &n= bsp;           &nb= sp;    }

        &= nbsp;           &n= bsp; }

       = ]

}

…

[Jon5] It = will work

 

-Tiru

 

~jon4

 

-Tiru

 

[Jon3] But = as the final fragment of the sequence could have any offset, the use of = the offset field is not that helpful here.  Even if we do go with = our DOTS fragments definition (but widened to cover all fragments), we = still cannot generate a netmod-acl entry for onward processing by an = upstream mitigator.

 

[Jon3] FYI, = for Juniper, you just need to set ‘first-fragment’ and = ‘is-fragment’ in their ACL.  BGP FlowSpec does support = fragmentation detection properly (RFC5575 Type 12 = Fragment).

 

 

-Tiru

------=_NextPart_000_0061_01D3D59A.0A9FA1B0-- From nobody Mon Apr 16 08:08:35 2018 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 A225312DA0D; Mon, 16 Apr 2018 08:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MgQazxK-WBhZ; Mon, 16 Apr 2018 08:08:32 -0700 (PDT) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD97812D95B; Mon, 16 Apr 2018 08:08:31 -0700 (PDT) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 6C5E3120825; Mon, 16 Apr 2018 17:08:30 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.34]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 4632E160096; Mon, 16 Apr 2018 17:08:30 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6F.corporate.adroot.infra.ftgroup ([fe80::bd00:88f8:8552:3349%17]) with mapi id 14.03.0389.001; Mon, 16 Apr 2018 17:08:29 +0200 From: To: "draft-ietf-netmod-acl-model@ietf.org" CC: "dots@ietf.org" , "kwatsen@juniper.net" Thread-Topic: Mail regarding draft-ietf-netmod-acl-model Thread-Index: AdPVlMZLfgl8LrjkRwqP1O1MsxSS7A== Importance: high X-Priority: 1 Date: Mon, 16 Apr 2018 15:08:29 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DF0B7FE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93302DF0B7FEOPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: [Dots] Mail regarding draft-ietf-netmod-acl-model 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, 16 Apr 2018 15:08:34 -0000 --_000_787AE7BB302AE849A7480A190F8B93302DF0B7FEOPEXCLILMA3corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear authors, We do have a question regarding the interpretation of "protocol" when an IP= v6 match filter is applied because the draft is not clear. Can you please clarify whether "protocol" covers only the base IPv6 header = or it includes also "next header" of any enclosed Extension Header? For example, does the following ACL accept DNS packets + drop fragments eff= iciently? Does it work even if other EHs are preceding a Fragment header ? { "ietf-dots-data-channel:acls": { "acl": [ { "name": "dns-fragments", "type": "ipv6-acl-type", "aces": { "ace": [ { "name": "drop-all-fragments", "matches": { "ipv6": { "protocol": 44 } }, "actions": { "forwarding": "drop" } } ] "ace": [ { "name": "allow-dns-packets", "matches": { "ipv6": { "destination-ipv6-network": "2001:db8::/32" } "udp": { "destination-port": { "operator": "eq", "port": 53 } } }, "actions": { "forwarding": "accept" } } ] } } ] } } Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93302DF0B7FEOPEXCLILMA3corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear authors, 

 

We do have a question regarding the interpr= etation of “protocol” when an IPv6 match filter is applied beca= use the draft is not clear.

 

Can you please clarify whether “proto= col” covers only the base IPv6 header or it includes also “next= header” of any enclosed Extension Header?

 

For example, does the following ACL accept = DNS packets + drop fragments efficiently? Does it work even if other EH= s are preceding a Fragment header ?

 

{

  "ietf-dots-data-cha= nnel:acls": {

    "acl&qu= ot;: [

      = {

     &= nbsp;  "name": "dns-fragments",<= /p>

     &= nbsp;  "type": "ipv6-acl-type",<= /p>

     &= nbsp;  "aces": {

     &= nbsp;    "ace": [

     &= nbsp;      {

     &= nbsp;        "name": "dro= p-all-fragments",

     &= nbsp;        "matches": {=

     &= nbsp;          "ipv6"= ;: {

     &= nbsp;            &qu= ot;protocol": 44

     &= nbsp;          }

     &= nbsp;        },

     &= nbsp;        "actions": {=

     &= nbsp;          "forwardin= g": "drop"

     &= nbsp;        }

     &= nbsp;      }

     &= nbsp;    ]

     &= nbsp;    "ace": [

     &= nbsp;      {

     &= nbsp;        "name": "all= ow-dns-packets",

     &= nbsp;        "matches": {=

     &= nbsp;          "ipv6"= ;: {

     &= nbsp;            &qu= ot;destination-ipv6-network": "2001:db8::/32"

     &= nbsp;          }

       &nbs= p;        "udp": {<= /span>

       &nbs= p;          "destination-= port": {

       &nbs= p;            "= operator": "eq",

       &nbs= p;            "= port": 53

       &nbs= p;          }

     &= nbsp;          }

     &= nbsp;        },

     &= nbsp;        "actions": {=

     &= nbsp;          "forwardin= g": "accept"

     &= nbsp;        }

     &= nbsp;      }

     &= nbsp;    ]

     &= nbsp;  }

      = }

    ]=

  }

}

Cheers,

Med

--_000_787AE7BB302AE849A7480A190F8B93302DF0B7FEOPEXCLILMA3corp_-- From nobody Wed Apr 18 06:41:43 2018 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 C5D9112D869 for ; Wed, 18 Apr 2018 06:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tY5gwzeYIk56 for ; Wed, 18 Apr 2018 06:41:39 -0700 (PDT) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 105C412D7F8 for ; Wed, 18 Apr 2018 06:41:39 -0700 (PDT) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id C39D3406B9; Wed, 18 Apr 2018 15:41:37 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.43]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id A48151A009D; Wed, 18 Apr 2018 15:41:37 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5F.corporate.adroot.infra.ftgroup ([fe80::e172:f13e:8be6:71cc%18]) with mapi id 14.03.0389.001; Wed, 18 Apr 2018 15:41:37 +0200 From: To: Roman Danyliw CC: "dots@ietf.org" Thread-Topic: WGLC on DOTS Signal Channel Thread-Index: AdPA/2I8r8JGmyBkSmyI9HwbArIJBwP0jFcAAZI9xhA= Date: Wed, 18 Apr 2018 13:41:36 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DF0D65B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <359EC4B99E040048A7131E0F4E113AFC014C36B932@marathon> <359EC4B99E040048A7131E0F4E113AFC014C38025E@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC014C38025E@marathon> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] WGLC on DOTS Signal Channel 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: Wed, 18 Apr 2018 13:41:41 -0000 Hi Roman,=20 Can I assume that the consensus is reached for this document and that the n= ext step is to send it to IESG ?=20 Thank you.=20 Chees, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Roman Danyliw > Envoy=E9=A0: mardi 10 avril 2018 15:43 > =C0=A0: dots@ietf.org > Objet=A0: Re: [Dots] WGLC on DOTS Signal Channel >=20 > Hello! >=20 > The WGLC last call on this draft closed this past Friday, April 6. Thank= you > for all of your input. The authors continue to work on resolving > comments/feedback and will publish a new draft that captures this input. >=20 > Thanks, > Roman >=20 > > -----Original Message----- > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Roman Danyliw > > Sent: Wednesday, March 21, 2018 6:33 AM > > To: dots@ietf.org > > Subject: [Dots] WGLC on DOTS Signal Channel > > > > Hello! > > > > Consistent with our discussion at the London meeting, we are starting a > > working group last call (WGLC) for the DOTS Signal Channel draft: > > > > DOTS Signal Channel Specification > > draft-ietf-dots-signal-channel-18 > > https://tools.ietf.org/html/draft-ietf-dots-signal-channel-18 > > > > Please send comments to the DOTS mailing list -- feedback on remaining > > issues or needed changes; as well as endorsements that this draft is re= ady. > > > > This WGLC will end on April 6, 2018. > > > > Thanks, > > Roman > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Thu Apr 19 00:15:11 2018 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 EC56912D77C; Thu, 19 Apr 2018 00:15:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.78.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152412210993.28757.3397813391525813816@ietfa.amsl.com> Date: Thu, 19 Apr 2018 00:15:09 -0700 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-data-channel-15.txt 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: Thu, 19 Apr 2018 07:15:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DDoS Open Threat Signaling WG of the IETF. Title : Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification Authors : Tirumaleswar Reddy Mohamed Boucadair Kaname Nishizuka Liang Xia Prashanth Patil Andrew Mortensen Nik Teague Filename : draft-ietf-dots-data-channel-15.txt Pages : 59 Date : 2018-04-19 Abstract: The document specifies a Distributed Denial-of-Service Open Threat Signaling (DOTS) data channel used for bulk exchange of data that cannot easily or appropriately communicated through the DOTS signal channel under attack conditions. This is a companion document to the DOTS signal channel specification. Editorial Note (To be removed by RFC Editor) Please update these statements with the RFC number to be assigned to this document: o "This version of this YANG module is part of RFC XXXX;" o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification"; o reference: RFC XXXX Please update these statements with the RFC number to be assigned to the following documents: o "RFC YYYY: Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification" (used to be [I-D.ietf-dots-signal-channel]) o "RFC ZZZZ: Network Access Control List (ACL) YANG Data Model" (used to be [I-D.ietf-netmod-acl-model]) Please update the "revision" date of the YANG module. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-data-channel/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-data-channel-15 https://datatracker.ietf.org/doc/html/draft-ietf-dots-data-channel-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-data-channel-15 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Apr 19 00:24:19 2018 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 AAE9512D77B for ; Thu, 19 Apr 2018 00:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 uPK-jDPN8R7W for ; Thu, 19 Apr 2018 00:24:15 -0700 (PDT) Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 503B112422F for ; Thu, 19 Apr 2018 00:24:15 -0700 (PDT) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 2E3E9C0881 for ; Thu, 19 Apr 2018 09:24:14 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.62]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 162D9120076 for ; Thu, 19 Apr 2018 09:24:14 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5E.corporate.adroot.infra.ftgroup ([fe80::2912:bfa5:91d3:bf63%18]) with mapi id 14.03.0389.001; Thu, 19 Apr 2018 09:24:13 +0200 From: To: "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-data-channel-15.txt Thread-Index: AQHT164qdKBeO1PbP0WAbRfF3wBcYqQHrSdQ Date: Thu, 19 Apr 2018 07:24:13 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DF0DC8F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <152412210993.28757.3397813391525813816@ietfa.amsl.com> In-Reply-To: <152412210993.28757.3397813391525813816@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-data-channel-15.txt 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, 19 Apr 2018 07:24:17 -0000 Hi all,=20 This new version integrates the outcome of the discussion related to the ha= ndling of IPv4 fragments. An appendix is added to illustrate examples with = fragment handling.=20 A keyword is still present for the IPv6 given that the netmod-acl specifica= tion is not clear whether "protocol" covers the base header and "next-heade= r" of any enclosed header. Authors/shepherded of the netmod-acl I-D was con= tacted to clarify this; no feedback from them (yet).=20 We received an offline comment from Jon asking to change "rate-limit decima= l64" to "uint32" or "uint64", but we didn't implemented any change at this = stage because the use of decimal64 is aligned with RFC5575 and also the for= mat used for rate definition in other RFCs such as https://tools.ietf.org/h= tml/rfc2212. If you think that in the context of DOTS, we don't need to ali= gn with existing specs or that in the context of massive DDoS, we don't nee= d to concern ourselves with sub byte precision, please let us know.=20 Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de internet- > drafts@ietf.org > Envoy=E9=A0: jeudi 19 avril 2018 09:15 > =C0=A0: i-d-announce@ietf.org > Cc=A0: dots@ietf.org > Objet=A0: [Dots] I-D Action: draft-ietf-dots-data-channel-15.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the DDoS Open Threat Signaling WG of the IET= F. >=20 > Title : Distributed Denial-of-Service Open Threat Signa= ling > (DOTS) Data Channel Specification > Authors : Tirumaleswar Reddy > Mohamed Boucadair > Kaname Nishizuka > Liang Xia > Prashanth Patil > Andrew Mortensen > Nik Teague > Filename : draft-ietf-dots-data-channel-15.txt > Pages : 59 > Date : 2018-04-19 >=20 > Abstract: > The document specifies a Distributed Denial-of-Service Open Threat > Signaling (DOTS) data channel used for bulk exchange of data that > cannot easily or appropriately communicated through the DOTS signal > channel under attack conditions. >=20 > This is a companion document to the DOTS signal channel > specification. >=20 > Editorial Note (To be removed by RFC Editor) >=20 > Please update these statements with the RFC number to be assigned to > this document: >=20 > o "This version of this YANG module is part of RFC XXXX;" >=20 > o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling > (DOTS) Data Channel Specification"; >=20 > o reference: RFC XXXX >=20 > Please update these statements with the RFC number to be assigned to > the following documents: >=20 > o "RFC YYYY: Distributed Denial-of-Service Open Threat Signaling > (DOTS) Signal Channel Specification" (used to be > [I-D.ietf-dots-signal-channel]) >=20 > o "RFC ZZZZ: Network Access Control List (ACL) YANG Data Model" > (used to be [I-D.ietf-netmod-acl-model]) >=20 > Please update the "revision" date of the YANG module. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dots-data-channel/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dots-data-channel-15 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-data-channel-15 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-data-channel-15 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Thu Apr 19 03:53:12 2018 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 9755B1274D2 for ; Thu, 19 Apr 2018 03:53:11 -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, 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 1UTGP3Co4vbt for ; Thu, 19 Apr 2018 03:53:09 -0700 (PDT) Received: from guri.nttv6.jp (guri.nttv6.jp [115.69.228.140]) by ietfa.amsl.com (Postfix) with ESMTP id C1BFD1205D3 for ; Thu, 19 Apr 2018 03:53:08 -0700 (PDT) Received: from z.nttv6.jp (z.nttv6.jp [192.168.8.15]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id CD20125F691; Thu, 19 Apr 2018 19:53:07 +0900 (JST) Received: from MacBook-Pro-17.local (fujiko.nttv6.jp [115.69.228.141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id B1C6B76350F; Thu, 19 Apr 2018 19:53:07 +0900 (JST) To: mohamed.boucadair@orange.com, "dots@ietf.org" References: <152412210993.28757.3397813391525813816@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302DF0DC8F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: kaname nishizuka Message-ID: <17702edf-28b6-caa3-af8c-5acfe91dee4c@nttv6.jp> Date: Thu, 19 Apr 2018 19:53:07 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DF0DC8F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-data-channel-15.txt 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, 19 Apr 2018 10:53:12 -0000 Hi Med, Thank you for updating the draft. I'd like to note 2 typos. Figure 19: An Example of Response Body - "traffic-protocol": [ + "target-protocol": [ Figure 23: Reply to a GET Response with Filtering Capabilities - "rate-limit": "true", + "rate-limit": true, (it's boolean) And please consider to put the latest draft on github repo of dotswg and keep it to be latest in order to make this kind of tiny pull request easily merged. https://github.com/dotswg/dots-data-channel thank you, Kaname On 2018/04/19 16:24, mohamed.boucadair@orange.com wrote: > Hi all, > > This new version integrates the outcome of the discussion related to the handling of IPv4 fragments. An appendix is added to illustrate examples with fragment handling. > > A keyword is still present for the IPv6 given that the netmod-acl specification is not clear whether "protocol" covers the base header and "next-header" of any enclosed header. Authors/shepherded of the netmod-acl I-D was contacted to clarify this; no feedback from them (yet). > > We received an offline comment from Jon asking to change "rate-limit decimal64" to "uint32" or "uint64", but we didn't implemented any change at this stage because the use of decimal64 is aligned with RFC5575 and also the format used for rate definition in other RFCs such as https://tools.ietf.org/html/rfc2212. If you think that in the context of DOTS, we don't need to align with existing specs or that in the context of massive DDoS, we don't need to concern ourselves with sub byte precision, please let us know. > > Cheers, > Med > >> -----Message d'origine----- >> De : Dots [mailto:dots-bounces@ietf.org] De la part de internet- >> drafts@ietf.org >> Envoyé : jeudi 19 avril 2018 09:15 >> À : i-d-announce@ietf.org >> Cc : dots@ietf.org >> Objet : [Dots] I-D Action: draft-ietf-dots-data-channel-15.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the DDoS Open Threat Signaling WG of the IETF. >> >> Title : Distributed Denial-of-Service Open Threat Signaling >> (DOTS) Data Channel Specification >> Authors : Tirumaleswar Reddy >> Mohamed Boucadair >> Kaname Nishizuka >> Liang Xia >> Prashanth Patil >> Andrew Mortensen >> Nik Teague >> Filename : draft-ietf-dots-data-channel-15.txt >> Pages : 59 >> Date : 2018-04-19 >> >> Abstract: >> The document specifies a Distributed Denial-of-Service Open Threat >> Signaling (DOTS) data channel used for bulk exchange of data that >> cannot easily or appropriately communicated through the DOTS signal >> channel under attack conditions. >> >> This is a companion document to the DOTS signal channel >> specification. >> >> Editorial Note (To be removed by RFC Editor) >> >> Please update these statements with the RFC number to be assigned to >> this document: >> >> o "This version of this YANG module is part of RFC XXXX;" >> >> o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling >> (DOTS) Data Channel Specification"; >> >> o reference: RFC XXXX >> >> Please update these statements with the RFC number to be assigned to >> the following documents: >> >> o "RFC YYYY: Distributed Denial-of-Service Open Threat Signaling >> (DOTS) Signal Channel Specification" (used to be >> [I-D.ietf-dots-signal-channel]) >> >> o "RFC ZZZZ: Network Access Control List (ACL) YANG Data Model" >> (used to be [I-D.ietf-netmod-acl-model]) >> >> Please update the "revision" date of the YANG module. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-dots-data-channel/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-dots-data-channel-15 >> https://datatracker.ietf.org/doc/html/draft-ietf-dots-data-channel-15 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-data-channel-15 >> >> >> 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. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> Dots mailing list >> Dots@ietf.org >> https://www.ietf.org/mailman/listinfo/dots > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Thu Apr 19 05:12:34 2018 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 C990612D95B for ; Thu, 19 Apr 2018 05:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 kxBf0bDnLIiw for ; Thu, 19 Apr 2018 05:12:26 -0700 (PDT) Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E15F612D959 for ; Thu, 19 Apr 2018 05:12:25 -0700 (PDT) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 31B3C1C0A4E; Thu, 19 Apr 2018 14:12:24 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.3]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 119A7160075; Thu, 19 Apr 2018 14:12:24 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5D.corporate.adroot.infra.ftgroup ([fe80::9898:741c:bc1d:258d%19]) with mapi id 14.03.0389.001; Thu, 19 Apr 2018 14:12:23 +0200 From: To: kaname nishizuka , "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-data-channel-15.txt Thread-Index: AQHT18yd8UgNJTVeqkiYvnBsTI7yUqQH/10w Date: Thu, 19 Apr 2018 12:12:23 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DF0DE70@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <152412210993.28757.3397813391525813816@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302DF0DC8F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <17702edf-28b6-caa3-af8c-5acfe91dee4c@nttv6.jp> In-Reply-To: <17702edf-28b6-caa3-af8c-5acfe91dee4c@nttv6.jp> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-data-channel-15.txt 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, 19 Apr 2018 12:12:30 -0000 SGkgS2FuYW1lLCANCg0KVGhhbmsgeW91IGZvciBjYXRjaGluZyB0aG9zZS4gDQoNCkZpeGVkLiBQ bGVhc2VkIGNoZWNrIGF0IGh0dHBzOi8vZ2l0aHViLmNvbS9ib3VjYWRhaXIvZHJhZnQtaWV0Zi1k b3RzLWRhdGEtY2hhbm5lbC4gDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVzc2FnZSBkJ29y aWdpbmUtLS0tLQ0KPiBEZcKgOiBrYW5hbWUgbmlzaGl6dWthIFttYWlsdG86a2FuYW1lQG50dHY2 LmpwXQ0KPiBFbnZvecOpwqA6IGpldWRpIDE5IGF2cmlsIDIwMTggMTI6NTMNCj4gw4DCoDogQk9V Q0FEQUlSIE1vaGFtZWQgSU1UL09MTjsgZG90c0BpZXRmLm9yZw0KPiBPYmpldMKgOiBSZTogW0Rv dHNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtZG90cy1kYXRhLWNoYW5uZWwtMTUudHh0DQo+IA0K PiBIaSBNZWQsDQo+IA0KPiBUaGFuayB5b3UgZm9yIHVwZGF0aW5nIHRoZSBkcmFmdC4NCj4gSSdk IGxpa2UgdG8gbm90ZSAyIHR5cG9zLg0KPiANCj4gRmlndXJlIDE5OiBBbiBFeGFtcGxlIG9mIFJl c3BvbnNlIEJvZHkNCj4gLSAidHJhZmZpYy1wcm90b2NvbCI6IFsNCj4gKyAidGFyZ2V0LXByb3Rv Y29sIjogWw0KPiANCj4gRmlndXJlIDIzOiBSZXBseSB0byBhIEdFVCBSZXNwb25zZSB3aXRoIEZp bHRlcmluZyBDYXBhYmlsaXRpZXMNCj4gLSAicmF0ZS1saW1pdCI6ICJ0cnVlIiwNCj4gKyAicmF0 ZS1saW1pdCI6IHRydWUsDQo+IChpdCdzIGJvb2xlYW4pDQo+IA0KPiBBbmQgcGxlYXNlIGNvbnNp ZGVyIHRvIHB1dCB0aGUgbGF0ZXN0IGRyYWZ0IG9uIGdpdGh1YiByZXBvIG9mIGRvdHN3ZyBhbmQg a2VlcA0KPiBpdCB0byBiZSBsYXRlc3QgaW4gb3JkZXIgdG8gbWFrZSB0aGlzIGtpbmQgb2YgdGlu eSBwdWxsIHJlcXVlc3QgZWFzaWx5DQo+IG1lcmdlZC4NCj4gaHR0cHM6Ly9naXRodWIuY29tL2Rv dHN3Zy9kb3RzLWRhdGEtY2hhbm5lbA0KPiANCj4gdGhhbmsgeW91LA0KPiBLYW5hbWUNCj4gDQo+ IE9uIDIwMTgvMDQvMTkgMTY6MjQsIG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20gd3JvdGU6 DQo+ID4gSGkgYWxsLA0KPiA+DQo+ID4gVGhpcyBuZXcgdmVyc2lvbiBpbnRlZ3JhdGVzIHRoZSBv dXRjb21lIG9mIHRoZSBkaXNjdXNzaW9uIHJlbGF0ZWQgdG8gdGhlDQo+IGhhbmRsaW5nIG9mIElQ djQgZnJhZ21lbnRzLiBBbiBhcHBlbmRpeCBpcyBhZGRlZCB0byBpbGx1c3RyYXRlIGV4YW1wbGVz IHdpdGgNCj4gZnJhZ21lbnQgaGFuZGxpbmcuDQo+ID4NCj4gPiBBIGtleXdvcmQgaXMgc3RpbGwg cHJlc2VudCBmb3IgdGhlIElQdjYgZ2l2ZW4gdGhhdCB0aGUgbmV0bW9kLWFjbA0KPiBzcGVjaWZp Y2F0aW9uIGlzIG5vdCBjbGVhciB3aGV0aGVyICJwcm90b2NvbCIgY292ZXJzIHRoZSBiYXNlIGhl YWRlciBhbmQNCj4gIm5leHQtaGVhZGVyIiBvZiBhbnkgZW5jbG9zZWQgaGVhZGVyLiBBdXRob3Jz L3NoZXBoZXJkZWQgb2YgdGhlIG5ldG1vZC1hY2wgSS0NCj4gRCB3YXMgY29udGFjdGVkIHRvIGNs YXJpZnkgdGhpczsgbm8gZmVlZGJhY2sgZnJvbSB0aGVtICh5ZXQpLg0KPiA+DQo+ID4gV2UgcmVj ZWl2ZWQgYW4gb2ZmbGluZSBjb21tZW50IGZyb20gSm9uIGFza2luZyB0byBjaGFuZ2UgInJhdGUt bGltaXQNCj4gZGVjaW1hbDY0IiB0byAidWludDMyIiBvciAidWludDY0IiwgYnV0IHdlIGRpZG4n dCBpbXBsZW1lbnRlZCBhbnkgY2hhbmdlIGF0DQo+IHRoaXMgc3RhZ2UgYmVjYXVzZSB0aGUgdXNl IG9mIGRlY2ltYWw2NCBpcyBhbGlnbmVkIHdpdGggUkZDNTU3NSBhbmQgYWxzbyB0aGUNCj4gZm9y bWF0IHVzZWQgZm9yIHJhdGUgZGVmaW5pdGlvbiBpbiBvdGhlciBSRkNzIHN1Y2ggYXMNCj4gaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzIyMTIuIElmIHlvdSB0aGluayB0aGF0IGluIHRo ZSBjb250ZXh0IG9mDQo+IERPVFMsIHdlIGRvbid0IG5lZWQgdG8gYWxpZ24gd2l0aCBleGlzdGlu ZyBzcGVjcyBvciB0aGF0IGluIHRoZSBjb250ZXh0IG9mDQo+IG1hc3NpdmUgRERvUywgd2UgZG9u J3QgbmVlZCB0byBjb25jZXJuIG91cnNlbHZlcyB3aXRoIHN1YiBieXRlIHByZWNpc2lvbiwNCj4g cGxlYXNlIGxldCB1cyBrbm93Lg0KPiA+DQo+ID4gQ2hlZXJzLA0KPiA+IE1lZA0KPiA+DQo+ID4+ IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiA+PiBEZcKgOiBEb3RzIFttYWlsdG86ZG90 cy1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIGludGVybmV0LQ0KPiA+PiBkcmFmdHNA aWV0Zi5vcmcNCj4gPj4gRW52b3nDqcKgOiBqZXVkaSAxOSBhdnJpbCAyMDE4IDA5OjE1DQo+ID4+ IMOAwqA6IGktZC1hbm5vdW5jZUBpZXRmLm9yZw0KPiA+PiBDY8KgOiBkb3RzQGlldGYub3JnDQo+ ID4+IE9iamV0wqA6IFtEb3RzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWRvdHMtZGF0YS1jaGFu bmVsLTE1LnR4dA0KPiA+Pg0KPiA+Pg0KPiA+PiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFp bGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMNCj4gPj4gZGlyZWN0b3JpZXMu DQo+ID4+IFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIEREb1MgT3BlbiBUaHJlYXQg U2lnbmFsaW5nIFdHIG9mIHRoZQ0KPiBJRVRGLg0KPiA+Pg0KPiA+PiAgICAgICAgICBUaXRsZSAg ICAgICAgICAgOiBEaXN0cmlidXRlZCBEZW5pYWwtb2YtU2VydmljZSBPcGVuIFRocmVhdA0KPiBT aWduYWxpbmcNCj4gPj4gKERPVFMpIERhdGEgQ2hhbm5lbCBTcGVjaWZpY2F0aW9uDQo+ID4+ICAg ICAgICAgIEF1dGhvcnMgICAgICAgICA6IFRpcnVtYWxlc3dhciBSZWRkeQ0KPiA+PiAgICAgICAg ICAgICAgICAgICAgICAgICAgICBNb2hhbWVkIEJvdWNhZGFpcg0KPiA+PiAgICAgICAgICAgICAg ICAgICAgICAgICAgICBLYW5hbWUgTmlzaGl6dWthDQo+ID4+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgIExpYW5nIFhpYQ0KPiA+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICBQcmFzaGFu dGggUGF0aWwNCj4gPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgQW5kcmV3IE1vcnRlbnNl bg0KPiA+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICBOaWsgVGVhZ3VlDQo+ID4+IAlGaWxl bmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLWRvdHMtZGF0YS1jaGFubmVsLTE1LnR4dA0KPiA+PiAJ UGFnZXMgICAgICAgICAgIDogNTkNCj4gPj4gCURhdGUgICAgICAgICAgICA6IDIwMTgtMDQtMTkN Cj4gPj4NCj4gPj4gQWJzdHJhY3Q6DQo+ID4+ICAgICBUaGUgZG9jdW1lbnQgc3BlY2lmaWVzIGEg RGlzdHJpYnV0ZWQgRGVuaWFsLW9mLVNlcnZpY2UgT3BlbiBUaHJlYXQNCj4gPj4gICAgIFNpZ25h bGluZyAoRE9UUykgZGF0YSBjaGFubmVsIHVzZWQgZm9yIGJ1bGsgZXhjaGFuZ2Ugb2YgZGF0YSB0 aGF0DQo+ID4+ICAgICBjYW5ub3QgZWFzaWx5IG9yIGFwcHJvcHJpYXRlbHkgY29tbXVuaWNhdGVk IHRocm91Z2ggdGhlIERPVFMgc2lnbmFsDQo+ID4+ICAgICBjaGFubmVsIHVuZGVyIGF0dGFjayBj b25kaXRpb25zLg0KPiA+Pg0KPiA+PiAgICAgVGhpcyBpcyBhIGNvbXBhbmlvbiBkb2N1bWVudCB0 byB0aGUgRE9UUyBzaWduYWwgY2hhbm5lbA0KPiA+PiAgICAgc3BlY2lmaWNhdGlvbi4NCj4gPj4N Cj4gPj4gRWRpdG9yaWFsIE5vdGUgKFRvIGJlIHJlbW92ZWQgYnkgUkZDIEVkaXRvcikNCj4gPj4N Cj4gPj4gICAgIFBsZWFzZSB1cGRhdGUgdGhlc2Ugc3RhdGVtZW50cyB3aXRoIHRoZSBSRkMgbnVt YmVyIHRvIGJlIGFzc2lnbmVkIHRvDQo+ID4+ICAgICB0aGlzIGRvY3VtZW50Og0KPiA+Pg0KPiA+ PiAgICAgbyAgIlRoaXMgdmVyc2lvbiBvZiB0aGlzIFlBTkcgbW9kdWxlIGlzIHBhcnQgb2YgUkZD IFhYWFg7Ig0KPiA+Pg0KPiA+PiAgICAgbyAgIlJGQyBYWFhYOiBEaXN0cmlidXRlZCBEZW5pYWwt b2YtU2VydmljZSBPcGVuIFRocmVhdCBTaWduYWxpbmcNCj4gPj4gICAgICAgIChET1RTKSBEYXRh IENoYW5uZWwgU3BlY2lmaWNhdGlvbiI7DQo+ID4+DQo+ID4+ICAgICBvICByZWZlcmVuY2U6IFJG QyBYWFhYDQo+ID4+DQo+ID4+ICAgICBQbGVhc2UgdXBkYXRlIHRoZXNlIHN0YXRlbWVudHMgd2l0 aCB0aGUgUkZDIG51bWJlciB0byBiZSBhc3NpZ25lZCB0bw0KPiA+PiAgICAgdGhlIGZvbGxvd2lu ZyBkb2N1bWVudHM6DQo+ID4+DQo+ID4+ICAgICBvICAiUkZDIFlZWVk6IERpc3RyaWJ1dGVkIERl bmlhbC1vZi1TZXJ2aWNlIE9wZW4gVGhyZWF0IFNpZ25hbGluZw0KPiA+PiAgICAgICAgKERPVFMp IFNpZ25hbCBDaGFubmVsIFNwZWNpZmljYXRpb24iICh1c2VkIHRvIGJlDQo+ID4+ICAgICAgICBb SS1ELmlldGYtZG90cy1zaWduYWwtY2hhbm5lbF0pDQo+ID4+DQo+ID4+ICAgICBvICAiUkZDIFpa Wlo6IE5ldHdvcmsgQWNjZXNzIENvbnRyb2wgTGlzdCAoQUNMKSBZQU5HIERhdGEgTW9kZWwiDQo+ ID4+ICAgICAgICAodXNlZCB0byBiZSBbSS1ELmlldGYtbmV0bW9kLWFjbC1tb2RlbF0pDQo+ID4+ DQo+ID4+ICAgICBQbGVhc2UgdXBkYXRlIHRoZSAicmV2aXNpb24iIGRhdGUgb2YgdGhlIFlBTkcg bW9kdWxlLg0KPiA+Pg0KPiA+Pg0KPiA+PiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFn ZSBmb3IgdGhpcyBkcmFmdCBpczoNCj4gPj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaWV0Zi1kb3RzLWRhdGEtY2hhbm5lbC8NCj4gPj4NCj4gPj4gVGhlcmUgYXJlIGFs c28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KPiA+PiBodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1kb3RzLWRhdGEtY2hhbm5lbC0xNQ0KPiA+PiBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtZG90cy1kYXRhLWNoYW5u ZWwtMTUNCj4gPj4NCj4gPj4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZh aWxhYmxlIGF0Og0KPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQt aWV0Zi1kb3RzLWRhdGEtY2hhbm5lbC0xNQ0KPiA+Pg0KPiA+Pg0KPiA+PiBQbGVhc2Ugbm90ZSB0 aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0KPiBz dWJtaXNzaW9uDQo+ID4+IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBh dmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+ID4+DQo+ID4+IEludGVybmV0LURyYWZ0cyBh cmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4gPj4gZnRwOi8vZnRwLmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4gPj4NCj4gPj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gRG90cyBtYWlsaW5nIGxpc3QNCj4gPj4g RG90c0BpZXRmLm9yZw0KPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2RvdHMNCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiA+IERvdHMgbWFpbGluZyBsaXN0DQo+ID4gRG90c0BpZXRmLm9yZw0KPiA+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90cw0KDQo= From nobody Thu Apr 19 12:17:17 2018 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 D8AB01270B4; Thu, 19 Apr 2018 12:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 0F6JeUH7jRoR; Thu, 19 Apr 2018 12:17:14 -0700 (PDT) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6FBF12DA50; Thu, 19 Apr 2018 12:17:13 -0700 (PDT) Received: by mail-pf0-x232.google.com with SMTP id f15so3100306pfn.0; Thu, 19 Apr 2018 12:17:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=Lkpf7dzElDdsLEPWoZe1u7ERnHbmTSGc1w87FOgKE5U=; b=LB7sZNu7ysMKEk9SK2f4VTwJqXUEOAzsHqxf9HmxEParafBU+g99sNbF2a3dfPuWWd xH9LRIjQ8E2H6BeSNa2D+WNN9V7VQGN3f3+ucKqJP82zHfREfUKTFqgLnz70JMTA/EHD YC28ippqm3bKIIFtHzi4FSQDsbtZHYOR5yxHeXjlKhzXPL8qF7NYwLkPiJ6K5RYCi3xV PulNPowSl/i4wLDjpUJ1b+47Lnot+Bf7zuCXSU3rd1FT7tk08kPwvklUa7/Gs3x/1GA+ gfa7UyRdpMzmpSno6zp1tP9z0geyHWBPyma4tcx6O3z99EtfG5l/VqVRvpzenV3aYNLv CIcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=Lkpf7dzElDdsLEPWoZe1u7ERnHbmTSGc1w87FOgKE5U=; b=efawv20Q+XE/tkRpWV4bqck5vMhDy86RfdEDRVx3BdRZH4T6esh5F6FTANS6VhQ+mu 2cyzgzOd4p6LfXEtTyJ9Y5Shf9Ak4iH8BoubEn58au4ja4txJ8l687BLmzwI6BGtVpxF 7fuXQ3Pg1I/3hqS5xEMMLgRpvzLoXang0jXay3Dh42PhmFgTIcpfi328X1L0qXvQazhJ 2dwkAH5/c3V+3vivMHvofPfds0lrw/qFNBXaiGXUtoSoIy8MOSK6XEbC8yMh2iKWFKT9 43634XCnxATxT5u5dZ2dIjj7XWjnsJoHMg9plD6772tMShwSY6/sYAyuyZxnloXMTZwE bHNA== X-Gm-Message-State: ALQs6tCkki4tyGkMZOwi8E5CK0hxCTuI7zLWMBC3XnE68KQlNrYsWQxE /xlilfdedfc2etTlEZQicvY= X-Google-Smtp-Source: AIpwx4+QL7ssgas7sbQTZsBp5WnObwyayxkfnMG7CP2Bdni+d3gP1GIBhesK8kyXMmso+NuAwcvJng== X-Received: by 10.99.164.18 with SMTP id c18mr6091464pgf.85.1524165433190; Thu, 19 Apr 2018 12:17:13 -0700 (PDT) Received: from ?IPv6:2601:647:4700:1280:dde1:aceb:94f7:e0c6? ([2601:647:4700:1280:dde1:aceb:94f7:e0c6]) by smtp.gmail.com with ESMTPSA id s65sm11767187pfj.124.2018.04.19.12.17.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Apr 2018 12:17:12 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_6B1D23C7-C9AB-4441-BC50-F32A8D4157C7" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Mahesh Jethanandani X-Priority: 1 In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DF0B7FE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Thu, 19 Apr 2018 12:17:11 -0700 Cc: "draft-ietf-netmod-acl-model@ietf.org" , "dots@ietf.org" , Kent Watsen Message-Id: References: <787AE7BB302AE849A7480A190F8B93302DF0B7FE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> To: mohamed.boucadair@orange.com X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [Dots] Mail regarding draft-ietf-netmod-acl-model 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, 19 Apr 2018 19:17:16 -0000 --Apple-Mail=_6B1D23C7-C9AB-4441-BC50-F32A8D4157C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Mohamed, While I wait for my co-authors to get back to me, here is my take on = this. > On Apr 16, 2018, at 8:08 AM, = wrote: >=20 > Dear authors,=20 > =20 > We do have a question regarding the interpretation of =E2=80=9Cprotocol=E2= =80=9D when an IPv6 match filter is applied because the draft is not = clear. > =20 > Can you please clarify whether =E2=80=9Cprotocol=E2=80=9D covers only = the base IPv6 header or it includes also =E2=80=9Cnext header=E2=80=9D = of any enclosed Extension Header? The current draft covers only the base IPv6 header. It does not cover = Extension Headers.=20 If there is such a requirement, we will have to take it up in the bis = version of this draft. > =20 > For example, does the following ACL accept DNS packets + drop = fragments efficiently? Does it work even if other EHs are preceding a = Fragment header ? > =20 > { > "ietf-dots-data-channel:acls": { > "acl": [ > { > "name": "dns-fragments", > "type": "ipv6-acl-type", > "aces": { > "ace": [ > { > "name": "drop-all-fragments", > "matches": { > "ipv6": { > "protocol": 44 > } > }, > "actions": { > "forwarding": "drop" > } > } > ] > "ace": [ > { > "name": "allow-dns-packets", > "matches": { > "ipv6": { > "destination-ipv6-network": "2001:db8::/32" > } > "udp": { > "destination-port": { > "operator": "eq", > "port": 53 > } > } > }, > "actions": { > "forwarding": "accept" > } > } > ] > } > } > ] > } > } Again, my personal take on it (and I will wait for my co-authors to = correct me if I am wrong), is that these are two separate entries. = Depending on the order of the rules, and again assuming the rules are in = the order stated above, if you do receive a fragmented DNS packet, the = second rule will never be hit. The first rule would apply and the packet = will be dropped. If the rules are reversed, then all DNS packets to IPv6 = address 2001:db8::/32 will be accepted, whether they are fragmented or = not. Cheers. > Cheers, > Med Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_6B1D23C7-C9AB-4441-BC50-F32A8D4157C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Mohamed,

While I wait for my co-authors to get back to me, here is my = take on this.

On Apr 16, 2018, at 8:08 AM, <mohamed.boucadair@orange.com> <mohamed.boucadair@orange.com> wrote:

Dear authors, 
 
We do have a = question regarding the interpretation of =E2=80=9Cprotocol=E2=80=9D when = an IPv6 match filter is applied because the draft is not clear.
 
Can you please = clarify whether =E2=80=9Cprotocol=E2=80=9D covers only the base IPv6 = header or it includes also =E2=80=9Cnext header=E2=80=9D of any enclosed = Extension Header?

The current draft covers only the base IPv6 header. It = does not cover Extension Headers. 

If there is such a requirement, we will have to = take it up in the bis version of this draft.

 
For example, does the following ACL = accept DNS packets + drop fragments efficiently? Does it work even if = other EHs are preceding a Fragment header ?
 
{
  "ietf-dots-data-channel:acls": {
    "acl": [
      {
        = "name": "dns-fragments",
        "type": = "ipv6-acl-type",
        "aces": {
          "ace": = [
          &nb= sp; {
          &nb= sp;   "name": "drop-all-fragments",
          &nb= sp;   "matches": {
          &nb= sp;     "ipv6": {
          &nb= sp;       "protocol": 44
          &nb= sp;     }
          &nb= sp;   },
          &nb= sp;   "actions": {
          &nb= sp;     "forwarding": "drop"
          &nb= sp;   }
          &nb= sp; }
          ]
          "ace": = [
          &nb= sp; {
          &nb= sp;   "name": "allow-dns-packets",
          &nb= sp;   "matches": {
          &nb= sp;     "ipv6": {
          &nb= sp;       "destination-ipv6-network": = "2001:db8::/32"
          &nb= sp;     }
          &nb= sp;     "udp": {
          &nb= sp;       "destination-port": {
          &nb= sp;         "operator": = "eq",
          &nb= sp;         "port": 53
          &nb= sp;       }
          &nb= sp;     }
          &nb= sp;   },
          &nb= sp;   "actions": {
          &nb= sp;     "forwarding": "accept"
          &nb= sp;   }
          &nb= sp; }
          ]
        }
      }
    ]
  }
}

Again, my personal take on it (and I will wait for my = co-authors to correct me if I am wrong), is that these are two separate = entries. Depending on the order of the rules, and again assuming the = rules are in the order stated above, if you do receive a fragmented DNS = packet, the second rule will never be hit. The first rule would apply = and the packet will be dropped. If the rules are reversed, then all DNS = packets to IPv6 address 2001:db8::/32 will = be accepted, whether they are fragmented or not.

Cheers.

Cheers,
Med

Mahesh Jethanandani
mjethanandani@gmail.com

= --Apple-Mail=_6B1D23C7-C9AB-4441-BC50-F32A8D4157C7-- From nobody Thu Apr 19 16:35:25 2018 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 89A94126CF6; Thu, 19 Apr 2018 16:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.448 X-Spam-Level: X-Spam-Status: No, score=-1.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 DSQYymed-u6l; Thu, 19 Apr 2018 16:35:21 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6B46126CE8; Thu, 19 Apr 2018 16:35:20 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id 186-v6so464849itu.0; Thu, 19 Apr 2018 16:35:20 -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=oKfJAp+CClhpDNXmBSKYEBXtN4gtYVRXZfSUpBKsGyE=; b=PQokq6F4rTMS7ZHZEzmb/PAzir7g9GODu3v13hxQTgPXFB84mR7LxYUbLBUeVgg1yv Bwm7zKyFVwoS3whN1EEraKnBUUN/BR7iIJcv3nI4J+YZPni9ga2rViehGqLnM1PrENgS SOXJdpJuERmZrA2G5DDRWVswuVCKm6InHGsMVCaeSUVGN7jOMIwsrVv4+Qffk4WCl4Lw KjZLkqfXOLuaT5uSGcB0eqHuv0rXg6bhkZ3Ugjfa1eqNWWLOjann+RkxlLnDasBsDjfB kJu/QJ59Tr13K+h7gW9KY4eEak92Yqffc/epdKnnB15zb6kBw0HnePUp0tyOxdQnn3PU /Ang== 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=oKfJAp+CClhpDNXmBSKYEBXtN4gtYVRXZfSUpBKsGyE=; b=NfwSDvmhiSgCpayVljWmtRA1sY46s35JB3rxvxIUvWrn/iUi079zFoMu/iXDmLMI+Z ulnNUk71fhZIcdfoTReDL0leRtHPz1sg5MK2feRNxiSuG/UYkTIAIDn83JwqRkhMHrpO 23RH9eij0gyEVO2PVKD7Ij4+i+r8tpBEBj8I1EWwB9CgINPYnINl6BLJUJAs02qlC/04 PeJ36GtY/K2iofrum0DpKV9+kCgHS5MOQn/vVLfN3gGE2kBETzlE7zWpWK2bHnNhc1dE eUxZt97gRJbgaVjN++N4o0/YlK/VrehBA51a8EGuOTsklASuYBPuba1ojmOM9Cdstv8I XGpg== X-Gm-Message-State: ALQs6tChQca5Peq2iijhvKZvFsIMd9AMae6oD/Euy7GZD8mAMDGGdU2u gN85br0Chkn3DhnGKrIlhk5iQT+geavDqyhG+Lo= X-Google-Smtp-Source: AIpwx48FF04HFWyhQPQLN92PVZEmQ24fVtXC8BDJ13/h9yazbCkZEBFavGgRjijP+7bAspY+QmgPLWwZF8RpiA01pHI= X-Received: by 2002:a24:3941:: with SMTP id l62-v6mr798045ita.55.1524180919967; Thu, 19 Apr 2018 16:35:19 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:45c4:0:0:0:0:0 with HTTP; Thu, 19 Apr 2018 16:35:19 -0700 (PDT) In-Reply-To: References: <787AE7BB302AE849A7480A190F8B93302DF0B7FE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Sonal Agarwal Date: Thu, 19 Apr 2018 16:35:19 -0700 Message-ID: To: Mahesh Jethanandani Cc: mohamed.boucadair@orange.com, "draft-ietf-netmod-acl-model@ietf.org" , "dots@ietf.org" , Kent Watsen Content-Type: multipart/alternative; boundary="0000000000004ee3aa056a3c061d" Archived-At: Subject: Re: [Dots] Mail regarding draft-ietf-netmod-acl-model 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, 19 Apr 2018 23:35:23 -0000 --0000000000004ee3aa056a3c061d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Med, Replies inline: Can you please clarify whether =E2=80=9Cprotocol=E2=80=9D covers only the b= ase IPv6 header or it includes also =E2=80=9Cnext header=E2=80=9D of any enclosed Extension= Header? The protocol covers the entire IPv6 packet, which includes the extension header(s). The EH's do not individually contain the protocol information. When EH's are present, then the protocol will be in the "Upper layer header". For example, does the following ACL accept DNS packets + drop fragments efficiently? Does it work even if other EHs are preceding a Fragment header ? I have not seen an ACL that is used to filter DNS packets, but I presume it would have the protocol to be tcp/udp and the L4 port to be 53. "ace": [ { "name": "drop-all-fragments", "matches": { "ipv6": { "protocol": 44 } }, "actions": { "forwarding": "drop" } } ] This ACE is saying match protocol 44 in upper header and drop the packet. It will only work for packets that have 44 set as the protocol. For hardware to truly drop all fragmented packets, the correct match would be something like "deny any any frag". This indicates to dataplane to figure out if a packet is a fragment, and then drop it. "ace": [ { "name": "allow-dns-packets", "matches": { "ipv6": { "destination-ipv6-network": "2001:db8::/32" } "udp": { "destination-port": { "operator": "eq", "port": 53 } } }, "actions": { "forwarding": "accept" } } ] } } ] I presume you want the protocol here to be ipv6. This ACE indicates to match packets with protocol ipv6 and match on destination-port 53. In order to do this, dataplane needs to extract L4 information from the payload. If the packet matches destination port of 53, then accept the packets. Dataplane should be capable of extracting L4 from the payload, regardless of the number of extension headers present. Thanks, Sonal. On Thu, Apr 19, 2018 at 12:17 PM, Mahesh Jethanandani < mjethanandani@gmail.com> wrote: > Mohamed, > > While I wait for my co-authors to get back to me, here is my take on this= . > > On Apr 16, 2018, at 8:08 AM, < > mohamed.boucadair@orange.com> wrote: > > Dear authors, > > We do have a question regarding the interpretation of =E2=80=9Cprotocol= =E2=80=9D when an > IPv6 match filter is applied because the draft is not clear. > > Can you please clarify whether =E2=80=9Cprotocol=E2=80=9D covers only the= base IPv6 header > or it includes also =E2=80=9Cnext header=E2=80=9D of any enclosed Extensi= on Header? > > > The current draft covers only the base IPv6 header. It does not cover > Extension Headers. > > If there is such a requirement, we will have to take it up in the bis > version of this draft. > > > For example, does the following ACL accept DNS packets + drop fragments > efficiently? Does it work even if other EHs are preceding a Fragment head= er > ? > > { > "ietf-dots-data-channel:acls": { > "acl": [ > { > "name": "dns-fragments", > "type": "ipv6-acl-type", > "aces": { > "ace": [ > { > "name": "drop-all-fragments", > "matches": { > "ipv6": { > "protocol": 44 > } > }, > "actions": { > "forwarding": "drop" > } > } > ] > "ace": [ > { > "name": "allow-dns-packets", > "matches": { > "ipv6": { > "destination-ipv6-network": "2001:db8::/32" > } > "udp": { > "destination-port": { > "operator": "eq", > "port": 53 > } > } > }, > "actions": { > "forwarding": "accept" > } > } > ] > } > } > ] > } > } > > > Again, my personal take on it (and I will wait for my co-authors to > correct me if I am wrong), is that these are two separate entries. > Depending on the order of the rules, and again assuming the rules are in > the order stated above, if you do receive a fragmented DNS packet, the > second rule will never be hit. The first rule would apply and the packet > will be dropped. If the rules are reversed, then all DNS packets to IPv6 > address 2001:db8::/32 will be accepted, whether they are fragmented or > not. > > Cheers. > > Cheers, > Med > > > Mahesh Jethanandani > mjethanandani@gmail.com > > --0000000000004ee3aa056a3c061d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Med,

Replies inline:

Can you please clarify whether =E2=80=9Cprotocol=E2=80=9D covers only the = base IPv6 header or it includes also =E2=80=9Cnext header=E2=80=9D of any e= nclosed Extension Header?
The protocol covers the entire IPv6 packet, which inclu= des the extension header(s). The EH's do not individually contain the p= rotocol information. When EH's are present, then the protocol will be i= n the "Upper layer header".

For example, does the following= ACL accept DNS packets + drop fragments efficiently? Does it work even if = other EHs are preceding a Fragment header ?

=C2=A0 =C2=A0 =C2=A0I have not seen an ACL that is used = to filter DNS packets, but I presume it would have the protocol to be tcp/u= dp and the L4 port to be 53.
"ace": [
=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 {
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "name&quo= t;: "drop-all-fragments",
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 "matches": {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 "ipv6": {
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "protocol": 44=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }
<= div style=3D"font-family:Calibri,sans-serif;margin:0cm 0cm 0.0001pt;font-si= ze:11pt">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 },
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 &q= uot;actions": {
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 "forwarding": "drop"
<= div style=3D"font-family:Calibri,sans-serif;margin:0cm 0cm 0.0001pt;font-si= ze:11pt">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 }
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 ]

This ACE is saying m= atch protocol 44 in upper header and drop the packet. It will only work for= packets that have 44 set as the protocol. For hardware to truly drop all f= ragmented packets, the correct match would be something like "deny any= any frag". This indicates to dataplane to figure out if a packet is a= fragment, and then drop it.

"ace":= [
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 "name": "allow-dns-packets",<= /u>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "matches": {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "ipv6": {=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "desti= nation-ipv6-network": "2001:db8::/32"
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0}
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 "udp": {
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 "destination-port": {
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "operator": "eq",<= u>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "= ;port": 53
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0}
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= }
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 },=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 "actions": {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "forwarding": "accept&q= uot;
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }<= /div>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 }
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ]
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }
=C2=A0=C2=A0=C2=A0 ]
I presume you want the protocol here to be ipv6. This ACE indi= cates to match packets with protocol ipv6 and match on destination-port 53.= In order to do this, dataplane needs to extract L4 information from the pa= yload. If the packet matches destination port of 53, then accept the packet= s. Dataplane should be capable of extracting L4 from the payload, regardles= s of the number of extension headers present.

Sonal.




On Thu, Apr 19, 2018 at 12:17 PM, Mahesh Jethanandani <m= jethanandani@gmail.com> wrote:
Mohame= d,

While I wait for my co-authors to get back to me, her= e is my take on this.

On Apr 16, 2018, at 8:08 AM, <mohamed.boucadair@orange.com> <mohamed.bouc= adair@orange.com> wrote:

Dear authors,=C2=A0
=C2=A0
= We do have a question regarding the interpretation of =E2=80=9Cprotocol=E2= =80=9D when an IPv6 match filter is applied because the draft is not clear.=
=C2=A0
Can you please clarify whether =E2=80=9Cprotocol=E2=80= =9D covers only the base IPv6 header or it includes also =E2=80=9Cnext head= er=E2=80=9D of any enclosed Extension Header?

The current draft covers only the base IPv6 h= eader. It does not cover Extension Headers.=C2=A0

= If there is such a requirement, we will have to take it up in the bis versi= on of this draft.

=C2= =A0
For example, does the following ACL= accept DNS packets + drop fragments efficiently? Does it work even if othe= r EHs are preceding a Fragment header ?
=C2=A0
{
=C2=A0 "ietf-dots-data-channel:acls":= {
=C2=A0=C2=A0=C2=A0 "acl&= quot;: [
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 {
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 "name": "dns-fragments",
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 "type": "ipv6-acl-type",
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "aces&q= uot;: {
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "ace": [
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 {
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "name&quo= t;: "drop-all-fragments",
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 "matches": {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 "ipv6": {
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "protocol": 44=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }
<= div style=3D"margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,san= s-serif">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 },
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 &q= uot;actions": {
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 "forwarding": "drop"
<= div style=3D"margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,san= s-serif">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 }
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 ]
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "ace": [
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 {
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "= ;name": "allow-dns-packets",
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 "matches": {
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 "ipv6": {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "destination-ipv6-network&q= uot;: "2001:db8::/32"
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0= =C2=A0}
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "udp": = {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "destination= -port": {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 "operator": "eq",
<= div style=3D"margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,san= s-serif">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "port": 53
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0}
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 },
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "= ;actions": {
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 "forwarding": "accept"
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 }
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 ]
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 }
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 }
= =C2=A0=C2=A0=C2=A0 ]
=C2=A0 }=
}

Again, my personal take on it (and I will w= ait for my co-authors to correct me if I am wrong), is that these are two s= eparate entries. Depending on the order of the rules, and again assuming th= e rules are in the order stated above, if you do receive a fragmented DNS p= acket, the second rule will never be hit. The first rule would apply and th= e packet will be dropped. If the rules are reversed, then all DNS packets t= o IPv6 address=C2=A02001:db8::/32=C2=A0will be accepted, whether they are fr= agmented or not.

Cheers.

=
Cheers,
=
Med

Mahesh Jethanandani


--0000000000004ee3aa056a3c061d-- From nobody Thu Apr 19 22:33:57 2018 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 5BA44128959; Thu, 19 Apr 2018 22:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IBEktrpm3Q5t; Thu, 19 Apr 2018 22:33:54 -0700 (PDT) Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B42E1128D2E; Thu, 19 Apr 2018 22:33:53 -0700 (PDT) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id F150320793; Fri, 20 Apr 2018 07:33:51 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.66]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id CA0101A0062; Fri, 20 Apr 2018 07:33:51 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA1.corporate.adroot.infra.ftgroup ([fe80::95e2:eb4b:3053:fabf%19]) with mapi id 14.03.0389.001; Fri, 20 Apr 2018 07:33:51 +0200 From: To: Mahesh Jethanandani CC: "draft-ietf-netmod-acl-model@ietf.org" , "dots@ietf.org" , "Kent Watsen" Thread-Topic: Mail regarding draft-ietf-netmod-acl-model Thread-Index: AdPVlMZLfgl8LrjkRwqP1O1MsxSS7ACbXpaAABl14yA= Date: Fri, 20 Apr 2018 05:33:51 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DF0E757@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93302DF0B7FE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93302DF0E757OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Mail regarding draft-ietf-netmod-acl-model 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, 20 Apr 2018 05:33:56 -0000 --_000_787AE7BB302AE849A7480A190F8B93302DF0E757OPEXCLILMA3corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFoZXNoLA0KDQpUaGFuayB5b3UgZm9yIHRoZSBmb2xsb3ctdXAuDQoNClBsZWFzZSBzZWUg aW5saW5lLg0KDQpDaGVlcnMsDQpNZWQNCg0KRGUgOiBNYWhlc2ggSmV0aGFuYW5kYW5pIFttYWls dG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb21dDQpFbnZvecOpIDogamV1ZGkgMTkgYXZyaWwgMjAx OCAyMToxNw0Kw4AgOiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xODQpDYyA6IGRyYWZ0LWlldGYt bmV0bW9kLWFjbC1tb2RlbEBpZXRmLm9yZzsgZG90c0BpZXRmLm9yZzsgS2VudCBXYXRzZW4NCk9i amV0IDogUmU6IE1haWwgcmVnYXJkaW5nIGRyYWZ0LWlldGYtbmV0bW9kLWFjbC1tb2RlbA0KSW1w b3J0YW5jZSA6IEhhdXRlDQoNCk1vaGFtZWQsDQoNCldoaWxlIEkgd2FpdCBmb3IgbXkgY28tYXV0 aG9ycyB0byBnZXQgYmFjayB0byBtZSwgaGVyZSBpcyBteSB0YWtlIG9uIHRoaXMuDQoNCg0KT24g QXByIDE2LCAyMDE4LCBhdCA4OjA4IEFNLCA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxt YWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4+IDxtb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPj4gd3JvdGU6DQoN CkRlYXIgYXV0aG9ycywNCg0KV2UgZG8gaGF2ZSBhIHF1ZXN0aW9uIHJlZ2FyZGluZyB0aGUgaW50 ZXJwcmV0YXRpb24gb2Yg4oCccHJvdG9jb2zigJ0gd2hlbiBhbiBJUHY2IG1hdGNoIGZpbHRlciBp cyBhcHBsaWVkIGJlY2F1c2UgdGhlIGRyYWZ0IGlzIG5vdCBjbGVhci4NCg0KQ2FuIHlvdSBwbGVh c2UgY2xhcmlmeSB3aGV0aGVyIOKAnHByb3RvY29s4oCdIGNvdmVycyBvbmx5IHRoZSBiYXNlIElQ djYgaGVhZGVyIG9yIGl0IGluY2x1ZGVzIGFsc28g4oCcbmV4dCBoZWFkZXLigJ0gb2YgYW55IGVu Y2xvc2VkIEV4dGVuc2lvbiBIZWFkZXI/DQoNClRoZSBjdXJyZW50IGRyYWZ0IGNvdmVycyBvbmx5 IHRoZSBiYXNlIElQdjYgaGVhZGVyLiBJdCBkb2VzIG5vdCBjb3ZlciBFeHRlbnNpb24gSGVhZGVy cy4NCltNZWRdIFRoYW5rIHlvdSBmb3IgY2xhcmlmeWluZy4gQ2FuIHlvdSBwbGVhc2UgYWRkIGEg c2VudGVuY2UgdG8gdGhlIGRyYWZ0IHRvIG1ha2UgdGhpcyBleHBsaWNpdD8NCg0KSWYgdGhlcmUg aXMgc3VjaCBhIHJlcXVpcmVtZW50LCB3ZSB3aWxsIGhhdmUgdG8gdGFrZSBpdCB1cCBpbiB0aGUg YmlzIHZlcnNpb24gb2YgdGhpcyBkcmFmdC4NCltNZWRdIEZpbHRlcmluZyBFSHMgaXMgYSByZXF1 aXJlbWVudC4gSSB3b3VsZCBob3BlIHRoaXMgaXMgaW4gc2NvcGUsIGJ1dCBJIHdvbuKAmXQgYXNr IGZvciBpdCB0byBiZSBpbmNsdWRlZCBhdCB0aGlzIHN0YWdlIG9mIHRoZSBwdWJsaWNhdGlvbiBw cm9jZXNzIGdpdmVuIHRoYXQgSSB3b3VsZCBsaWtlIHRvIHNlZSBuZXRtb2QtYWNsIHB1Ymxpc2hl ZCBBU0FQLg0KDQoNCkZvciBleGFtcGxlLCBkb2VzIHRoZSBmb2xsb3dpbmcgQUNMIGFjY2VwdCBE TlMgcGFja2V0cyArIGRyb3AgZnJhZ21lbnRzIGVmZmljaWVudGx5PyBEb2VzIGl0IHdvcmsgZXZl biBpZiBvdGhlciBFSHMgYXJlIHByZWNlZGluZyBhIEZyYWdtZW50IGhlYWRlciA/DQoNCnsNCiAg ImlldGYtZG90cy1kYXRhLWNoYW5uZWw6YWNscyI6IHsNCiAgICAiYWNsIjogWw0KICAgICAgew0K ICAgICAgICAibmFtZSI6ICJkbnMtZnJhZ21lbnRzIiwNCiAgICAgICAgInR5cGUiOiAiaXB2Ni1h Y2wtdHlwZSIsDQogICAgICAgICJhY2VzIjogew0KICAgICAgICAgICJhY2UiOiBbDQogICAgICAg ICAgICB7DQogICAgICAgICAgICAgICJuYW1lIjogImRyb3AtYWxsLWZyYWdtZW50cyIsDQogICAg ICAgICAgICAgICJtYXRjaGVzIjogew0KICAgICAgICAgICAgICAgICJpcHY2Ijogew0KICAgICAg ICAgICAgICAgICAgInByb3RvY29sIjogNDQNCiAgICAgICAgICAgICAgICB9DQogICAgICAgICAg ICAgIH0sDQogICAgICAgICAgICAgICJhY3Rpb25zIjogew0KICAgICAgICAgICAgICAgICJmb3J3 YXJkaW5nIjogImRyb3AiDQogICAgICAgICAgICAgIH0NCiAgICAgICAgICAgIH0NCiAgICAgICAg ICBdDQogICAgICAgICAgImFjZSI6IFsNCiAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgIm5h bWUiOiAiYWxsb3ctZG5zLXBhY2tldHMiLA0KICAgICAgICAgICAgICAibWF0Y2hlcyI6IHsNCiAg ICAgICAgICAgICAgICAiaXB2NiI6IHsNCiAgICAgICAgICAgICAgICAgICJkZXN0aW5hdGlvbi1p cHY2LW5ldHdvcmsiOiAiMjAwMTpkYjg6Oi8zMiINCiAgICAgICAgICAgICAgICB9DQogICAgICAg ICAgICAgICAgInVkcCI6IHsNCiAgICAgICAgICAgICAgICAgICJkZXN0aW5hdGlvbi1wb3J0Ijog ew0KICAgICAgICAgICAgICAgICAgICAib3BlcmF0b3IiOiAiZXEiLA0KICAgICAgICAgICAgICAg ICAgICAicG9ydCI6IDUzDQogICAgICAgICAgICAgICAgICB9DQogICAgICAgICAgICAgICAgfQ0K ICAgICAgICAgICAgICB9LA0KICAgICAgICAgICAgICAiYWN0aW9ucyI6IHsNCiAgICAgICAgICAg ICAgICAiZm9yd2FyZGluZyI6ICJhY2NlcHQiDQogICAgICAgICAgICAgIH0NCiAgICAgICAgICAg IH0NCiAgICAgICAgICBdDQogICAgICAgIH0NCiAgICAgIH0NCiAgICBdDQogIH0NCn0NCg0KQWdh aW4sIG15IHBlcnNvbmFsIHRha2Ugb24gaXQgKGFuZCBJIHdpbGwgd2FpdCBmb3IgbXkgY28tYXV0 aG9ycyB0byBjb3JyZWN0IG1lIGlmIEkgYW0gd3JvbmcpLCBpcyB0aGF0IHRoZXNlIGFyZSB0d28g c2VwYXJhdGUgZW50cmllcy4gRGVwZW5kaW5nIG9uIHRoZSBvcmRlciBvZiB0aGUgcnVsZXMsIGFu ZCBhZ2FpbiBhc3N1bWluZyB0aGUgcnVsZXMgYXJlIGluIHRoZSBvcmRlciBzdGF0ZWQgYWJvdmUs IGlmIHlvdSBkbyByZWNlaXZlIGEgZnJhZ21lbnRlZCBETlMgcGFja2V0LCB0aGUgc2Vjb25kIHJ1 bGUgd2lsbCBuZXZlciBiZSBoaXQuIFRoZSBmaXJzdCBydWxlIHdvdWxkIGFwcGx5IGFuZCB0aGUg cGFja2V0IHdpbGwgYmUgZHJvcHBlZC4NCltNZWRdIFllcywgaWYgYW5kIG9ubHkgaWYgdGhlcmUg aXMgbm8gRUggcHJlY2VkaW5nIHRoZSBGcmFnbWVudCBoZWFkZXIuIFRoYXQgaXMgaWYgdGhlIG5l eHQtaGVhZGVyIG9mIHRoZSBiYXNlIElQdjYgcG9pbnRzIHRvIGFub3RoZXIgaGVhZGVyIHRoYXQg dGhlIGZyYWdtZW50IGhlYWRlciwgYSBmcmFnbWVudGVkIHBhY2tldCB3b27igJl0IGJlIGRyb3Bw ZWQuDQoNCklmIHRoZSBydWxlcyBhcmUgcmV2ZXJzZWQsIHRoZW4gYWxsIEROUyBwYWNrZXRzIHRv IElQdjYgYWRkcmVzcyAyMDAxOmRiODo6LzMyIHdpbGwgYmUgYWNjZXB0ZWQsIHdoZXRoZXIgdGhl eSBhcmUgZnJhZ21lbnRlZCBvciBub3QuDQpbTWVkXSBZZXMuDQoNCg0KQ2hlZXJzLg0KDQoNCkNo ZWVycywNCk1lZA0KDQpNYWhlc2ggSmV0aGFuYW5kYW5pDQptamV0aGFuYW5kYW5pQGdtYWlsLmNv bTxtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20+DQoNCg== --_000_787AE7BB302AE849A7480A190F8B93302DF0E757OPEXCLILMA3corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUHLD qWZvcm1hdMOpIEhUTUwgQ2FyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bh bi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVk LXNwYWNlO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7DQoJZm9udC13 ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCnNwYW4uUHJmb3JtYXRIVE1MQ2Fy DQoJe21zby1zdHlsZS1uYW1lOiJQcsOpZm9ybWF0w6kgSFRNTCBDYXIiOw0KCW1zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUHLDqWZvcm1hdMOpIEhUTUwiOw0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcw Ljg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJGUiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj5IaSBNYWhlc2gsDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+VGhhbmsgeW91IGZvciB0aGUgZm9sbG93LXVwLg0K PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPlBsZWFz ZSBzZWUgaW5saW5lLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPk1lZDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQu MHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGUmbmJzcDs6PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE1haGVzaCBKZXRoYW5hbmRhbmkgW21haWx0bzpt amV0aGFuYW5kYW5pQGdtYWlsLmNvbV0NCjxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiBqZXVk aSAxOSBhdnJpbCAyMDE4IDIxOjE3PGJyPg0KPGI+w4AmbmJzcDs6PC9iPiBCT1VDQURBSVIgTW9o YW1lZCBJTVQvT0xOPGJyPg0KPGI+Q2MmbmJzcDs6PC9iPiBkcmFmdC1pZXRmLW5ldG1vZC1hY2wt bW9kZWxAaWV0Zi5vcmc7IGRvdHNAaWV0Zi5vcmc7IEtlbnQgV2F0c2VuPGJyPg0KPGI+T2JqZXQm bmJzcDs6PC9iPiBSZTogTWFpbCByZWdhcmRpbmcgZHJhZnQtaWV0Zi1uZXRtb2QtYWNsLW1vZGVs PGJyPg0KPGI+SW1wb3J0YW5jZSZuYnNwOzo8L2I+IEhhdXRlPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TW9oYW1lZCw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoaWxlIEkgd2FpdCBmb3IgbXkgY28tYXV0aG9ycyB0 byBnZXQgYmFjayB0byBtZSwgaGVyZSBpcyBteSB0YWtlIG9uIHRoaXMuPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gQXByIDE2LCAyMDE4LCBhdCA4OjA4IEFN LCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1vaGFt ZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1vaGFt ZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+RGVhciBhdXRob3JzLCZuYnNwOzwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij5XZSBkbyBoYXZlIGEgcXVlc3Rpb24gcmVnYXJkaW5nIHRoZSBpbnRlcnByZXRhdGlvbiBvZiDi gJxwcm90b2NvbOKAnSB3aGVuIGFuIElQdjYgbWF0Y2ggZmlsdGVyIGlzIGFwcGxpZWQgYmVjYXVz ZSB0aGUgZHJhZnQgaXMgbm90IGNsZWFyLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5DYW4geW91IHBsZWFzZSBj bGFyaWZ5IHdoZXRoZXIg4oCccHJvdG9jb2zigJ0gY292ZXJzIG9ubHkgdGhlIGJhc2UgSVB2NiBo ZWFkZXIgb3IgaXQgaW5jbHVkZXMgYWxzbyDigJxuZXh0IGhlYWRlcuKAnSBvZiBhbnkgZW5jbG9z ZWQgRXh0ZW5zaW9uIEhlYWRlcj88L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGUgY3VycmVudCBkcmFmdCBjb3ZlcnMgb25seSB0aGUgYmFzZSBJUHY2IGhlYWRlci4g SXQgZG9lcyBub3QgY292ZXIgRXh0ZW5zaW9uIEhlYWRlcnMuJm5ic3A7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PltNZWRdIFRoYW5rIHlvdSBmb3IgY2xhcmlmeWluZy4gQ2FuIHlvdSBwbGVhc2UgYWRkIGEgc2Vu dGVuY2UgdG8gdGhlIGRyYWZ0IHRvIG1ha2UgdGhpcyBleHBsaWNpdD88bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SWYgdGhlcmUgaXMgc3VjaCBhIHJlcXVpcmVtZW50LCB3ZSB3aWxsIGhh dmUgdG8gdGFrZSBpdCB1cCBpbiB0aGUgYmlzIHZlcnNpb24gb2YgdGhpcyBkcmFmdC48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+W01lZF0gRmlsdGVyaW5nIEVIcyBpcyBhIHJlcXVpcmVt ZW50LiBJIHdvdWxkIGhvcGUgdGhpcyBpcyBpbiBzY29wZSwgYnV0IEkgd29u4oCZdCBhc2sgZm9y IGl0IHRvIGJlIGluY2x1ZGVkIGF0IHRoaXMgc3RhZ2Ugb2YgdGhlIHB1YmxpY2F0aW9uIHByb2Nl c3MgZ2l2ZW4NCiB0aGF0IEkgd291bGQgbGlrZSB0byBzZWUgbmV0bW9kLWFjbCBwdWJsaXNoZWQg QVNBUC48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5Gb3IgZXhhbXBsZSwgZG9lcyB0aGUg Zm9sbG93aW5nIEFDTCBhY2NlcHQgRE5TIHBhY2tldHMgJiM0MzsgZHJvcCBmcmFnbWVudHMgZWZm aWNpZW50bHk/IERvZXMgaXQgd29yayBldmVuIGlmIG90aGVyIEVIcyBhcmUgcHJlY2VkaW5nIGEg RnJhZ21lbnQgaGVhZGVyID88L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ezwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZxdW90O2lldGYt ZG90cy1kYXRhLWNoYW5uZWw6YWNscyZxdW90Ozogezwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZx dW90O2FjbCZxdW90OzogWzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHs8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtuYW1lJnF1 b3Q7OiAmcXVvdDtkbnMtZnJhZ21lbnRzJnF1b3Q7LDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O3R5cGUmcXVvdDs6ICZxdW90O2lwdjYtYWNsLXR5 cGUmcXVvdDssPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg JnF1b3Q7YWNlcyZxdW90Ozogezwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O2FjZSZxdW90OzogWzwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHs8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtuYW1lJnF1b3Q7OiAmcXVvdDtkcm9wLWFs bC1mcmFnbWVudHMmcXVvdDssPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7bWF0Y2hl cyZxdW90Ozogezwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O2lw djYmcXVvdDs6IHs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmcXVvdDtwcm90b2NvbCZxdW90OzogNDQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB9PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfSw8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmcXVvdDthY3Rpb25zJnF1b3Q7OiB7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJnF1b3Q7Zm9yd2FyZGluZyZxdW90OzogJnF1b3Q7ZHJvcCZxdW90Ozwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgXTwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O2Fj ZSZxdW90OzogWzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVv dDtuYW1lJnF1b3Q7OiAmcXVvdDthbGxvdy1kbnMtcGFja2V0cyZxdW90Oyw8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmcXVvdDttYXRjaGVzJnF1b3Q7OiB7PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7aXB2NiZxdW90Ozogezwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O2Rlc3RpbmF0aW9uLWlwdjYtbmV0 d29yayZxdW90OzogJnF1b3Q7MjAwMTpkYjg6Oi8zMiZxdW90Ozwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+fTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1 b3Q7dWRwJnF1b3Q7OiB7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVv dDtkZXN0aW5hdGlvbi1wb3J0JnF1b3Q7OiB7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtvcGVyYXRvciZxdW90OzogJnF1b3Q7ZXEmcXVvdDss PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtw b3J0JnF1b3Q7OiA1Mzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+fTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9LDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZx dW90O2FjdGlvbnMmcXVvdDs6IHs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmcXVvdDtmb3J3YXJkaW5nJnF1b3Q7OiAmcXVvdDthY2NlcHQmcXVvdDs8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB9PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IF08L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgfTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IF08L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyB9PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij59PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWdhaW4sIG15IHBlcnNvbmFsIHRh a2Ugb24gaXQgKGFuZCBJIHdpbGwgd2FpdCBmb3IgbXkgY28tYXV0aG9ycyB0byBjb3JyZWN0IG1l IGlmIEkgYW0gd3JvbmcpLCBpcyB0aGF0IHRoZXNlIGFyZSB0d28gc2VwYXJhdGUgZW50cmllcy4g RGVwZW5kaW5nIG9uIHRoZSBvcmRlciBvZiB0aGUgcnVsZXMsIGFuZCBhZ2FpbiBhc3N1bWluZyB0 aGUgcnVsZXMgYXJlIGluIHRoZSBvcmRlciBzdGF0ZWQgYWJvdmUsIGlmIHlvdQ0KIGRvIHJlY2Vp dmUgYSBmcmFnbWVudGVkIEROUyBwYWNrZXQsIHRoZSBzZWNvbmQgcnVsZSB3aWxsIG5ldmVyIGJl IGhpdC4gVGhlIGZpcnN0IHJ1bGUgd291bGQgYXBwbHkgYW5kIHRoZSBwYWNrZXQgd2lsbCBiZSBk cm9wcGVkLg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PltNZWRdIFllcywgaWYgYW5kIG9ubHkgaWYgdGhlcmUgaXMgbm8gRUggcHJlY2VkaW5nIHRoZSBG cmFnbWVudCBoZWFkZXIuIFRoYXQgaXMgaWYgdGhlIG5leHQtaGVhZGVyIG9mIHRoZSBiYXNlIElQ djYgcG9pbnRzIHRvIGFub3RoZXIgaGVhZGVyIHRoYXQgdGhlIGZyYWdtZW50DQogaGVhZGVyLCBh IGZyYWdtZW50ZWQgcGFja2V0IHdvbuKAmXQgYmUgZHJvcHBlZC4gJm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SWYgdGhlIHJ1bGVzIGFyZSByZXZlcnNlZCwgdGhlbiBh bGwgRE5TIHBhY2tldHMgdG8gSVB2NiBhZGRyZXNzJm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+MjAwMTpkYjg6Oi8zMjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7d2ls bCBiZSBhY2NlcHRlZCwgd2hldGhlciB0aGV5IGFyZSBmcmFnbWVudGVkDQogb3Igbm90LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+W01lZF0gWWVzLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5D aGVlcnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij5DaGVlcnMsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+TWVkPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5NYWhlc2ggSmV0aGFuYW5kYW5pPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJl Zj0ibWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tIj48c3BhbiBsYW5nPSJFTi1VUyI+bWpl dGhhbmFuZGFuaUBnbWFpbC5jb208L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_787AE7BB302AE849A7480A190F8B93302DF0E757OPEXCLILMA3corp_-- From nobody Thu Apr 19 22:46:31 2018 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 12215128959; Thu, 19 Apr 2018 22:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OBCyksLBa4lP; Thu, 19 Apr 2018 22:46:26 -0700 (PDT) Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E54C8120713; Thu, 19 Apr 2018 22:46:25 -0700 (PDT) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 5C653C0F9D; Fri, 20 Apr 2018 07:46:24 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.41]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id 379FC60073; Fri, 20 Apr 2018 07:46:24 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM31.corporate.adroot.infra.ftgroup ([fe80::2cc9:4bac:7b7d:229d%19]) with mapi id 14.03.0389.001; Fri, 20 Apr 2018 07:46:24 +0200 From: To: Sonal Agarwal , Mahesh Jethanandani CC: "draft-ietf-netmod-acl-model@ietf.org" , "dots@ietf.org" , "Kent Watsen" Thread-Topic: Mail regarding draft-ietf-netmod-acl-model Thread-Index: AdPVlMZLfgl8LrjkRwqP1O1MsxSS7ACok+OnAAyFiPA= Date: Fri, 20 Apr 2018 05:46:23 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DF0E790@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93302DF0B7FE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93302DF0E790OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Mail regarding draft-ietf-netmod-acl-model 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, 20 Apr 2018 05:46:29 -0000 --_000_787AE7BB302AE849A7480A190F8B93302DF0E790OPEXCLILMA3corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU29uYWwsDQoNClRoYW5rIHlvdSBmb3IgdGhlIHJlcGx5LiBNdWNoIGFwcHJlY2lhdGVkIQ0K DQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCkRlIDogU29uYWwgQWdhcndh bCBbbWFpbHRvOnNhZ2Fyd2FsMTJAZ21haWwuY29tXQ0KRW52b3nDqSA6IHZlbmRyZWRpIDIwIGF2 cmlsIDIwMTggMDE6MzUNCsOAIDogTWFoZXNoIEpldGhhbmFuZGFuaQ0KQ2MgOiBCT1VDQURBSVIg TW9oYW1lZCBJTVQvT0xOOyBkcmFmdC1pZXRmLW5ldG1vZC1hY2wtbW9kZWxAaWV0Zi5vcmc7IGRv dHNAaWV0Zi5vcmc7IEtlbnQgV2F0c2VuDQpPYmpldCA6IFJlOiBNYWlsIHJlZ2FyZGluZyBkcmFm dC1pZXRmLW5ldG1vZC1hY2wtbW9kZWwNCg0KSGkgTWVkLA0KDQpSZXBsaWVzIGlubGluZToNCg0K Q2FuIHlvdSBwbGVhc2UgY2xhcmlmeSB3aGV0aGVyIOKAnHByb3RvY29s4oCdIGNvdmVycyBvbmx5 IHRoZSBiYXNlIElQdjYgaGVhZGVyIG9yIGl0IGluY2x1ZGVzIGFsc28g4oCcbmV4dCBoZWFkZXLi gJ0gb2YgYW55IGVuY2xvc2VkIEV4dGVuc2lvbiBIZWFkZXI/DQpUaGUgcHJvdG9jb2wgY292ZXJz IHRoZSBlbnRpcmUgSVB2NiBwYWNrZXQsIHdoaWNoIGluY2x1ZGVzIHRoZSBleHRlbnNpb24gaGVh ZGVyKHMpLiBUaGUgRUgncyBkbyBub3QgaW5kaXZpZHVhbGx5IGNvbnRhaW4gdGhlIHByb3RvY29s IGluZm9ybWF0aW9uLg0KW01lZF0gQWN0dWFsbHksIOKAnHByb3RvY29s4oCdIGlzIGRlZmluZWQg aW4gdGhlIG5ldG1vZC1hY2wgYXMgZm9sbG93czoNCg0KICAgIGxlYWYgcHJvdG9jb2wgew0KICAg ICAgdHlwZSB1aW50ODsNCiAgICAgIGRlc2NyaXB0aW9uDQogICAgICAgICJJbnRlcm5ldCBQcm90 b2NvbCBudW1iZXIuIFJlZmVycyB0byB0aGUgcHJvdG9jb2wgb2YgdGhlDQogICAgICAgICBwYXls b2FkLiBJbiBJUHY2LCB0aGlzIGZpZWxkIGlzIGtub3duIGFzICduZXh0LWhlYWRlci4iOw0KDQpU aGlzIHRleHQgaXMgcmVhbGx5IG5vdCBjbGVhciB3aGF0IGl0IGNvdmVycy4gVGhpcyBpcyBjb25m dXNpbmcgZ2l2ZW4gdGhhdCDigJxuZXh0IGhlYWRlcuKAnSBpcyBwcmVzZW50IGluIHRoZSBiYXNl IGhlYWRlciBhbmQgYWxzbyBpbiBFSHMuDQoNCkluIG9yZGVyIHRvIGF2b2lkIGNvbmZ1c2lvbiwg cGxlYXNlIGNvbnNpZGVyIGFkZGluZyBvbmUgc2VudGVuY2UgdG8gdHdvIHRvIGNsYXJpZnkgdGhl IGludGVudC4NCg0KV2hlbiBFSCdzIGFyZSBwcmVzZW50LCB0aGVuIHRoZSBwcm90b2NvbCB3aWxs IGJlIGluIHRoZSAiVXBwZXIgbGF5ZXIgaGVhZGVyIi4NCg0KRm9yIGV4YW1wbGUsIGRvZXMgdGhl IGZvbGxvd2luZyBBQ0wgYWNjZXB0IEROUyBwYWNrZXRzICsgZHJvcCBmcmFnbWVudHMgZWZmaWNp ZW50bHk/IERvZXMgaXQgd29yayBldmVuIGlmIG90aGVyIEVIcyBhcmUgcHJlY2VkaW5nIGEgRnJh Z21lbnQgaGVhZGVyID8NCg0KICAgICBJIGhhdmUgbm90IHNlZW4gYW4gQUNMIHRoYXQgaXMgdXNl ZCB0byBmaWx0ZXIgRE5TIHBhY2tldHMsIGJ1dCBJIHByZXN1bWUgaXQgd291bGQgaGF2ZSB0aGUg cHJvdG9jb2wgdG8gYmUgdGNwL3VkcCBhbmQgdGhlIEw0IHBvcnQgdG8gYmUgNTMuDQoiYWNlIjog Ww0KICAgICAgICAgICAgew0KICAgICAgICAgICAgICAibmFtZSI6ICJkcm9wLWFsbC1mcmFnbWVu dHMiLA0KICAgICAgICAgICAgICAibWF0Y2hlcyI6IHsNCiAgICAgICAgICAgICAgICAiaXB2NiI6 IHsNCiAgICAgICAgICAgICAgICAgICJwcm90b2NvbCI6IDQ0DQogICAgICAgICAgICAgICAgfQ0K ICAgICAgICAgICAgICB9LA0KICAgICAgICAgICAgICAiYWN0aW9ucyI6IHsNCiAgICAgICAgICAg ICAgICAiZm9yd2FyZGluZyI6ICJkcm9wIg0KICAgICAgICAgICAgICB9DQogICAgICAgICAgICB9 DQogICAgICAgICAgXQ0KDQpUaGlzIEFDRSBpcyBzYXlpbmcgbWF0Y2ggcHJvdG9jb2wgNDQgaW4g dXBwZXIgaGVhZGVyIGFuZCBkcm9wIHRoZSBwYWNrZXQuIEl0IHdpbGwgb25seSB3b3JrIGZvciBw YWNrZXRzIHRoYXQgaGF2ZSA0NCBzZXQgYXMgdGhlIHByb3RvY29sLiBGb3IgaGFyZHdhcmUgdG8g dHJ1bHkgZHJvcCBhbGwgZnJhZ21lbnRlZCBwYWNrZXRzLCB0aGUgY29ycmVjdCBtYXRjaCB3b3Vs ZCBiZSBzb21ldGhpbmcgbGlrZSAiZGVueSBhbnkgYW55IGZyYWciLiBUaGlzIGluZGljYXRlcyB0 byBkYXRhcGxhbmUgdG8gZmlndXJlIG91dCBpZiBhIHBhY2tldCBpcyBhIGZyYWdtZW50LCBhbmQg dGhlbiBkcm9wIGl0Lg0KDQoiYWNlIjogWw0KICAgICAgICAgICAgew0KICAgICAgICAgICAgICAi bmFtZSI6ICJhbGxvdy1kbnMtcGFja2V0cyIsDQogICAgICAgICAgICAgICJtYXRjaGVzIjogew0K ICAgICAgICAgICAgICAgICJpcHY2Ijogew0KICAgICAgICAgICAgICAgICAgImRlc3RpbmF0aW9u LWlwdjYtbmV0d29yayI6ICIyMDAxOmRiODo6LzMyIg0KICAgICAgICAgICAgICAgIH0NCiAgICAg ICAgICAgICAgICAidWRwIjogew0KICAgICAgICAgICAgICAgICAgImRlc3RpbmF0aW9uLXBvcnQi OiB7DQogICAgICAgICAgICAgICAgICAgICJvcGVyYXRvciI6ICJlcSIsDQogICAgICAgICAgICAg ICAgICAgICJwb3J0IjogNTMNCiAgICAgICAgICAgICAgICAgIH0NCiAgICAgICAgICAgICAgICB9 DQogICAgICAgICAgICAgIH0sDQogICAgICAgICAgICAgICJhY3Rpb25zIjogew0KICAgICAgICAg ICAgICAgICJmb3J3YXJkaW5nIjogImFjY2VwdCINCiAgICAgICAgICAgICAgfQ0KICAgICAgICAg ICAgfQ0KICAgICAgICAgIF0NCiAgICAgICAgfQ0KICAgICAgfQ0KICAgIF0NCg0KSSBwcmVzdW1l IHlvdSB3YW50IHRoZSBwcm90b2NvbCBoZXJlIHRvIGJlIGlwdjYuIFRoaXMgQUNFIGluZGljYXRl cyB0byBtYXRjaCBwYWNrZXRzIHdpdGggcHJvdG9jb2wgaXB2NiBhbmQgbWF0Y2ggb24gZGVzdGlu YXRpb24tcG9ydCA1My4gSW4gb3JkZXIgdG8gZG8gdGhpcywgZGF0YXBsYW5lIG5lZWRzIHRvIGV4 dHJhY3QgTDQgaW5mb3JtYXRpb24gZnJvbSB0aGUgcGF5bG9hZC4gSWYgdGhlIHBhY2tldCBtYXRj aGVzIGRlc3RpbmF0aW9uIHBvcnQgb2YgNTMsIHRoZW4gYWNjZXB0IHRoZSBwYWNrZXRzLiBEYXRh cGxhbmUgc2hvdWxkIGJlIGNhcGFibGUgb2YgZXh0cmFjdGluZyBMNCBmcm9tIHRoZSBwYXlsb2Fk LCByZWdhcmRsZXNzIG9mIHRoZSBudW1iZXIgb2YgZXh0ZW5zaW9uIGhlYWRlcnMgcHJlc2VudC4N Cg0KVGhhbmtzLA0KU29uYWwuDQoNCg0KDQoNCk9uIFRodSwgQXByIDE5LCAyMDE4IGF0IDEyOjE3 IFBNLCBNYWhlc2ggSmV0aGFuYW5kYW5pIDxtamV0aGFuYW5kYW5pQGdtYWlsLmNvbTxtYWlsdG86 bWpldGhhbmFuZGFuaUBnbWFpbC5jb20+PiB3cm90ZToNCk1vaGFtZWQsDQoNCldoaWxlIEkgd2Fp dCBmb3IgbXkgY28tYXV0aG9ycyB0byBnZXQgYmFjayB0byBtZSwgaGVyZSBpcyBteSB0YWtlIG9u IHRoaXMuDQoNCg0KT24gQXByIDE2LCAyMDE4LCBhdCA4OjA4IEFNLCA8bW9oYW1lZC5ib3VjYWRh aXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4+IDxtb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2Uu Y29tPj4gd3JvdGU6DQoNCkRlYXIgYXV0aG9ycywNCg0KV2UgZG8gaGF2ZSBhIHF1ZXN0aW9uIHJl Z2FyZGluZyB0aGUgaW50ZXJwcmV0YXRpb24gb2Yg4oCccHJvdG9jb2zigJ0gd2hlbiBhbiBJUHY2 IG1hdGNoIGZpbHRlciBpcyBhcHBsaWVkIGJlY2F1c2UgdGhlIGRyYWZ0IGlzIG5vdCBjbGVhci4N Cg0KQ2FuIHlvdSBwbGVhc2UgY2xhcmlmeSB3aGV0aGVyIOKAnHByb3RvY29s4oCdIGNvdmVycyBv bmx5IHRoZSBiYXNlIElQdjYgaGVhZGVyIG9yIGl0IGluY2x1ZGVzIGFsc28g4oCcbmV4dCBoZWFk ZXLigJ0gb2YgYW55IGVuY2xvc2VkIEV4dGVuc2lvbiBIZWFkZXI/DQoNClRoZSBjdXJyZW50IGRy YWZ0IGNvdmVycyBvbmx5IHRoZSBiYXNlIElQdjYgaGVhZGVyLiBJdCBkb2VzIG5vdCBjb3ZlciBF eHRlbnNpb24gSGVhZGVycy4NCg0KSWYgdGhlcmUgaXMgc3VjaCBhIHJlcXVpcmVtZW50LCB3ZSB3 aWxsIGhhdmUgdG8gdGFrZSBpdCB1cCBpbiB0aGUgYmlzIHZlcnNpb24gb2YgdGhpcyBkcmFmdC4N Cg0KDQoNCkZvciBleGFtcGxlLCBkb2VzIHRoZSBmb2xsb3dpbmcgQUNMIGFjY2VwdCBETlMgcGFj a2V0cyArIGRyb3AgZnJhZ21lbnRzIGVmZmljaWVudGx5PyBEb2VzIGl0IHdvcmsgZXZlbiBpZiBv dGhlciBFSHMgYXJlIHByZWNlZGluZyBhIEZyYWdtZW50IGhlYWRlciA/DQoNCnsNCiAgImlldGYt ZG90cy1kYXRhLWNoYW5uZWw6YWNscyI6IHsNCiAgICAiYWNsIjogWw0KICAgICAgew0KICAgICAg ICAibmFtZSI6ICJkbnMtZnJhZ21lbnRzIiwNCiAgICAgICAgInR5cGUiOiAiaXB2Ni1hY2wtdHlw ZSIsDQogICAgICAgICJhY2VzIjogew0KICAgICAgICAgICJhY2UiOiBbDQogICAgICAgICAgICB7 DQogICAgICAgICAgICAgICJuYW1lIjogImRyb3AtYWxsLWZyYWdtZW50cyIsDQogICAgICAgICAg ICAgICJtYXRjaGVzIjogew0KICAgICAgICAgICAgICAgICJpcHY2Ijogew0KICAgICAgICAgICAg ICAgICAgInByb3RvY29sIjogNDQNCiAgICAgICAgICAgICAgICB9DQogICAgICAgICAgICAgIH0s DQogICAgICAgICAgICAgICJhY3Rpb25zIjogew0KICAgICAgICAgICAgICAgICJmb3J3YXJkaW5n IjogImRyb3AiDQogICAgICAgICAgICAgIH0NCiAgICAgICAgICAgIH0NCiAgICAgICAgICBdDQog ICAgICAgICAgImFjZSI6IFsNCiAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgIm5hbWUiOiAi YWxsb3ctZG5zLXBhY2tldHMiLA0KICAgICAgICAgICAgICAibWF0Y2hlcyI6IHsNCiAgICAgICAg ICAgICAgICAiaXB2NiI6IHsNCiAgICAgICAgICAgICAgICAgICJkZXN0aW5hdGlvbi1pcHY2LW5l dHdvcmsiOiAiMjAwMTpkYjg6Oi8zMiINCiAgICAgICAgICAgICAgICB9DQogICAgICAgICAgICAg ICAgInVkcCI6IHsNCiAgICAgICAgICAgICAgICAgICJkZXN0aW5hdGlvbi1wb3J0Ijogew0KICAg ICAgICAgICAgICAgICAgICAib3BlcmF0b3IiOiAiZXEiLA0KICAgICAgICAgICAgICAgICAgICAi cG9ydCI6IDUzDQogICAgICAgICAgICAgICAgICB9DQogICAgICAgICAgICAgICAgfQ0KICAgICAg ICAgICAgICB9LA0KICAgICAgICAgICAgICAiYWN0aW9ucyI6IHsNCiAgICAgICAgICAgICAgICAi Zm9yd2FyZGluZyI6ICJhY2NlcHQiDQogICAgICAgICAgICAgIH0NCiAgICAgICAgICAgIH0NCiAg ICAgICAgICBdDQogICAgICAgIH0NCiAgICAgIH0NCiAgICBdDQogIH0NCn0NCg0KQWdhaW4sIG15 IHBlcnNvbmFsIHRha2Ugb24gaXQgKGFuZCBJIHdpbGwgd2FpdCBmb3IgbXkgY28tYXV0aG9ycyB0 byBjb3JyZWN0IG1lIGlmIEkgYW0gd3JvbmcpLCBpcyB0aGF0IHRoZXNlIGFyZSB0d28gc2VwYXJh dGUgZW50cmllcy4gRGVwZW5kaW5nIG9uIHRoZSBvcmRlciBvZiB0aGUgcnVsZXMsIGFuZCBhZ2Fp biBhc3N1bWluZyB0aGUgcnVsZXMgYXJlIGluIHRoZSBvcmRlciBzdGF0ZWQgYWJvdmUsIGlmIHlv dSBkbyByZWNlaXZlIGEgZnJhZ21lbnRlZCBETlMgcGFja2V0LCB0aGUgc2Vjb25kIHJ1bGUgd2ls bCBuZXZlciBiZSBoaXQuIFRoZSBmaXJzdCBydWxlIHdvdWxkIGFwcGx5IGFuZCB0aGUgcGFja2V0 IHdpbGwgYmUgZHJvcHBlZC4gSWYgdGhlIHJ1bGVzIGFyZSByZXZlcnNlZCwgdGhlbiBhbGwgRE5T IHBhY2tldHMgdG8gSVB2NiBhZGRyZXNzIDIwMDE6ZGI4OjovMzIgd2lsbCBiZSBhY2NlcHRlZCwg d2hldGhlciB0aGV5IGFyZSBmcmFnbWVudGVkIG9yIG5vdC4NCg0KQ2hlZXJzLg0KDQoNCkNoZWVy cywNCk1lZA0KDQpNYWhlc2ggSmV0aGFuYW5kYW5pDQptamV0aGFuYW5kYW5pQGdtYWlsLmNvbTxt YWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20+DQoNCg0K --_000_787AE7BB302AE849A7480A190F8B93302DF0E790OPEXCLILMA3corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUHLD qWZvcm1hdMOpIEhUTUwgQ2FyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bh bi5nbWFpbC1tLTQ2MjM2MjcxODk4MDAyNjA5NTlhcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNv LXN0eWxlLW5hbWU6Z21haWwtbV8tNDYyMzYyNzE4OTgwMDI2MDk1OWFwcGxlLWNvbnZlcnRlZC1z cGFjZTt9DQpzcGFuLm0tNDYyMzYyNzE4OTgwMDI2MDk1OWFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0K CXttc28tc3R5bGUtbmFtZTptXy00NjIzNjI3MTg5ODAwMjYwOTU5YXBwbGUtY29udmVydGVkLXNw YWNlO30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWls U3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250 LXN0eWxlOm5vcm1hbDt9DQpzcGFuLlByZm9ybWF0SFRNTENhcg0KCXttc28tc3R5bGUtbmFtZToi UHLDqWZvcm1hdMOpIEhUTUwgQ2FyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IlByw6lmb3JtYXTDqSBIVE1MIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXci Ow0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44 NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRlIiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+SGkgU29uYWwsDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+VGhhbmsgeW91IGZvciB0aGUgcmVwbHkuIE11Y2ggYXBw cmVjaWF0ZWQhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPlBsZWFzZSBzZWUgaW5saW5lLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPk1lZDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAw Y20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGUmbmJzcDs6PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFNvbmFsIEFnYXJ3YWwgW21haWx0 bzpzYWdhcndhbDEyQGdtYWlsLmNvbV0NCjxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiB2ZW5k cmVkaSAyMCBhdnJpbCAyMDE4IDAxOjM1PGJyPg0KPGI+w4AmbmJzcDs6PC9iPiBNYWhlc2ggSmV0 aGFuYW5kYW5pPGJyPg0KPGI+Q2MmbmJzcDs6PC9iPiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xO OyBkcmFmdC1pZXRmLW5ldG1vZC1hY2wtbW9kZWxAaWV0Zi5vcmc7IGRvdHNAaWV0Zi5vcmc7IEtl bnQgV2F0c2VuPGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBSZTogTWFpbCByZWdhcmRpbmcgZHJh ZnQtaWV0Zi1uZXRtb2QtYWNsLW1vZGVsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIE1lZCw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlJlcGxpZXMgaW5saW5lOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Q2FuIHlvdSBwbGVhc2Ug Y2xhcmlmeSB3aGV0aGVyIOKAnHByb3RvY29s4oCdIGNvdmVycyBvbmx5IHRoZSBiYXNlIElQdjYg aGVhZGVyIG9yIGl0IGluY2x1ZGVzIGFsc28g4oCcbmV4dCBoZWFkZXLigJ0gb2YgYW55IGVuY2xv c2VkIEV4dGVuc2lvbiBIZWFkZXI/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dDtmb250LXZhcmlhbnQtbGlnYXR1cmVzOm5vcm1hbDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7 dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWRlY29yYXRpb24tc3R5bGU6aW5pdGlhbDt0ZXh0LWRlY29y YXRpb24tY29sb3I6aW5pdGlhbDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjIyMjIyIj5UaGUgcHJvdG9j b2wgY292ZXJzIHRoZSBlbnRpcmUgSVB2NiBwYWNrZXQsIHdoaWNoIGluY2x1ZGVzIHRoZSBleHRl bnNpb24gaGVhZGVyKHMpLiBUaGUgRUgncyBkbyBub3QgaW5kaXZpZHVhbGx5IGNvbnRhaW4NCiB0 aGUgcHJvdG9jb2wgaW5mb3JtYXRpb24uIDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1yaWdodDozNi4wcHQ7YmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5bTWVkXSBBY3R1YWxseSwg4oCc cHJvdG9jb2zigJ0gaXMgZGVmaW5lZCBpbiB0aGUgbmV0bW9kLWFjbCBhcyBmb2xsb3dzOjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tcmln aHQ6MzYuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsgbGVhZiBwcm90b2NvbCB7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdHlwZSB1aW50ODs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkZXNjcmlwdGlvbjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O0ludGVy bmV0IFByb3RvY29sIG51bWJlci4gUmVmZXJzIHRvIHRoZSBwcm90b2NvbCBvZiB0aGU8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBwYXls b2FkLiBJbiBJUHY2LCB0aGlzIGZpZWxkIGlzIGtub3duIGFzICduZXh0LWhlYWRlci4mcXVvdDs7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1yaWdodDozNi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLXJpZ2h0OjM2LjBwdDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPlRoaXMgdGV4dCBpcyByZWFsbHkgbm90IGNsZWFy IHdoYXQgaXQgY292ZXJzLiBUaGlzIGlzIGNvbmZ1c2luZyBnaXZlbiB0aGF0IOKAnG5leHQgaGVh ZGVy4oCdIGlzIHByZXNlbnQgaW4gdGhlIGJhc2UNCiBoZWFkZXIgYW5kIGFsc28gaW4gRUhzLiA8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LXJpZ2h0OjM2LjBwdDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tcmlnaHQ6MzYuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+SW4gb3JkZXIgdG8gYXZvaWQgY29uZnVzaW9uLCBw bGVhc2UgY29uc2lkZXIgYWRkaW5nIG9uZSBzZW50ZW5jZSB0byB0d28gdG8gY2xhcmlmeSB0aGUg aW50ZW50Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1yaWdodDozNi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+V2hlbiBFSCdzIGFyZSBwcmVzZW50 LCB0aGVuIHRoZSBwcm90b2NvbCB3aWxsIGJlIGluIHRoZSAmcXVvdDtVcHBlciBsYXllciBoZWFk ZXImcXVvdDsuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMyMjIyMjI7YmFja2dyb3VuZDp3aGl0ZSI+ Rm9yIGV4YW1wbGUsIGRvZXMgdGhlIGZvbGxvd2luZyBBQ0wgYWNjZXB0IEROUyBwYWNrZXRzICYj NDM7IGRyb3AgZnJhZ21lbnRzIGVmZmljaWVudGx5Pw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMy MjIyMjI7YmFja2dyb3VuZDp3aGl0ZSI+RG9lcyBpdCB3b3JrIGV2ZW4gaWYgb3RoZXIgRUhzIGFy ZSBwcmVjZWRpbmcgYSBGcmFnbWVudCBoZWFkZXIgPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+Jm5ic3A7ICZuYnNwOyAmbmJzcDtJIGhhdmUgbm90IHNlZW4gYW4gQUNMIHRoYXQgaXMg dXNlZCB0byBmaWx0ZXIgRE5TIHBhY2tldHMsIGJ1dCBJIHByZXN1bWUgaXQgd291bGQgaGF2ZSB0 aGUgcHJvdG9jb2wgdG8gYmUgdGNwL3VkcCBhbmQgdGhlIEw0IHBvcnQgdG8gYmUgNTMuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0O2ZvbnQtdmFyaWFudC1saWdhdHVyZXM6bm9ybWFsO2Zv bnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtZGVjb3JhdGlvbi1z dHlsZTppbml0aWFsO3RleHQtZGVjb3JhdGlvbi1jb2xvcjppbml0aWFsO3dvcmQtc3BhY2luZzow cHgiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM1MDAwNTAiPiZxdW90O2FjZSZx dW90OzogWzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzUwMDA1MCI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjoj NTAwMDUwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgezwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzUwMDA1MCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjojNTAwMDUwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7bmFtZSZxdW90 OzogJnF1b3Q7ZHJvcC1hbGwtZnJhZ21lbnRzJnF1b3Q7LDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzUwMDA1MCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojNTAwMDUwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg JnF1b3Q7bWF0Y2hlcyZxdW90Ozogezwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzUwMDA1MCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjojNTAwMDUwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg JnF1b3Q7aXB2NiZxdW90Ozogezwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzUwMDA1MCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjojNTAwMDUwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJnF1b3Q7cHJvdG9jb2wmcXVvdDs6IDQ0PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojNTAwMDUwIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM1MDAwNTAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB9PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNTAw MDUwIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOiM1MDAwNTAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9LDwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzUwMDA1MCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojNTAwMDUwIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJnF1b3Q7YWN0aW9ucyZxdW90Ozogezwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzUwMDA1MCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjojNTAwMDUwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJnF1b3Q7Zm9yd2FyZGluZyZxdW90OzogJnF1b3Q7ZHJvcCZxdW90Ozwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzUwMDA1MCI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojNTAwMDUwIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgfTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzUwMDA1 MCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjojNTAwMDUwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgfTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzUwMDA1MCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjojNTAwMDUwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgXTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzUwMDA1MCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojNTAwMDUwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzUwMDA1 MCI+VGhpcyBBQ0UgaXMgc2F5aW5nIG1hdGNoIHByb3RvY29sIDQ0IGluIHVwcGVyIGhlYWRlciBh bmQgZHJvcCB0aGUgcGFja2V0LiBJdCB3aWxsIG9ubHkgd29yayBmb3IgcGFja2V0cyB0aGF0IGhh dmUgNDQgc2V0DQogYXMgdGhlIHByb3RvY29sLiBGb3IgaGFyZHdhcmUgdG8gdHJ1bHkgZHJvcCBh bGwgZnJhZ21lbnRlZCBwYWNrZXRzLCB0aGUgY29ycmVjdCBtYXRjaCB3b3VsZCBiZSBzb21ldGhp bmcgbGlrZSAmcXVvdDtkZW55IGFueSBhbnkgZnJhZyZxdW90Oy4gVGhpcyBpbmRpY2F0ZXMgdG8g ZGF0YXBsYW5lIHRvIGZpZ3VyZSBvdXQgaWYgYSBwYWNrZXQgaXMgYSBmcmFnbWVudCwgYW5kIHRo ZW4gZHJvcCBpdC48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzUw MDA1MCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojNTAwMDUwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0O2ZvbnQtdmFyaWFudC1saWdhdHVyZXM6bm9ybWFsO2ZvbnQtdmFyaWFudC1jYXBzOm5v cm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtZGVjb3JhdGlvbi1zdHlsZTppbml0aWFsO3RleHQt ZGVjb3JhdGlvbi1jb2xvcjppbml0aWFsO3dvcmQtc3BhY2luZzowcHgiPg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojNTAwMDUwIj4mcXVvdDthY2UmcXVvdDs6IFs8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM1MDAwNTAiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzUwMDA1MCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM1MDAwNTAi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 IzUwMDA1MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O25hbWUmcXVvdDs6ICZxdW90O2Fs bG93LWRucy1wYWNrZXRzJnF1b3Q7LDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzUwMDA1MCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjojNTAwMDUwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7bWF0Y2hl cyZxdW90Ozogezwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzUwMDA1 MCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjojNTAwMDUwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7aXB2NiZx dW90Ozogezwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzUwMDA1MCI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjoj NTAwMDUwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1 b3Q7ZGVzdGluYXRpb24taXB2Ni1uZXR3b3JrJnF1b3Q7OiAmcXVvdDsyMDAxOmRiODo6LzMyJnF1 b3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNTAwMDUwIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM1MDAw NTAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1t LTQ2MjM2MjcxODk4MDAyNjA5NTlhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6IzUwMDA1MCI+fTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzUwMDA1MCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOiM1MDAwNTAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVv dDt1ZHAmcXVvdDs6IHs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM1 MDAwNTAiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojNTAwMDUw Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7ZGVz dGluYXRpb24tcG9ydCZxdW90Ozogezwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzUwMDA1MCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OiM1MDAwNTAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmcXVvdDtvcGVyYXRvciZxdW90OzogJnF1b3Q7ZXEmcXVvdDssPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNTAwMDUwIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzUwMDA1MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O3BvcnQmcXVvdDs6IDUz PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNTAwMDUwIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzUwMDA1MCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLW0tNDYy MzYyNzE4OTgwMDI2MDk1OWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzUwMDA1MCI+fTwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzUwMDA1MCI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojNTAwMDUwIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgfTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzUwMDA1MCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjojNTAwMDUwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfSw8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM1MDAwNTAiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzUwMDA1MCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZxdW90O2FjdGlvbnMmcXVvdDs6IHs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiM1MDAwNTAiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzUwMDA1MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZxdW90O2ZvcndhcmRpbmcmcXVvdDs6ICZxdW90O2FjY2VwdCZxdW90Ozwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzUwMDA1MCI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojNTAwMDUwIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgfTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzUwMDA1MCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjojNTAwMDUwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzUwMDA1MCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjojNTAwMDUwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgXTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzUwMDA1MCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjojNTAwMDUwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgfTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzUwMDA1MCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjojNTAwMDUwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfTwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzUwMDA1MCI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojNTAwMDUwIj4mbmJz cDsmbmJzcDsmbmJzcDsgXTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzUwMDA1MCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojNTAwMDUwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzUwMDA1MCI+SSBw cmVzdW1lIHlvdSB3YW50IHRoZSBwcm90b2NvbCBoZXJlIHRvIGJlIGlwdjYuIFRoaXMgQUNFIGlu ZGljYXRlcyB0byBtYXRjaCBwYWNrZXRzIHdpdGggcHJvdG9jb2wgaXB2NiBhbmQgbWF0Y2ggb24g ZGVzdGluYXRpb24tcG9ydA0KIDUzLiBJbiBvcmRlciB0byBkbyB0aGlzLCBkYXRhcGxhbmUgbmVl ZHMgdG8gZXh0cmFjdCBMNCBpbmZvcm1hdGlvbiBmcm9tIHRoZSBwYXlsb2FkLiBJZiB0aGUgcGFj a2V0IG1hdGNoZXMgZGVzdGluYXRpb24gcG9ydCBvZiA1MywgdGhlbiBhY2NlcHQgdGhlIHBhY2tl dHMuIERhdGFwbGFuZSBzaG91bGQgYmUgY2FwYWJsZSBvZiBleHRyYWN0aW5nIEw0IGZyb20gdGhl IHBheWxvYWQsIHJlZ2FyZGxlc3Mgb2YgdGhlIG51bWJlciBvZiBleHRlbnNpb24NCiBoZWFkZXJz IHByZXNlbnQuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiM1MDAw NTAiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtjb2xvcjojNTAwMDUwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzUwMDA1MCI+VGhhbmtz LDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojNTAwMDUwIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzUwMDA1MCI+U29uYWwuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2NvbG9yOiM1MDAwNTAiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzUwMDA1MCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2NvbG9yOiM1MDAwNTAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBU aHUsIEFwciAxOSwgMjAxOCBhdCAxMjoxNyBQTSwgTWFoZXNoIEpldGhhbmFuZGFuaSAmbHQ7PGEg aHJlZj0ibWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWpl dGhhbmFuZGFuaUBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Nb2hhbWVkLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hpbGUgSSB3YWl0IGZvciBteSBjby1hdXRob3JzIHRvIGdl dCBiYWNrIHRvIG1lLCBoZXJlIGlzIG15IHRha2Ugb24gdGhpcy48bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBBcHIgMTYsIDIwMTgsIGF0IDg6MDggQU0sICZs dDs8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+Jmd0OyAmbHQ7PGEgaHJlZj0i bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iIHRhcmdldD0iX2JsYW5rIj5tb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij5EZWFyIGF1dGhvcnMsJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPldlIGRvIGhhdmUgYSBxdWVzdGlv biByZWdhcmRpbmcgdGhlIGludGVycHJldGF0aW9uIG9mIOKAnHByb3RvY29s4oCdIHdoZW4gYW4g SVB2NiBtYXRjaCBmaWx0ZXIgaXMgYXBwbGllZCBiZWNhdXNlIHRoZSBkcmFmdCBpcyBub3QgY2xl YXIuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPkNhbiB5b3UgcGxlYXNlIGNsYXJpZnkgd2hldGhlciDigJxwcm90 b2NvbOKAnSBjb3ZlcnMgb25seSB0aGUgYmFzZSBJUHY2IGhlYWRlciBvciBpdCBpbmNsdWRlcyBh bHNvIOKAnG5leHQgaGVhZGVy4oCdIG9mIGFueSBlbmNsb3NlZCBFeHRlbnNpb24gSGVhZGVyPzwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGN1cnJl bnQgZHJhZnQgY292ZXJzIG9ubHkgdGhlIGJhc2UgSVB2NiBoZWFkZXIuIEl0IGRvZXMgbm90IGNv dmVyIEV4dGVuc2lvbiBIZWFkZXJzLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB0aGVyZSBpcyBzdWNoIGEgcmVxdWlyZW1lbnQs IHdlIHdpbGwgaGF2ZSB0byB0YWtlIGl0IHVwIGluIHRoZSBiaXMgdmVyc2lvbiBvZiB0aGlzIGRy YWZ0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7 PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij5Gb3IgZXhhbXBsZSwgZG9lcyB0aGUgZm9sbG93aW5nIEFDTCBhY2NlcHQgRE5TIHBhY2tl dHMgJiM0MzsgZHJvcCBmcmFnbWVudHMgZWZmaWNpZW50bHk/IERvZXMgaXQgd29yayBldmVuIGlm IG90aGVyIEVIcyBhcmUgcHJlY2VkaW5nIGEgRnJhZ21lbnQgaGVhZGVyID88L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+ezwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7ICZxdW90O2lldGYtZG90cy1kYXRhLWNoYW5uZWw6YWNscyZxdW90Ozog ezwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O2FjbCZxdW90OzogWzwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmcXVvdDtuYW1lJnF1b3Q7OiAmcXVvdDtkbnMtZnJhZ21lbnRzJnF1b3Q7 LDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O3R5 cGUmcXVvdDs6ICZxdW90O2lwdjYtYWNsLXR5cGUmcXVvdDssPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7YWNlcyZxdW90Ozogezwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O2Fj ZSZxdW90OzogWzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVv dDtuYW1lJnF1b3Q7OiAmcXVvdDtkcm9wLWFsbC1mcmFnbWVudHMmcXVvdDssPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJnF1b3Q7bWF0Y2hlcyZxdW90Ozogezwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O2lwdjYmcXVvdDs6IHs8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtwcm90b2NvbCZxdW90OzogNDQ8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9PC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgfSw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDthY3Rpb25zJnF1b3Q7 OiB7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7Zm9yd2FyZGlu ZyZxdW90OzogJnF1b3Q7ZHJvcCZxdW90Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB9PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgXTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O2FjZSZxdW90OzogWzwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHs8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtuYW1lJnF1b3Q7OiAmcXVvdDthbGxvdy1kbnMt cGFja2V0cyZxdW90Oyw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDttYXRjaGVzJnF1 b3Q7OiB7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7aXB2NiZx dW90Ozogezwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZxdW90O2Rlc3RpbmF0aW9uLWlwdjYtbmV0d29yayZxdW90OzogJnF1b3Q7MjAwMTpkYjg6Oi8z MiZxdW90Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9 Im0tNDYyMzYyNzE4OTgwMDI2MDk1OWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu Pjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+fTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7dWRwJnF1 b3Q7OiB7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtkZXN0aW5h dGlvbi1wb3J0JnF1b3Q7OiB7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmcXVvdDtvcGVyYXRvciZxdW90OzogJnF1b3Q7ZXEmcXVvdDssPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtwb3J0JnF1b3Q7 OiA1Mzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0ibS00 NjIzNjI3MTg5ODAwMjYwOTU5YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+fTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IH08L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9LDwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZxdW90O2FjdGlvbnMmcXVvdDs6IHs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmcXVvdDtmb3J3YXJkaW5nJnF1b3Q7OiAmcXVvdDthY2NlcHQmcXVvdDs8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfTwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IF08L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9PC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgfTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IF08L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyB9 PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij59PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+QWdhaW4sIG15IHBlcnNvbmFsIHRha2Ugb24gaXQgKGFuZCBJIHdpbGwg d2FpdCBmb3IgbXkgY28tYXV0aG9ycyB0byBjb3JyZWN0IG1lIGlmIEkgYW0gd3JvbmcpLCBpcyB0 aGF0IHRoZXNlIGFyZSB0d28gc2VwYXJhdGUgZW50cmllcy4gRGVwZW5kaW5nIG9uIHRoZSBvcmRl ciBvZiB0aGUgcnVsZXMsIGFuZCBhZ2FpbiBhc3N1bWluZyB0aGUgcnVsZXMgYXJlIGluIHRoZSBv cmRlciBzdGF0ZWQgYWJvdmUsIGlmIHlvdQ0KIGRvIHJlY2VpdmUgYSBmcmFnbWVudGVkIEROUyBw YWNrZXQsIHRoZSBzZWNvbmQgcnVsZSB3aWxsIG5ldmVyIGJlIGhpdC4gVGhlIGZpcnN0IHJ1bGUg d291bGQgYXBwbHkgYW5kIHRoZSBwYWNrZXQgd2lsbCBiZSBkcm9wcGVkLiBJZiB0aGUgcnVsZXMg YXJlIHJldmVyc2VkLCB0aGVuIGFsbCBETlMgcGFja2V0cyB0byBJUHY2IGFkZHJlc3MmbmJzcDs8 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+MjAwMTpkYjg6Oi8zMjwvc3Bhbj4mbmJzcDt3aWxsDQogYmUgYWNjZXB0ZWQsIHdo ZXRoZXIgdGhleSBhcmUgZnJhZ21lbnRlZCBvciBub3QuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNoZWVycy48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij5DaGVlcnMsPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5NZWQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJob2VuemIiPjxzcGFuIHN0 eWxlPSJjb2xvcjojODg4ODg4Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4 ODg4OCI+TWFoZXNoIEpldGhhbmFuZGFuaTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48 YSBocmVmPSJtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5t amV0aGFuYW5kYW5pQGdtYWlsLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_787AE7BB302AE849A7480A190F8B93302DF0E790OPEXCLILMA3corp_-- From nobody Fri Apr 20 12:18:28 2018 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 62B8212D870; Fri, 20 Apr 2018 12:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 6oF8Mza_yhbJ; Fri, 20 Apr 2018 12:18:22 -0700 (PDT) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (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 7E4C0129C6D; Fri, 20 Apr 2018 12:18:22 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id m21so1412554pgv.8; Fri, 20 Apr 2018 12:18:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Hvm0MAZAm1tARKOaGBQNS8i4QCP0IG9f89mIvAHpJV8=; b=oU2BOFQCxvx/1QkHY2ZayYxxYB8ieCrDXKHQtku1nNXJ2UNSguNytFXJWuFNZMxvNv 3k79yCS4sPc2NILskOAXvckqnH5Ca1qfhjmM71ASTPPLajxTHzTxFjOIGBOWu1Nx2GuV ItTZz4QVfFrZCjuFuttEf5wgE8Z8JlsVXSCshST3QktDCA3eZBCefzO4oT7M7PNHfFFN 6Q5EZjpKuOlkg4Hn0dZTEQlg9rAWp3owtOQ+uJpAhIs3diH1m61E6vd6Ak/+WELOcSQI eCVexBMYVZnNYutP5tvO6Yi3+alAAxr7wMcWSHjhai+z2Dj1kAYesrCHQRSQssAydMTy pkjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Hvm0MAZAm1tARKOaGBQNS8i4QCP0IG9f89mIvAHpJV8=; b=i84FRg0UVABjqzMwjoqXodrjxJ8eVgKEjg48mUUsL2KcP5Xu0oSlLArHwjKLZlc5pR hP1n08iePGlwssUozaGKjjjJxiWi78EAkU/jQ4L3bGs0IPA0I095dlYSHa+ZOW4C/E+G XSCvY/D0VfN/mP9Js3usOrD6xLYqoGr406GMxq1+2QUnrraZCgeRt9j/6eCp1v5NCmGF jpBO4U0HciOccSrWgjP/yx7vp8pIUUxjk5YPWAK9gXbFckjrZdyAEbJU63gnuxFAfzDN yXaA9Ar3S78Sb5xWCFBfjPmYIx8WsqssYS6BWFBpsWRCnbcnXLhzxgcJRQ7aj24TEE5K HBLQ== X-Gm-Message-State: ALQs6tCrac5KYctBu+XfQ39IKElNjL0b7BPIXVIMIfBEvz0RZnLwW8Nz m3ih1lK4cTmNXi/Zu9sUTpQ= X-Google-Smtp-Source: AIpwx4+evog7awnwHcL8LzX0mIWaw3gTEpJaGlUlnUyXpSqnhh3klSXkib/e3v40gj2rTKyVkq7zhA== X-Received: by 10.167.128.2 with SMTP id j2mr10619381pfi.126.1524251901722; Fri, 20 Apr 2018 12:18:21 -0700 (PDT) Received: from ?IPv6:2601:647:4700:1280:24b9:330:64fe:8aae? ([2601:647:4700:1280:24b9:330:64fe:8aae]) by smtp.gmail.com with ESMTPSA id u7sm14355546pfa.96.2018.04.20.12.18.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Apr 2018 12:18:20 -0700 (PDT) From: Mahesh Jethanandani Message-Id: <2644EFA1-0333-4912-B4BB-104B4F6569B3@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_36A2768E-1CAE-444E-81F7-E1FA4BDCAC1D" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Fri, 20 Apr 2018 12:18:19 -0700 In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DF0E790@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Cc: Sonal Agarwal , "draft-ietf-netmod-acl-model@ietf.org" , "dots@ietf.org" , Kent Watsen To: mohamed.boucadair@orange.com References: <787AE7BB302AE849A7480A190F8B93302DF0B7FE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DF0E790@OPEXCLILMA3.corporate.adroot.infra.ftgroup> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [Dots] Mail regarding draft-ietf-netmod-acl-model 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, 20 Apr 2018 19:18:25 -0000 --Apple-Mail=_36A2768E-1CAE-444E-81F7-E1FA4BDCAC1D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Med, See comment inline with [mj] > On Apr 19, 2018, at 10:46 PM, = wrote: >=20 > Hi Sonal, > =20 > Thank you for the reply. Much appreciated! > =20 > Please see inline. > =20 > Cheers, > Med > =20 > De : Sonal Agarwal [mailto:sagarwal12@gmail.com = ]=20 > Envoy=C3=A9 : vendredi 20 avril 2018 01:35 > =C3=80 : Mahesh Jethanandani > Cc : BOUCADAIR Mohamed IMT/OLN; draft-ietf-netmod-acl-model@ietf.org = ; dots@ietf.org = ; Kent Watsen > Objet : Re: Mail regarding draft-ietf-netmod-acl-model > =20 > Hi Med, > =20 > Replies inline: > =20 > Can you please clarify whether =E2=80=9Cprotocol=E2=80=9D covers only = the base IPv6 header or it includes also =E2=80=9Cnext header=E2=80=9D = of any enclosed Extension Header? > The protocol covers the entire IPv6 packet, which includes the = extension header(s). The EH's do not individually contain the protocol = information.=20 > [Med] Actually, =E2=80=9Cprotocol=E2=80=9D is defined in the = netmod-acl as follows: > =20 > leaf protocol { > type uint8; > description > "Internet Protocol number. Refers to the protocol of the > payload. In IPv6, this field is known as 'next-header."; > =20 > This text is really not clear what it covers. This is confusing given = that =E2=80=9Cnext header=E2=80=9D is present in the base header and = also in EHs.=20 > =20 > In order to avoid confusion, please consider adding one sentence to = two to clarify the intent. > =20 > When EH's are present, then the protocol will be in the "Upper layer = header=E2=80=9D. [mj] Med, how about this? OLD: Internet Protocol number. Refers to the protocol of the payload. In IPv6, this field is known as 'next-header. NEW: Internet Protocol number. Refers to the protocol of the payload. In IPv6, this field is known as 'next-header', and if extension headers are present, the protocol is present in the 'upper-layer' header. > =20 > For example, does the following ACL accept DNS packets + drop = fragments efficiently?Does it work even if other EHs are preceding a = Fragment header ? > =20 > I have not seen an ACL that is used to filter DNS packets, but I = presume it would have the protocol to be tcp/udp and the L4 port to be = 53. > "ace": [ > { > "name": "drop-all-fragments", > "matches": { > "ipv6": { > "protocol": 44 > } > }, > "actions": { > "forwarding": "drop" > } > } > ] > =20 > This ACE is saying match protocol 44 in upper header and drop the = packet. It will only work for packets that have 44 set as the protocol. = For hardware to truly drop all fragmented packets, the correct match = would be something like "deny any any frag". This indicates to dataplane = to figure out if a packet is a fragment, and then drop it. > =20 > "ace": [ > { > "name": "allow-dns-packets", > "matches": { > "ipv6": { > "destination-ipv6-network": "2001:db8::/32" > } > "udp": { > "destination-port": { > "operator": "eq", > "port": 53 > } > } > }, > "actions": { > "forwarding": "accept" > } > } > ] > } > } > ] > =20 > I presume you want the protocol here to be ipv6. This ACE indicates to = match packets with protocol ipv6 and match on destination-port 53. In = order to do this, dataplane needs to extract L4 information from the = payload. If the packet matches destination port of 53, then accept the = packets. Dataplane should be capable of extracting L4 from the payload, = regardless of the number of extension headers present. > =20 > Thanks, > Sonal. > =20 > =20 > =20 > =20 > On Thu, Apr 19, 2018 at 12:17 PM, Mahesh Jethanandani = > wrote: > Mohamed, > =20 > While I wait for my co-authors to get back to me, here is my take on = this. >=20 >=20 > On Apr 16, 2018, at 8:08 AM, > > wrote: > =20 > Dear authors,=20 > =20 > We do have a question regarding the interpretation of =E2=80=9Cprotocol=E2= =80=9D when an IPv6 match filter is applied because the draft is not = clear. > =20 > Can you please clarify whether =E2=80=9Cprotocol=E2=80=9D covers only = the base IPv6 header or it includes also =E2=80=9Cnext header=E2=80=9D = of any enclosed Extension Header? > =20 > The current draft covers only the base IPv6 header. It does not cover = Extension Headers.=20 > =20 > If there is such a requirement, we will have to take it up in the bis = version of this draft. >=20 >=20 > =20 > For example, does the following ACL accept DNS packets + drop = fragments efficiently? Does it work even if other EHs are preceding a = Fragment header ? > =20 > { > "ietf-dots-data-channel:acls": { > "acl": [ > { > "name": "dns-fragments", > "type": "ipv6-acl-type", > "aces": { > "ace": [ > { > "name": "drop-all-fragments", > "matches": { > "ipv6": { > "protocol": 44 > } > }, > "actions": { > "forwarding": "drop" > } > } > ] > "ace": [ > { > "name": "allow-dns-packets", > "matches": { > "ipv6": { > "destination-ipv6-network": "2001:db8::/32" > } > "udp": { > "destination-port": { > "operator": "eq", > "port": 53 > } > } > }, > "actions": { > "forwarding": "accept" > } > } > ] > } > } > ] > } > } > =20 > Again, my personal take on it (and I will wait for my co-authors to = correct me if I am wrong), is that these are two separate entries. = Depending on the order of the rules, and again assuming the rules are in = the order stated above, if you do receive a fragmented DNS packet, the = second rule will never be hit. The first rule would apply and the packet = will be dropped. If the rules are reversed, then all DNS packets to IPv6 = address 2001:db8::/32 will be accepted, whether they are fragmented or = not. > =20 > Cheers. >=20 >=20 > Cheers, > Med > =20 > Mahesh Jethanandani > mjethanandani@gmail.com Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_36A2768E-1CAE-444E-81F7-E1FA4BDCAC1D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Med,

See = comment inline with [mj]

On Apr 19, 2018, at 10:46 PM, = <mohamed.boucadair@orange.com> <mohamed.boucadair@orange.com> wrote:

Hi Sonal,
 
Thank you for the = reply. Much appreciated!
 
Please see = inline.
 
Cheers,
Med
 
De : Sonal Agarwal [mailto:sagarwal12@gmail.com] 
Envoy=C3=A9 : vendredi 20 avril 2018 = 01:35
=C3=80 : Mahesh Jethanandani
Cc : BOUCADAIR Mohamed = IMT/OLN; draft-ietf-netmod-acl-model@ietf.org; dots@ietf.org; Kent Watsen
Objet : Re: Mail regarding = draft-ietf-netmod-acl-model
 
Hi Med,
 
Replies = inline:
 
Can you please clarify = whether =E2=80=9Cprotocol=E2=80=9D covers only the base IPv6 header or = it includes also =E2=80=9Cnext header=E2=80=9D of any enclosed Extension = Header?
The = protocol covers the entire IPv6 packet, which includes the extension = header(s). The EH's do not individually contain the protocol = information. 
[Med] Actually, =E2=80=9Cprotocol=E2=80=9D is defined in the = netmod-acl as follows:
 
    = leaf protocol {
      type uint8;
      = description
        "Internet Protocol = number. Refers to the protocol of the
         payload. In = IPv6, this field is known as 'next-header.";
 
This text is really not clear what it covers. = This is confusing given that =E2=80=9Cnext header=E2=80=9D is present in = the base header and also in EHs. 
 
In order to avoid confusion, please consider = adding one sentence to two to clarify the intent.
 
When EH's are present, then the = protocol will be in the "Upper layer = header=E2=80=9D.

[mj] Med, how = about this?

OLD:

Internet Protocol number. Refers = to the protocol of the
payload. In IPv6, = this field is known as 'next-header.

NEW:

Internet Protocol number. Refers to the protocol of = the
payload. In IPv6, this field is = known as 'next-header',
and if extension = headers are present, the protocol
is present in the 'upper-layer' = header.


 
For example, = does the following ACL accept DNS packets + drop fragments = efficiently?Does it work even if other EHs are preceding a = Fragment header ?
 
     I have = not seen an ACL that is used to filter DNS packets, but I presume it = would have the protocol to be tcp/udp and the L4 port to be = 53.
"ace": [
          &nb= sp; {
          &nb= sp;   "name": "drop-all-fragments",
          &nb= sp;   "matches": {
          &nb= sp;     "ipv6": {
          &nb= sp;       "protocol": 44
          &nb= sp;     }
          &nb= sp;   },
          &nb= sp;   "actions": {
          &nb= sp;     "forwarding": "drop"
          &nb= sp;   }
          &nb= sp; }
          = ]
 
This ACE is saying = match protocol 44 in upper header and drop the packet. It will only work = for packets that have 44 set as the protocol. For hardware to truly drop = all fragmented packets, the correct match would be something like "deny = any any frag". This indicates to dataplane to figure out if a packet is = a fragment, and then drop it.
 
"ace": = [
          &nb= sp; {
          &nb= sp;   "name": "allow-dns-packets",
          &nb= sp;   "matches": {
          &nb= sp;     "ipv6": {
          &nb= sp;       "destination-ipv6-network": = "2001:db8::/32"
          &nb= sp;     }
          &nb= sp;     "udp": {
          &nb= sp;       "destination-port": = {
          &nb= sp;         "operator": = "eq",
          &nb= sp;         "port": = 53
          &nb= sp;       }
          &nb= sp;     }
          &nb= sp;   },
          &nb= sp;   "actions": {
          &nb= sp;     "forwarding": "accept"
          &nb= sp;   }
          &nb= sp; }
          = ]
        }
      }
    ]
 
I presume you want = the protocol here to be ipv6. This ACE indicates to match packets with = protocol ipv6 and match on destination-port 53. In order to do this, = dataplane needs to extract L4 information from the payload. If the = packet matches destination port of 53, then accept the packets. = Dataplane should be capable of extracting L4 from the payload, = regardless of the number of extension headers present.
 
Thanks,
Sonal.
 
 
 
 
On Thu, Apr = 19, 2018 at 12:17 PM, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:
Mohamed,
 
While I wait for my co-authors to get = back to me, here is my take on this.


On Apr 16, 2018, at 8:08 = AM, <mohamed.boucadair@orange.com> <mohamed.boucadair@orange.com> wrote:
 
Dear authors, 
 
We do have a = question regarding the interpretation of =E2=80=9Cprotocol=E2=80=9D when = an IPv6 match filter is applied because the draft is not = clear.
 
Can you please = clarify whether =E2=80=9Cprotocol=E2=80=9D covers only the base IPv6 = header or it includes also =E2=80=9Cnext header=E2=80=9D of any enclosed = Extension Header?
 
The current draft covers only the base IPv6 header. = It does not cover Extension Headers. 
 
If there is = such a requirement, we will have to take it up in the bis version of = this draft.


 
For example, does the following ACL accept DNS packets + drop = fragments efficiently? Does it work even if other EHs are preceding a = Fragment header ?
 
{
  "ietf-dots-data-channel:acls": = {
    "acl": [
      {
        "name": = "dns-fragments",
        "type": = "ipv6-acl-type",
        "aces": = {
          "ace": = [
          &nb= sp; {
          &nb= sp;   "name": "drop-all-fragments",
          &nb= sp;   "matches": {
          &nb= sp;     "ipv6": {
          &nb= sp;       "protocol": 44
          &nb= sp;     }
          &nb= sp;   },
          &nb= sp;   "actions": {
          &nb= sp;     "forwarding": "drop"
          &nb= sp;   }
          &nb= sp; }
          = ]
          "ace": = [
          &nb= sp; {
          &nb= sp;   "name": "allow-dns-packets",
          &nb= sp;   "matches": {
          &nb= sp;     "ipv6": {
          &nb= sp;       "destination-ipv6-network": = "2001:db8::/32"
          &nb= sp;     <= span style=3D"font-size: 10pt; font-family: "Courier New";" = class=3D"">}
          &nb= sp;     "udp": {
          &nb= sp;       "destination-port": = {
          &nb= sp;         "operator": = "eq",
          &nb= sp;         "port": = 53
          &nb= sp;       <= span lang=3D"EN-US" style=3D"font-size: 10pt; font-family: "Courier = New";" class=3D"">}
          &nb= sp;     }
          &nb= sp;   },
          &nb= sp;   "actions": {
          &nb= sp;     "forwarding": "accept"
          &nb= sp;   }
          &nb= sp; }
          = ]
        = }
      }
    ]
  = }
}
 
Again, my personal take on it (and I will wait for my = co-authors to correct me if I am wrong), is that these are two separate = entries. Depending on the order of the rules, and again assuming the = rules are in the order stated above, if you do receive a fragmented DNS = packet, the second rule will never be hit. The first rule would apply = and the packet will be dropped. If the rules are reversed, then all DNS = packets to IPv6 address 2001:db8::/32 will be accepted, whether they are = fragmented or not.
 
Cheers.


Cheers,
Med
 
Mahesh = Jethanandani
mjethanandani@gmail.com

Mahesh Jethanandani
mjethanandani@gmail.com

= --Apple-Mail=_36A2768E-1CAE-444E-81F7-E1FA4BDCAC1D-- From nobody Sun Apr 22 23:13:59 2018 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 27ABD120047; Sun, 22 Apr 2018 23:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T8wjt3vluTXu; Sun, 22 Apr 2018 23:13:55 -0700 (PDT) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EE001204DA; Sun, 22 Apr 2018 23:13:55 -0700 (PDT) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 854E0C0BA4; Mon, 23 Apr 2018 08:13:53 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.63]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 4D027C0064; Mon, 23 Apr 2018 08:13:53 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6E.corporate.adroot.infra.ftgroup ([fe80::f5a7:eab1:c095:d9ec%18]) with mapi id 14.03.0389.001; Mon, 23 Apr 2018 08:13:53 +0200 From: To: Mahesh Jethanandani CC: Sonal Agarwal , "draft-ietf-netmod-acl-model@ietf.org" , "dots@ietf.org" , "Kent Watsen" Thread-Topic: Mail regarding draft-ietf-netmod-acl-model Thread-Index: AdPVlMZLfgl8LrjkRwqP1O1MsxSS7ADR5UyyAHrjxpA= Date: Mon, 23 Apr 2018 06:13:52 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DF0F9AC@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93302DF0B7FE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DF0E790@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <2644EFA1-0333-4912-B4BB-104B4F6569B3@gmail.com> In-Reply-To: <2644EFA1-0333-4912-B4BB-104B4F6569B3@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93302DF0F9ACOPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Mail regarding draft-ietf-netmod-acl-model 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, 23 Apr 2018 06:13:58 -0000 --_000_787AE7BB302AE849A7480A190F8B93302DF0F9ACOPEXCLILMA3corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFoZXNoLA0KDQpUaGFuayB5b3UuDQoNCkkgc3VnZ2VzdCB0aGlzIG1vZGlmaWVkIE5FVyB0 ZXh0Og0KDQogICBJbnRlcm5ldCBQcm90b2NvbCBudW1iZXIuIFJlZmVycyB0byB0aGUgcHJvdG9j b2wgb2YgdGhlDQoNCiAgIHBheWxvYWQuIFRoYXQgaXMsIHRoZSBwcm90b2NvbCBsYXllciBpbW1l ZGlhdGVseSBhYm92ZSBJUHY2ICh1cHBlciBsYXllcikuDQogICBUaGlzIGlzIGluZGljYXRlZCBp biB0aGUgJ25leHQgaGVhZGVyJyBvZiB0aGUgSVB2NiBoZWFkZXIgd2hlbg0KICAgbm8gZXh0ZW5z aW9uIGhlYWRlcnMgYXJlIHByZXNlbnQuDQogICBXaGVuIHByb2Nlc3NpbmcgYSBzZXF1ZW5jZSBv ZiBOZXh0IEhlYWRlciB2YWx1ZXMgaW4gYSBwYWNrZXQsDQoNCiAgIHRoZSBmaXJzdCBvbmUgdGhh dCBpcyBub3QgYW4gZXh0ZW5zaW9uIGhlYWRlciBpbmRpY2F0ZXMgdGhhdA0KDQogICB0aGUgbmV4 dCBpdGVtIGluIHRoZSBwYWNrZXQgaXMgdGhlIGNvcnJlc3BvbmRpbmcgdXBwZXItbGF5ZXINCg0K ICAgaGVhZGVyLg0KDQoNCg0KQ2hlZXJzLA0KDQpNZWQNCg0KRGUgOiBNYWhlc2ggSmV0aGFuYW5k YW5pIFttYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb21dDQpFbnZvecOpIDogdmVuZHJlZGkg MjAgYXZyaWwgMjAxOCAyMToxOA0Kw4AgOiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xODQpDYyA6 IFNvbmFsIEFnYXJ3YWw7IGRyYWZ0LWlldGYtbmV0bW9kLWFjbC1tb2RlbEBpZXRmLm9yZzsgZG90 c0BpZXRmLm9yZzsgS2VudCBXYXRzZW4NCk9iamV0IDogUmU6IE1haWwgcmVnYXJkaW5nIGRyYWZ0 LWlldGYtbmV0bW9kLWFjbC1tb2RlbA0KDQpNZWQsDQoNClNlZSBjb21tZW50IGlubGluZSB3aXRo IFttal0NCg0KDQpPbiBBcHIgMTksIDIwMTgsIGF0IDEwOjQ2IFBNLCA8bW9oYW1lZC5ib3VjYWRh aXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4+IDxtb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2Uu Y29tPj4gd3JvdGU6DQoNCkhpIFNvbmFsLA0KDQpUaGFuayB5b3UgZm9yIHRoZSByZXBseS4gTXVj aCBhcHByZWNpYXRlZCENCg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoNCkNoZWVycywNCk1lZA0KDQpE ZSA6IFNvbmFsIEFnYXJ3YWwgW21haWx0bzpzYWdhcndhbDEyQGdtYWlsLmNvbV0NCkVudm95w6kg OiB2ZW5kcmVkaSAyMCBhdnJpbCAyMDE4IDAxOjM1DQrDgCA6IE1haGVzaCBKZXRoYW5hbmRhbmkN CkNjIDogQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTjsgZHJhZnQtaWV0Zi1uZXRtb2QtYWNsLW1v ZGVsQGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLW5ldG1vZC1hY2wtbW9kZWxAaWV0Zi5vcmc+ OyBkb3RzQGlldGYub3JnPG1haWx0bzpkb3RzQGlldGYub3JnPjsgS2VudCBXYXRzZW4NCk9iamV0 IDogUmU6IE1haWwgcmVnYXJkaW5nIGRyYWZ0LWlldGYtbmV0bW9kLWFjbC1tb2RlbA0KDQpIaSBN ZWQsDQoNClJlcGxpZXMgaW5saW5lOg0KDQpDYW4geW91IHBsZWFzZSBjbGFyaWZ5IHdoZXRoZXIg 4oCccHJvdG9jb2zigJ0gY292ZXJzIG9ubHkgdGhlIGJhc2UgSVB2NiBoZWFkZXIgb3IgaXQgaW5j bHVkZXMgYWxzbyDigJxuZXh0IGhlYWRlcuKAnSBvZiBhbnkgZW5jbG9zZWQgRXh0ZW5zaW9uIEhl YWRlcj8NClRoZSBwcm90b2NvbCBjb3ZlcnMgdGhlIGVudGlyZSBJUHY2IHBhY2tldCwgd2hpY2gg aW5jbHVkZXMgdGhlIGV4dGVuc2lvbiBoZWFkZXIocykuIFRoZSBFSCdzIGRvIG5vdCBpbmRpdmlk dWFsbHkgY29udGFpbiB0aGUgcHJvdG9jb2wgaW5mb3JtYXRpb24uDQpbTWVkXSBBY3R1YWxseSwg 4oCccHJvdG9jb2zigJ0gaXMgZGVmaW5lZCBpbiB0aGUgbmV0bW9kLWFjbCBhcyBmb2xsb3dzOg0K DQogICAgbGVhZiBwcm90b2NvbCB7DQogICAgICB0eXBlIHVpbnQ4Ow0KICAgICAgZGVzY3JpcHRp b24NCiAgICAgICAgIkludGVybmV0IFByb3RvY29sIG51bWJlci4gUmVmZXJzIHRvIHRoZSBwcm90 b2NvbCBvZiB0aGUNCiAgICAgICAgIHBheWxvYWQuIEluIElQdjYsIHRoaXMgZmllbGQgaXMga25v d24gYXMgJ25leHQtaGVhZGVyLiI7DQoNClRoaXMgdGV4dCBpcyByZWFsbHkgbm90IGNsZWFyIHdo YXQgaXQgY292ZXJzLiBUaGlzIGlzIGNvbmZ1c2luZyBnaXZlbiB0aGF0IOKAnG5leHQgaGVhZGVy 4oCdIGlzIHByZXNlbnQgaW4gdGhlIGJhc2UgaGVhZGVyIGFuZCBhbHNvIGluIEVIcy4NCg0KSW4g b3JkZXIgdG8gYXZvaWQgY29uZnVzaW9uLCBwbGVhc2UgY29uc2lkZXIgYWRkaW5nIG9uZSBzZW50 ZW5jZSB0byB0d28gdG8gY2xhcmlmeSB0aGUgaW50ZW50Lg0KDQpXaGVuIEVIJ3MgYXJlIHByZXNl bnQsIHRoZW4gdGhlIHByb3RvY29sIHdpbGwgYmUgaW4gdGhlICJVcHBlciBsYXllciBoZWFkZXLi gJ0uDQoNClttal0gTWVkLCBob3cgYWJvdXQgdGhpcz8NCg0KT0xEOg0KDQpJbnRlcm5ldCBQcm90 b2NvbCBudW1iZXIuIFJlZmVycyB0byB0aGUgcHJvdG9jb2wgb2YgdGhlDQpwYXlsb2FkLiBJbiBJ UHY2LCB0aGlzIGZpZWxkIGlzIGtub3duIGFzICduZXh0LWhlYWRlci4NCg0KTkVXOg0KDQpJbnRl cm5ldCBQcm90b2NvbCBudW1iZXIuIFJlZmVycyB0byB0aGUgcHJvdG9jb2wgb2YgdGhlDQpwYXls b2FkLiBJbiBJUHY2LCB0aGlzIGZpZWxkIGlzIGtub3duIGFzICduZXh0LWhlYWRlcicsDQphbmQg aWYgZXh0ZW5zaW9uIGhlYWRlcnMgYXJlIHByZXNlbnQsIHRoZSBwcm90b2NvbA0KaXMgcHJlc2Vu dCBpbiB0aGUgJ3VwcGVyLWxheWVyJyBoZWFkZXIuDQoNCg0KDQoNCkZvciBleGFtcGxlLCBkb2Vz IHRoZSBmb2xsb3dpbmcgQUNMIGFjY2VwdCBETlMgcGFja2V0cyArIGRyb3AgZnJhZ21lbnRzIGVm ZmljaWVudGx5P0RvZXMgaXQgd29yayBldmVuIGlmIG90aGVyIEVIcyBhcmUgcHJlY2VkaW5nIGEg RnJhZ21lbnQgaGVhZGVyID8NCg0KICAgICBJIGhhdmUgbm90IHNlZW4gYW4gQUNMIHRoYXQgaXMg dXNlZCB0byBmaWx0ZXIgRE5TIHBhY2tldHMsIGJ1dCBJIHByZXN1bWUgaXQgd291bGQgaGF2ZSB0 aGUgcHJvdG9jb2wgdG8gYmUgdGNwL3VkcCBhbmQgdGhlIEw0IHBvcnQgdG8gYmUgNTMuDQoiYWNl IjogWw0KICAgICAgICAgICAgew0KICAgICAgICAgICAgICAibmFtZSI6ICJkcm9wLWFsbC1mcmFn bWVudHMiLA0KICAgICAgICAgICAgICAibWF0Y2hlcyI6IHsNCiAgICAgICAgICAgICAgICAiaXB2 NiI6IHsNCiAgICAgICAgICAgICAgICAgICJwcm90b2NvbCI6IDQ0DQogICAgICAgICAgICAgICAg fQ0KICAgICAgICAgICAgICB9LA0KICAgICAgICAgICAgICAiYWN0aW9ucyI6IHsNCiAgICAgICAg ICAgICAgICAiZm9yd2FyZGluZyI6ICJkcm9wIg0KICAgICAgICAgICAgICB9DQogICAgICAgICAg ICB9DQogICAgICAgICAgXQ0KDQpUaGlzIEFDRSBpcyBzYXlpbmcgbWF0Y2ggcHJvdG9jb2wgNDQg aW4gdXBwZXIgaGVhZGVyIGFuZCBkcm9wIHRoZSBwYWNrZXQuIEl0IHdpbGwgb25seSB3b3JrIGZv ciBwYWNrZXRzIHRoYXQgaGF2ZSA0NCBzZXQgYXMgdGhlIHByb3RvY29sLiBGb3IgaGFyZHdhcmUg dG8gdHJ1bHkgZHJvcCBhbGwgZnJhZ21lbnRlZCBwYWNrZXRzLCB0aGUgY29ycmVjdCBtYXRjaCB3 b3VsZCBiZSBzb21ldGhpbmcgbGlrZSAiZGVueSBhbnkgYW55IGZyYWciLiBUaGlzIGluZGljYXRl cyB0byBkYXRhcGxhbmUgdG8gZmlndXJlIG91dCBpZiBhIHBhY2tldCBpcyBhIGZyYWdtZW50LCBh bmQgdGhlbiBkcm9wIGl0Lg0KDQoiYWNlIjogWw0KICAgICAgICAgICAgew0KICAgICAgICAgICAg ICAibmFtZSI6ICJhbGxvdy1kbnMtcGFja2V0cyIsDQogICAgICAgICAgICAgICJtYXRjaGVzIjog ew0KICAgICAgICAgICAgICAgICJpcHY2Ijogew0KICAgICAgICAgICAgICAgICAgImRlc3RpbmF0 aW9uLWlwdjYtbmV0d29yayI6ICIyMDAxOmRiODo6LzMyIg0KICAgICAgICAgICAgICAgIH0NCiAg ICAgICAgICAgICAgICAidWRwIjogew0KICAgICAgICAgICAgICAgICAgImRlc3RpbmF0aW9uLXBv cnQiOiB7DQogICAgICAgICAgICAgICAgICAgICJvcGVyYXRvciI6ICJlcSIsDQogICAgICAgICAg ICAgICAgICAgICJwb3J0IjogNTMNCiAgICAgICAgICAgICAgICAgIH0NCiAgICAgICAgICAgICAg ICB9DQogICAgICAgICAgICAgIH0sDQogICAgICAgICAgICAgICJhY3Rpb25zIjogew0KICAgICAg ICAgICAgICAgICJmb3J3YXJkaW5nIjogImFjY2VwdCINCiAgICAgICAgICAgICAgfQ0KICAgICAg ICAgICAgfQ0KICAgICAgICAgIF0NCiAgICAgICAgfQ0KICAgICAgfQ0KICAgIF0NCg0KSSBwcmVz dW1lIHlvdSB3YW50IHRoZSBwcm90b2NvbCBoZXJlIHRvIGJlIGlwdjYuIFRoaXMgQUNFIGluZGlj YXRlcyB0byBtYXRjaCBwYWNrZXRzIHdpdGggcHJvdG9jb2wgaXB2NiBhbmQgbWF0Y2ggb24gZGVz dGluYXRpb24tcG9ydCA1My4gSW4gb3JkZXIgdG8gZG8gdGhpcywgZGF0YXBsYW5lIG5lZWRzIHRv IGV4dHJhY3QgTDQgaW5mb3JtYXRpb24gZnJvbSB0aGUgcGF5bG9hZC4gSWYgdGhlIHBhY2tldCBt YXRjaGVzIGRlc3RpbmF0aW9uIHBvcnQgb2YgNTMsIHRoZW4gYWNjZXB0IHRoZSBwYWNrZXRzLiBE YXRhcGxhbmUgc2hvdWxkIGJlIGNhcGFibGUgb2YgZXh0cmFjdGluZyBMNCBmcm9tIHRoZSBwYXls b2FkLCByZWdhcmRsZXNzIG9mIHRoZSBudW1iZXIgb2YgZXh0ZW5zaW9uIGhlYWRlcnMgcHJlc2Vu dC4NCg0KVGhhbmtzLA0KU29uYWwuDQoNCg0KDQoNCk9uIFRodSwgQXByIDE5LCAyMDE4IGF0IDEy OjE3IFBNLCBNYWhlc2ggSmV0aGFuYW5kYW5pIDxtamV0aGFuYW5kYW5pQGdtYWlsLmNvbTxtYWls dG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20+PiB3cm90ZToNCk1vaGFtZWQsDQoNCldoaWxlIEkg d2FpdCBmb3IgbXkgY28tYXV0aG9ycyB0byBnZXQgYmFjayB0byBtZSwgaGVyZSBpcyBteSB0YWtl IG9uIHRoaXMuDQoNCg0KDQpPbiBBcHIgMTYsIDIwMTgsIGF0IDg6MDggQU0sIDxtb2hhbWVkLmJv dWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPj4g PG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb20+PiB3cm90ZToNCg0KRGVhciBhdXRob3JzLA0KDQpXZSBkbyBoYXZlIGEgcXVlc3Rp b24gcmVnYXJkaW5nIHRoZSBpbnRlcnByZXRhdGlvbiBvZiDigJxwcm90b2NvbOKAnSB3aGVuIGFu IElQdjYgbWF0Y2ggZmlsdGVyIGlzIGFwcGxpZWQgYmVjYXVzZSB0aGUgZHJhZnQgaXMgbm90IGNs ZWFyLg0KDQpDYW4geW91IHBsZWFzZSBjbGFyaWZ5IHdoZXRoZXIg4oCccHJvdG9jb2zigJ0gY292 ZXJzIG9ubHkgdGhlIGJhc2UgSVB2NiBoZWFkZXIgb3IgaXQgaW5jbHVkZXMgYWxzbyDigJxuZXh0 IGhlYWRlcuKAnSBvZiBhbnkgZW5jbG9zZWQgRXh0ZW5zaW9uIEhlYWRlcj8NCg0KVGhlIGN1cnJl bnQgZHJhZnQgY292ZXJzIG9ubHkgdGhlIGJhc2UgSVB2NiBoZWFkZXIuIEl0IGRvZXMgbm90IGNv dmVyIEV4dGVuc2lvbiBIZWFkZXJzLg0KDQpJZiB0aGVyZSBpcyBzdWNoIGEgcmVxdWlyZW1lbnQs IHdlIHdpbGwgaGF2ZSB0byB0YWtlIGl0IHVwIGluIHRoZSBiaXMgdmVyc2lvbiBvZiB0aGlzIGRy YWZ0Lg0KDQoNCg0KDQpGb3IgZXhhbXBsZSwgZG9lcyB0aGUgZm9sbG93aW5nIEFDTCBhY2NlcHQg RE5TIHBhY2tldHMgKyBkcm9wIGZyYWdtZW50cyBlZmZpY2llbnRseT8gRG9lcyBpdCB3b3JrIGV2 ZW4gaWYgb3RoZXIgRUhzIGFyZSBwcmVjZWRpbmcgYSBGcmFnbWVudCBoZWFkZXIgPw0KDQp7DQog ICJpZXRmLWRvdHMtZGF0YS1jaGFubmVsOmFjbHMiOiB7DQogICAgImFjbCI6IFsNCiAgICAgIHsN CiAgICAgICAgIm5hbWUiOiAiZG5zLWZyYWdtZW50cyIsDQogICAgICAgICJ0eXBlIjogImlwdjYt YWNsLXR5cGUiLA0KICAgICAgICAiYWNlcyI6IHsNCiAgICAgICAgICAiYWNlIjogWw0KICAgICAg ICAgICAgew0KICAgICAgICAgICAgICAibmFtZSI6ICJkcm9wLWFsbC1mcmFnbWVudHMiLA0KICAg ICAgICAgICAgICAibWF0Y2hlcyI6IHsNCiAgICAgICAgICAgICAgICAiaXB2NiI6IHsNCiAgICAg ICAgICAgICAgICAgICJwcm90b2NvbCI6IDQ0DQogICAgICAgICAgICAgICAgfQ0KICAgICAgICAg ICAgICB9LA0KICAgICAgICAgICAgICAiYWN0aW9ucyI6IHsNCiAgICAgICAgICAgICAgICAiZm9y d2FyZGluZyI6ICJkcm9wIg0KICAgICAgICAgICAgICB9DQogICAgICAgICAgICB9DQogICAgICAg ICAgXQ0KICAgICAgICAgICJhY2UiOiBbDQogICAgICAgICAgICB7DQogICAgICAgICAgICAgICJu YW1lIjogImFsbG93LWRucy1wYWNrZXRzIiwNCiAgICAgICAgICAgICAgIm1hdGNoZXMiOiB7DQog ICAgICAgICAgICAgICAgImlwdjYiOiB7DQogICAgICAgICAgICAgICAgICAiZGVzdGluYXRpb24t aXB2Ni1uZXR3b3JrIjogIjIwMDE6ZGI4OjovMzIiDQogICAgICAgICAgICAgICAgfQ0KICAgICAg ICAgICAgICAgICJ1ZHAiOiB7DQogICAgICAgICAgICAgICAgICAiZGVzdGluYXRpb24tcG9ydCI6 IHsNCiAgICAgICAgICAgICAgICAgICAgIm9wZXJhdG9yIjogImVxIiwNCiAgICAgICAgICAgICAg ICAgICAgInBvcnQiOiA1Mw0KICAgICAgICAgICAgICAgICAgfQ0KICAgICAgICAgICAgICAgIH0N CiAgICAgICAgICAgICAgfSwNCiAgICAgICAgICAgICAgImFjdGlvbnMiOiB7DQogICAgICAgICAg ICAgICAgImZvcndhcmRpbmciOiAiYWNjZXB0Ig0KICAgICAgICAgICAgICB9DQogICAgICAgICAg ICB9DQogICAgICAgICAgXQ0KICAgICAgICB9DQogICAgICB9DQogICAgXQ0KICB9DQp9DQoNCkFn YWluLCBteSBwZXJzb25hbCB0YWtlIG9uIGl0IChhbmQgSSB3aWxsIHdhaXQgZm9yIG15IGNvLWF1 dGhvcnMgdG8gY29ycmVjdCBtZSBpZiBJIGFtIHdyb25nKSwgaXMgdGhhdCB0aGVzZSBhcmUgdHdv IHNlcGFyYXRlIGVudHJpZXMuIERlcGVuZGluZyBvbiB0aGUgb3JkZXIgb2YgdGhlIHJ1bGVzLCBh bmQgYWdhaW4gYXNzdW1pbmcgdGhlIHJ1bGVzIGFyZSBpbiB0aGUgb3JkZXIgc3RhdGVkIGFib3Zl LCBpZiB5b3UgZG8gcmVjZWl2ZSBhIGZyYWdtZW50ZWQgRE5TIHBhY2tldCwgdGhlIHNlY29uZCBy dWxlIHdpbGwgbmV2ZXIgYmUgaGl0LiBUaGUgZmlyc3QgcnVsZSB3b3VsZCBhcHBseSBhbmQgdGhl IHBhY2tldCB3aWxsIGJlIGRyb3BwZWQuIElmIHRoZSBydWxlcyBhcmUgcmV2ZXJzZWQsIHRoZW4g YWxsIEROUyBwYWNrZXRzIHRvIElQdjYgYWRkcmVzcyAyMDAxOmRiODo6LzMyIHdpbGwgYmUgYWNj ZXB0ZWQsIHdoZXRoZXIgdGhleSBhcmUgZnJhZ21lbnRlZCBvciBub3QuDQoNCkNoZWVycy4NCg0K DQoNCkNoZWVycywNCk1lZA0KDQpNYWhlc2ggSmV0aGFuYW5kYW5pDQptamV0aGFuYW5kYW5pQGdt YWlsLmNvbTxtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20+DQoNCk1haGVzaCBKZXRoYW5h bmRhbmkNCm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPG1haWx0bzptamV0aGFuYW5kYW5pQGdtYWls LmNvbT4NCg0K --_000_787AE7BB302AE849A7480A190F8B93302DF0F9ACOPEXCLILMA3corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiUHLDqWZvcm1hdMOpIEhUTUwgQ2FyIjsNCgltYXJnaW46 MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYu TXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRl eHRlIGRlIGJ1bGxlcyBDYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7 fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29u dmVydGVkLXNwYWNlO30NCnNwYW4uZ21haWwtbS00NjIzNjI3MTg5ODAwMjYwOTU5YXBwbGUtY29u dmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmdtYWlsLW0tNDYyMzYyNzE4OTgwMDI2MDk1 OWFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLm0tNDYyMzYyNzE4OTgwMDI2MDk1OWFwcGxl LWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTptLTQ2MjM2MjcxODk4MDAyNjA5NTlh cHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5ob2VuemINCgl7bXNvLXN0eWxlLW5hbWU6aG9l bnpiO30NCnNwYW4uVGV4dGVkZWJ1bGxlc0Nhcg0KCXttc28tc3R5bGUtbmFtZToiVGV4dGUgZGUg YnVsbGVzIENhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJU ZXh0ZSBkZSBidWxsZXMiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpz cGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrOw0KCWZvbnQtd2VpZ2h0Om5vcm1h bDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQpzcGFuLlByZm9ybWF0SFRNTENhcg0KCXttc28tc3R5 bGUtbmFtZToiUHLDqWZvcm1hdMOpIEhUTUwgQ2FyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IlByw6lmb3JtYXTDqSBIVE1MIjsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw dCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRlIiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+SGkgTWFoZXNoLA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPlRoYW5rIHlvdS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5JIHN1Z2dlc3QgdGhpcyBtb2RpZmllZCBORVcgdGV4dDoN CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgSW50 ZXJuZXQgUHJvdG9jb2wgbnVtYmVyLiBSZWZlcnMgdG8gdGhlIHByb3RvY29sIG9mIHRoZTwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHByZT48c3BhbiBs YW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7IHBheWxvYWQuIFRoYXQgaXMsIHRoZSBwcm90b2NvbCBs YXllciBpbW1lZGlhdGVseSBhYm92ZSBJUHY2ICh1cHBlciBsYXllcikuPG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOyZuYnNwOyBUaGlzIGlzIGluZGljYXRlZCBpbiB0aGUgJ25leHQgaGVhZGVyJyBvZiB0aGUg SVB2NiBoZWFkZXIgd2hlbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IG5vIGV4dGVuc2lvbiBoZWFk ZXJzIGFyZSBwcmVzZW50Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDtXaGVuIHByb2Nl c3NpbmcgYSBzZXF1ZW5jZSBvZiBOZXh0IEhlYWRlciB2YWx1ZXMgaW4gYSBwYWNrZXQsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7IHRo ZSBmaXJzdCBvbmUgdGhhdCBpcyBub3QgYW4gZXh0ZW5zaW9uIGhlYWRlciBpbmRpY2F0ZXMgdGhh dDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7 Jm5ic3A7IHRoZSBuZXh0IGl0ZW0gaW4gdGhlIHBhY2tldCBpcyB0aGUgY29ycmVzcG9uZGluZyB1 cHBlci1sYXllcjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1V UyI+Jm5ic3A7Jm5ic3A7IGhlYWRlci48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBsYW5nPSJFTi1VUyI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBsYW5nPSJFTi1VUyI+TWVkPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20g MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gTWFoZXNo IEpldGhhbmFuZGFuaSBbbWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tXQ0KPGJyPg0KPGI+ RW52b3nDqSZuYnNwOzo8L2I+IHZlbmRyZWRpIDIwIGF2cmlsIDIwMTggMjE6MTg8YnI+DQo8Yj7D gCZuYnNwOzo8L2I+IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE48YnI+DQo8Yj5DYyZuYnNwOzo8 L2I+IFNvbmFsIEFnYXJ3YWw7IGRyYWZ0LWlldGYtbmV0bW9kLWFjbC1tb2RlbEBpZXRmLm9yZzsg ZG90c0BpZXRmLm9yZzsgS2VudCBXYXRzZW48YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+IFJlOiBN YWlsIHJlZ2FyZGluZyBkcmFmdC1pZXRmLW5ldG1vZC1hY2wtbW9kZWw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NZWQsPG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZWUgY29tbWVudCBpbmxpbmUgd2l0aCBbbWpdPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gQXByIDE5LCAyMDE4 LCBhdCAxMDo0NiBQTSwgJmx0OzxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFu Z2UuY29tIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPiZndDsgJmx0OzxhIGhyZWY9 Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIj5tb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkhpIFNvbmFsLDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UaGFuayB5b3Ug Zm9yIHRoZSByZXBseS4gTXVjaCBhcHByZWNpYXRlZCE8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+UGxlYXNlIHNlZSBpbmxpbmUuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkNoZWVy cyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPk1lZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4w cHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1 QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGUmbmJzcDs6PC9zcGFu PjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+U29uYWwNCiBBZ2Fyd2FsIFs8YSBocmVmPSJtYWlsdG86c2FnYXJ3YWwxMkBnbWFpbC5jb20i PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1haWx0bzpzYWdhcndhbDEyQGdtYWlsLmNvbTwv c3Bhbj48L2E+XTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj48YnI+DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+dmVuZHJlZGkgMjAgYXZyaWwgMjAxOCAwMTozNTxicj4NCjxi PsOAJm5ic3A7OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+TWFoZXNoIEpldGhhbmFuZGFuaTxicj4NCjxiPkNjJm5ic3A7OjwvYj48c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Qk9VQ0FEQUlSIE1vaGFtZWQg SU1UL09MTjs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtbmV0bW9kLWFjbC1tb2RlbEBpZXRmLm9yZyI+PHNw YW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ZHJhZnQtaWV0Zi1uZXRtb2QtYWNsLW1vZGVsQGlldGYu b3JnPC9zcGFuPjwvYT47PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpkb3RzQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6 cHVycGxlIj5kb3RzQGlldGYub3JnPC9zcGFuPjwvYT47DQogS2VudCBXYXRzZW48YnI+DQo8Yj5P YmpldCZuYnNwOzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPlJlOiBNYWlsIHJlZ2FyZGluZyBkcmFmdC1pZXRmLW5ldG1vZC1hY2wtbW9kZWw8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgTWVkLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVwbGll cyBpbmxpbmU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5DYW4geW91IHBs ZWFzZSBjbGFyaWZ5IHdoZXRoZXIg4oCccHJvdG9jb2zigJ0gY292ZXJzIG9ubHkgdGhlIGJhc2Ug SVB2NiBoZWFkZXIgb3IgaXQgaW5jbHVkZXMgYWxzbyDigJxuZXh0IGhlYWRlcuKAnSBvZiBhbnkg ZW5jbG9zZWQgRXh0ZW5zaW9uIEhlYWRlcj88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQ7Zm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsO2ZvbnQtdmFyaWFu dC1jYXBzOiBub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzIyMjIyMiI+VGhlIHByb3RvY29sIGNvdmVycyB0aGUgZW50aXJlIElQdjYgcGFja2V0LCB3aGlj aCBpbmNsdWRlcyB0aGUgZXh0ZW5zaW9uIGhlYWRlcihzKS4gVGhlIEVIJ3MgZG8gbm90IGluZGl2 aWR1YWxseSBjb250YWluDQogdGhlIHByb3RvY29sIGluZm9ybWF0aW9uLjxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDozNi4wcHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ W01lZF0gQWN0dWFsbHksIOKAnHByb3RvY29s4oCdIGlzIGRlZmluZWQgaW4gdGhlIG5ldG1vZC1h Y2wgYXMgZm9sbG93czo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbi1yaWdodDozNi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsgbGVhZiBwcm90b2NvbCB7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdHlwZSB1aW50ODs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBk ZXNjcmlwdGlvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O0ludGVybmV0IFByb3RvY29sIG51bWJlci4gUmVm ZXJzIHRvIHRoZSBwcm90b2NvbCBvZiB0aGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBwYXlsb2FkLiBJbiBJ UHY2LCB0aGlzIGZpZWxkIGlzIGtub3duIGFzICduZXh0LWhlYWRlci4mcXVvdDs7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6MzYuMHB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luLXJpZ2h0OjM2LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UaGlzIHRleHQgaXMgcmVh bGx5IG5vdCBjbGVhciB3aGF0IGl0IGNvdmVycy4gVGhpcyBpcyBjb25mdXNpbmcgZ2l2ZW4gdGhh dCDigJxuZXh0IGhlYWRlcuKAnSBpcyBwcmVzZW50IGluIHRoZSBiYXNlIGhlYWRlciBhbmQgYWxz byBpbiBFSHMuPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu Pjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0 OjM2LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDozNi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SW4gb3Jk ZXIgdG8gYXZvaWQgY29uZnVzaW9uLCBwbGVhc2UgY29uc2lkZXIgYWRkaW5nIG9uZSBzZW50ZW5j ZSB0byB0d28gdG8gY2xhcmlmeSB0aGUgaW50ZW50Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OjM2LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+V2hlbiBFSCdzIGFyZSBwcmVzZW50LCB0aGVuIHRo ZSBwcm90b2NvbCB3aWxsIGJlIGluIHRoZSAmcXVvdDtVcHBlciBsYXllciBoZWFkZXLigJ0uPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+W21qXSBNZWQsIGhvdyBhYm91dCB0aGlzPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PTEQ6PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JbnRlcm5ldCBQcm90 b2NvbCBudW1iZXIuIFJlZmVycyB0byB0aGUgcHJvdG9jb2wgb2YgdGhlPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPnBh eWxvYWQuIEluIElQdjYsIHRoaXMgZmllbGQgaXMga25vd24gYXMgJ25leHQtaGVhZGVyLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ TkVXOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPkludGVybmV0IFByb3RvY29sIG51bWJlci4gUmVmZXJzIHRvIHRo ZSBwcm90b2NvbCBvZiB0aGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+cGF5bG9hZC4gSW4gSVB2NiwgdGhpcyBmaWVs ZCBpcyBrbm93biBhcyAnbmV4dC1oZWFkZXInLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5hbmQgaWYgZXh0ZW5zaW9u IGhlYWRlcnMgYXJlIHByZXNlbnQsIHRoZSBwcm90b2NvbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5pcyBwcmVzZW50 IGluIHRoZSAndXBwZXItbGF5ZXInIGhlYWRlci48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMjIyMjIyO2JhY2tncm91bmQ6d2hpdGUiPkZvciBl eGFtcGxlLCBkb2VzIHRoZSBmb2xsb3dpbmcgQUNMIGFjY2VwdCBETlMgcGFja2V0cyAmIzQzOyBk cm9wIGZyYWdtZW50cyBlZmZpY2llbnRseT88L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzIyMjIyMjti YWNrZ3JvdW5kOndoaXRlIj5Eb2VzDQogaXQgd29yayBldmVuIGlmIG90aGVyIEVIcyBhcmUgcHJl Y2VkaW5nIGEgRnJhZ21lbnQgaGVhZGVyID88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOyAmbmJzcDsgJm5ic3A7SSBoYXZl IG5vdCBzZWVuIGFuIEFDTCB0aGF0IGlzIHVzZWQgdG8gZmlsdGVyIEROUyBwYWNrZXRzLCBidXQg SSBwcmVzdW1lIGl0IHdvdWxkIGhhdmUgdGhlIHByb3RvY29sIHRvIGJlIHRjcC91ZHAgYW5kIHRo ZSBMNCBwb3J0IHRvIGJlIDUzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 O2ZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFs O3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOiM1MDAwNTAiPiZxdW90O2FjZSZxdW90OzogWzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6IzUwMDA1MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM1MDAwNTAiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmcXVvdDtuYW1lJnF1b3Q7OiAmcXVvdDtkcm9wLWFsbC1mcmFnbWVudHMmcXVv dDssPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjojNTAwMDUwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7bWF0 Y2hlcyZxdW90Ozogezwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzUwMDA1MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZxdW90O2lwdjYmcXVvdDs6IHs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM1MDAwNTAiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtwcm90b2Nv bCZxdW90OzogNDQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM1MDAwNTAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB9PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojNTAwMDUwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg fSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOiM1MDAwNTAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDthY3Rp b25zJnF1b3Q7OiB7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojNTAwMDUwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJnF1b3Q7Zm9yd2FyZGluZyZxdW90OzogJnF1b3Q7ZHJvcCZxdW90Ozwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6IzUwMDA1MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM1 MDAwNTAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB9PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojNTAwMDUwIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgXTwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzUwMDA1MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM1MDAwNTAi PlRoaXMgQUNFIGlzIHNheWluZyBtYXRjaCBwcm90b2NvbCA0NCBpbiB1cHBlciBoZWFkZXIgYW5k IGRyb3AgdGhlIHBhY2tldC4gSXQgd2lsbCBvbmx5IHdvcmsgZm9yIHBhY2tldHMgdGhhdCBoYXZl IDQ0IHNldA0KIGFzIHRoZSBwcm90b2NvbC4gRm9yIGhhcmR3YXJlIHRvIHRydWx5IGRyb3AgYWxs IGZyYWdtZW50ZWQgcGFja2V0cywgdGhlIGNvcnJlY3QgbWF0Y2ggd291bGQgYmUgc29tZXRoaW5n IGxpa2UgJnF1b3Q7ZGVueSBhbnkgYW55IGZyYWcmcXVvdDsuIFRoaXMgaW5kaWNhdGVzIHRvIGRh dGFwbGFuZSB0byBmaWd1cmUgb3V0IGlmIGEgcGFja2V0IGlzIGEgZnJhZ21lbnQsIGFuZCB0aGVu IGRyb3AgaXQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNTAwMDUwIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQ7Zm9udC12YXJpYW50LWxpZ2F0dXJlczog bm9ybWFsO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNw YWNpbmc6MHB4Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OiM1MDAwNTAiPiZxdW90O2FjZSZxdW90OzogWzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzUwMDA1MCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOiM1MDAwNTAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtu YW1lJnF1b3Q7OiAmcXVvdDthbGxvdy1kbnMtcGFja2V0cyZxdW90Oyw8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM1 MDAwNTAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDttYXRjaGVzJnF1b3Q7OiB7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjojNTAwMDUwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7 aXB2NiZxdW90Ozogezwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzUwMDA1MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O2Rlc3RpbmF0aW9uLWlwdjYtbmV0d29yayZx dW90OzogJnF1b3Q7MjAwMTpkYjg6Oi8zMiZxdW90Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzUwMDA1MCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImdtYWlsLW0tNDYyMzYy NzE4OTgwMDI2MDk1OWFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjojNTAwMDUwIj59PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM1MDAwNTAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmcXVvdDt1ZHAmcXVvdDs6IHs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzUwMDA1MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O2Rlc3RpbmF0aW9uLXBvcnQmcXVvdDs6 IHs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6IzUwMDA1MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZxdW90O29wZXJhdG9yJnF1b3Q7OiAmcXVvdDtlcSZxdW90Oyw8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzUwMDA1 MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZxdW90O3BvcnQmcXVvdDs6IDUzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM1MDAwNTAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1tLTQ2MjM2MjcxODk4MDAy NjA5NTlhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOiM1MDAwNTAiPn08L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM1MDAwNTAiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojNTAwMDUwIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgfSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM1MDAwNTAiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmcXVvdDthY3Rpb25zJnF1b3Q7OiB7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojNTAwMDUwIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7Zm9yd2FyZGluZyZxdW90OzogJnF1 b3Q7YWNjZXB0JnF1b3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojNTAwMDUwIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6IzUwMDA1MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM1MDAw NTAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBdPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjojNTAwMDUwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgfTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzUwMDA1MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IH08L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM1MDAwNTAiPiZuYnNwOyZuYnNwOyZuYnNwOyBdPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojNTAwMDUwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzUwMDA1MCI+SSBwcmVzdW1lIHlvdSB3YW50IHRoZSBwcm90b2NvbCBoZXJlIHRvIGJl IGlwdjYuIFRoaXMgQUNFIGluZGljYXRlcyB0byBtYXRjaCBwYWNrZXRzIHdpdGggcHJvdG9jb2wg aXB2NiBhbmQgbWF0Y2ggb24gZGVzdGluYXRpb24tcG9ydA0KIDUzLiBJbiBvcmRlciB0byBkbyB0 aGlzLCBkYXRhcGxhbmUgbmVlZHMgdG8gZXh0cmFjdCBMNCBpbmZvcm1hdGlvbiBmcm9tIHRoZSBw YXlsb2FkLiBJZiB0aGUgcGFja2V0IG1hdGNoZXMgZGVzdGluYXRpb24gcG9ydCBvZiA1MywgdGhl biBhY2NlcHQgdGhlIHBhY2tldHMuIERhdGFwbGFuZSBzaG91bGQgYmUgY2FwYWJsZSBvZiBleHRy YWN0aW5nIEw0IGZyb20gdGhlIHBheWxvYWQsIHJlZ2FyZGxlc3Mgb2YgdGhlIG51bWJlciBvZiBl eHRlbnNpb24NCiBoZWFkZXJzIHByZXNlbnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiM1MDAwNTAi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNTAwMDUwIj5UaGFua3MsPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM1MDAwNTAiPlNvbmFsLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzUwMDA1MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2NvbG9yOiM1MDAwNTAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEFwciAxOSwgMjAxOCBh dCAxMjoxNyBQTSwgTWFoZXNoIEpldGhhbmFuZGFuaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1qZXRo YW5hbmRhbmlAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1 cnBsZSI+bWpldGhhbmFuZGFuaUBnbWFpbC5jb208L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TW9o YW1lZCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoaWxlIEkgd2FpdCBmb3IgbXkgY28tYXV0aG9ycyB0 byBnZXQgYmFjayB0byBtZSwgaGVyZSBpcyBteSB0YWtlIG9uIHRoaXMuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0K PGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T24gQXByIDE2LCAyMDE4LCBhdCA4OjA4IEFNLCAmbHQ7PGEgaHJlZj0ibWFpbHRv Om1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHls ZT0iY29sb3I6cHVycGxlIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9zcGFuPjwvYT4m Z3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1vaGFtZWQuYm91Y2FkYWly QG9yYW5nZS5jb208L3NwYW4+PC9hPiZndDsNCiB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkRlYXIgYXV0aG9ycywmbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+V2UgZG8gaGF2ZSBhIHF1ZXN0aW9uIHJlZ2FyZGluZyB0aGUg aW50ZXJwcmV0YXRpb24gb2Yg4oCccHJvdG9jb2zigJ0gd2hlbiBhbiBJUHY2IG1hdGNoIGZpbHRl ciBpcyBhcHBsaWVkIGJlY2F1c2UgdGhlIGRyYWZ0IGlzIG5vdCBjbGVhci48L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Q2FuIHlvdSBwbGVhc2UgY2xhcmlmeSB3aGV0aGVyIOKAnHByb3Rv Y29s4oCdIGNvdmVycyBvbmx5IHRoZSBiYXNlIElQdjYgaGVhZGVyIG9yIGl0IGluY2x1ZGVzIGFs c28g4oCcbmV4dCBoZWFkZXLigJ0gb2YgYW55IGVuY2xvc2VkIEV4dGVuc2lvbiBIZWFkZXI/PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgY3VycmVudCBkcmFm dCBjb3ZlcnMgb25seSB0aGUgYmFzZSBJUHY2IGhlYWRlci4gSXQgZG9lcyBub3QgY292ZXIgRXh0 ZW5zaW9uIEhlYWRlcnMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHRoZXJl IGlzIHN1Y2ggYSByZXF1aXJlbWVudCwgd2Ugd2lsbCBoYXZlIHRvIHRha2UgaXQgdXAgaW4gdGhl IGJpcyB2ZXJzaW9uIG9mIHRoaXMgZHJhZnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4N Cjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkZvciBleGFtcGxlLCBk b2VzIHRoZSBmb2xsb3dpbmcgQUNMIGFjY2VwdCBETlMgcGFja2V0cyAmIzQzOyBkcm9wIGZyYWdt ZW50cyBlZmZpY2llbnRseT8gRG9lcyBpdCB3b3JrIGV2ZW4gaWYgb3RoZXIgRUhzIGFyZSBwcmVj ZWRpbmcgYSBGcmFnbWVudCBoZWFkZXIgPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij57 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgJnF1b3Q7aWV0 Zi1kb3RzLWRhdGEtY2hhbm5lbDphY2xzJnF1b3Q7OiB7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7YWNsJnF1b3Q7OiBbPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgezwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O25hbWUmcXVvdDs6 ICZxdW90O2Rucy1mcmFnbWVudHMmcXVvdDssPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1 b3Q7dHlwZSZxdW90OzogJnF1b3Q7aXB2Ni1hY2wtdHlwZSZxdW90Oyw8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmcXVvdDthY2VzJnF1b3Q7OiB7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJnF1b3Q7YWNlJnF1b3Q7OiBbPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgezwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O25hbWUmcXVvdDs6ICZxdW90O2Ry b3AtYWxsLWZyYWdtZW50cyZxdW90Oyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDttYXRjaGVzJnF1b3Q7OiB7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJnF1b3Q7aXB2NiZxdW90Ozogezwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZxdW90O3Byb3RvY29sJnF1b3Q7OiA0NDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9LDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZxdW90O2FjdGlvbnMmcXVvdDs6IHs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtmb3J3YXJk aW5nJnF1b3Q7OiAmcXVvdDtkcm9wJnF1b3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBdPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7 YWNlJnF1b3Q7OiBbPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgezwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZxdW90O25hbWUmcXVvdDs6ICZxdW90O2FsbG93LWRucy1wYWNrZXRzJnF1 b3Q7LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZxdW90O21hdGNoZXMmcXVvdDs6IHs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtp cHY2JnF1b3Q7OiB7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7ZGVzdGluYXRp b24taXB2Ni1uZXR3b3JrJnF1b3Q7OiAmcXVvdDsyMDAxOmRiODo6LzMyJnF1b3Q7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDs8c3BhbiBjbGFzcz0ibS00NjIzNjI3MTg5ODAwMjYwOTU5YXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij59PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDt1ZHAmcXVv dDs6IHs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O2Rlc3RpbmF0aW9uLXBvcnQmcXVvdDs6IHs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O29wZXJhdG9yJnF1b3Q7OiAmcXVvdDtlcSZx dW90Oyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O3BvcnQmcXVvdDs6IDUzPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJtLTQ2MjM2MjcxODk4MDAyNjA5NTlhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij59 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgfTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH0sPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7YWN0aW9ucyZxdW90Ozogezwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZxdW90O2ZvcndhcmRpbmcmcXVvdDs6ICZxdW90O2FjY2VwdCZxdW90 Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IH08L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB9PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgXTwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IH08L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsgXTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7IH08L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPn08L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5BZ2FpbiwgbXkgcGVyc29uYWwgdGFrZSBvbiBpdCAoYW5kIEkgd2lsbCB3 YWl0IGZvciBteSBjby1hdXRob3JzIHRvIGNvcnJlY3QgbWUgaWYgSSBhbSB3cm9uZyksIGlzIHRo YXQgdGhlc2UgYXJlIHR3byBzZXBhcmF0ZSBlbnRyaWVzLiBEZXBlbmRpbmcgb24gdGhlIG9yZGVy IG9mIHRoZSBydWxlcywgYW5kIGFnYWluIGFzc3VtaW5nIHRoZSBydWxlcyBhcmUgaW4gdGhlIG9y ZGVyIHN0YXRlZCBhYm92ZSwgaWYgeW91DQogZG8gcmVjZWl2ZSBhIGZyYWdtZW50ZWQgRE5TIHBh Y2tldCwgdGhlIHNlY29uZCBydWxlIHdpbGwgbmV2ZXIgYmUgaGl0LiBUaGUgZmlyc3QgcnVsZSB3 b3VsZCBhcHBseSBhbmQgdGhlIHBhY2tldCB3aWxsIGJlIGRyb3BwZWQuIElmIHRoZSBydWxlcyBh cmUgcmV2ZXJzZWQsIHRoZW4gYWxsIEROUyBwYWNrZXRzIHRvIElQdjYgYWRkcmVzcyZuYnNwOzxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4yMDAxOmRiODo6LzMyPC9zcGFuPiZuYnNwO3dpbGwNCiBiZSBhY2NlcHRlZCwgd2hl dGhlciB0aGV5IGFyZSBmcmFnbWVudGVkIG9yIG5vdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Q2hlZXJzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPkNoZWVycyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPk1lZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g Y2xhc3M9ImhvZW56YiI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPiZuYnNwOzwvc3Bhbj48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij5NYWhlc2ggSmV0aGFu YW5kYW5pPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxhIGhy ZWY9Im1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFu IHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPC9zcGFuPjwvYT48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWFoZXNoIEpldGhhbmFuZGFuaTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0ibWFpbHRv Om1qZXRoYW5hbmRhbmlAZ21haWwuY29tIj5tamV0aGFuYW5kYW5pQGdtYWlsLmNvbTwvYT48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_787AE7BB302AE849A7480A190F8B93302DF0F9ACOPEXCLILMA3corp_-- From nobody Mon Apr 23 13:04:51 2018 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 DC04512D948 for ; Mon, 23 Apr 2018 13:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 LaqqXo48LrZh for ; Mon, 23 Apr 2018 13:04:47 -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 A7F01126B6E for ; Mon, 23 Apr 2018 13:04:47 -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 w3NK4kk4003127 for ; Mon, 23 Apr 2018 16:04:46 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu w3NK4kk4003127 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1524513886; bh=cZqYjBkWmZxUAqaggcsFlzy4bitnvmJHEhKs+xeeIbs=; h=From:To:Subject:Date:From; b=VDTli21K22dQX5fwcPtrLF3V0LeGaTktmt9XaZCO6QQMejlN6hNtji69DbMIyzJYu lQ3TMtM8Ky5Xc1FVHwxnvMGRT/w44PPTVSrDtEzYMWuB8bu5vaCQLjQn1Or5KECiXu iXgrIZ5IZb5PvEc02YD0TGTOoG7qXlfMw9cGIX8s= 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 w3NK4err024617 for ; Mon, 23 Apr 2018 16:04:40 -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; Mon, 23 Apr 2018 16:04:40 -0400 From: Roman Danyliw To: "dots@ietf.org" Thread-Topic: Draft minutes from IETF 101 meeting Thread-Index: AdPbPis0P1E+DQv5R5KjdzT9BlBCpg== Date: Mon, 23 Apr 2018 20:04:39 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC014C38C58C@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] Draft minutes from IETF 101 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: Mon, 23 Apr 2018 20:04:50 -0000 Hello! Draft minutes from the IETF 101 meeting can be found at: https://datatracker.ietf.org/meeting/101/materials/minutes-101-dots-00 Special thanks to our note taker, Liang Xia, who took them. Please send any corrections or updates to the chairs. Regards, Roman From nobody Mon Apr 23 23:48:54 2018 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 15A321270AB for ; Mon, 23 Apr 2018 23:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 17QYdwQ1swUB for ; Mon, 23 Apr 2018 23:48:50 -0700 (PDT) Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C27B12420B for ; Mon, 23 Apr 2018 23:48:49 -0700 (PDT) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id B9E31100E26; Tue, 24 Apr 2018 08:48:47 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.63]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 8ADF3C0060; Tue, 24 Apr 2018 08:48:47 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6E.corporate.adroot.infra.ftgroup ([fe80::f5a7:eab1:c095:d9ec%18]) with mapi id 14.03.0389.001; Tue, 24 Apr 2018 08:48:47 +0200 From: To: Jon Shallow , "Konda, Tirumaleswar Reddy" , "dots@ietf.org" Thread-Topic: [Dots] Data Channel ACL fragments Thread-Index: AQEYhrWXRSNBek+fWBybzdJS41Z0KAI4GsKdAX18SvQDE9KikwNzyn9FAeCfBHcAmG/gMgGrGCDSAZ2/A+cCF5qWXQGy5AXbAg+JyVkByAAwbQHvg6xBAdFnBMIB5XW0gQC6rlcwA1dFhlkCJgU3iQMvoFDAAcXEWBcCAjRLagJU5IDlpBOsveCADBXfIA== Date: Tue, 24 Apr 2018 06:48:46 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DF10737@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <016401d3cc1c$03321200$09963600$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7F97@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <01a701d3cc29$ba915b10$2fb41130$@jpshallow.com> <007501d3ccc2$b49f0b00$1ddd2100$@jpshallow.com> <021301d3cfe7$77e5cbe0$67b163a0$@jpshallow.com> <02b001d3d048$a2c68be0$e853a3a0$@jpshallow.com> <000001d3d0ab$547dec40$fd79c4c0$@jpshallow.com> <007701d3d0bb$2404c330$6c0e4990$@jpshallow.com> <00a801d3d0c8$67315800$35940800$@jpshallow.com> <00e901d3d30f$687eb1a0$397c14e0$@jpshallow.com> <013201d3d323$141409d0$3c3c1d70$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DF0B47F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <002101d3d57b$920ebf10$b62c3d30$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DF0B4F1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <006001d3d591$a8d2ae30$fa780a90$@jpshallow.com> In-Reply-To: <006001d3d591$a8d2ae30$fa780a90$@jpshallow.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93302DF10737OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Data Channel ACL fragments 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, 24 Apr 2018 06:48:53 -0000 --_000_787AE7BB302AE849A7480A190F8B93302DF10737OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, Given the clarification provided by the authors of the netmod-acl I-D, the = current design for handling IPv6 fragments in the DOTS data channel specifi= cation is the appropriate way to proceed. I consider this issue as closed. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : lundi 16 avril 2018 16:46 =C0 : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; dots@ietf.org Objet : RE: [Dots] Data Channel ACL fragments Hi Med, I think that this comes down to external integration. Whilst out of scope,= the data model communication method for transferring the ACL/ACEs between = a DOTS Server and a DOTS Mitigator cannot be using standard netmod-acl as t= here is no way to define how to handle fragmentation usage in it (following= your reasoning/interpretation of netmod-acl) unless there is a separate au= gmentation in that data model to include fragments definitions. Perhaps the right answer is to get the text in netmod-acl tightened up for = clarity between protocol and next-header (along with what is flags-> fragme= nt really meant to do for an ACL in grouping acl-ipv4-header-fields). Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 16 April 2018 13:23 To: Jon Shallow; Konda, Tirumaleswar Reddy; dots@ietf.org Subject: Re: [Dots] Data Channel ACL fragments Jon, I'm afraid the current netmod-acl does not allow to appropriately handle IP= v6 fragments (and more filtering based on Extension Header Types in general= ). At least, the text is not clear whether "protocol" applies for the next-= header of the base header or the one of any enclosed EH. The use of v6-fragment keyword (in the data-channel draft) solves this by p= erforming a check whether a Fragment header is present. "ace": [ { "name": "drop-all-fragments", "matches": { "ipv6": { "v6-fragment" } }, "actions": { "forwarding": "drop" } } ] This check is exactly what Cisco and Juniper are doing in the excerpts you = provided. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : lundi 16 avril 2018 14:08 =C0 : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; dots@ietf.org Objet : RE: [Dots] Data Channel ACL fragments Hi Med, Currently we disagree over IPv6 and fragmentation. As per https://www.cisco.com/en/US/technologies/tk648/tk872/technologies_wh= ite_paper0900aecd8054d37d.html , ACL filtering does work on "fragments". Filtering Based on Extension Header Type Routers can be explicitly instructed to look at and act on traffic that con= tains certain extension header types. This functionality is available on Ci= sco platforms and can be configured with the help of IPv6 Access List optio= ns: deny protocol {source-ipv6-prefix/prefix-length | any | host source-ipv6-ad= dress} [operator [port-number]] {destination-ipv6-prefix/prefix-length | an= y | host destination-ipv6-address} [operator [port-number]] [dest-option-ty= pe [doh-number | doh-type]] [dscp value] [flow-label value] [fragments] [lo= g] [log-input] [mobility] [mobility-type [mh-number | mh-type]] [routing] [= routing-type routing-number] [sequence value] [time-range name] [undetermin= ed-transport] Example 1: Access List Filtering based on Extension Header Type ipv6 access-list EH-type deny ipv6 any 2001:2B8:1:1::/64 routing In order to permit or deny certain types of extension headers, routers are = configured with the ACL features listed above to filter based on the "Heade= r Type" value (see Table 1). Note that in this case, the content of the EH is not processed and the rout= er simply makes a decision based on the presence of a certain EH type. Soft= ware platforms can also analyze and filter based on additional EH fields su= ch as the "Type Field". These filtering capabilities are very useful in imp= lementing, for instance, security policies such as blocking source routing. ... Since this functionality is implemented through ACLs, platforms that suppor= t hardware forwarding when ACLs are applied, will be able to handle the IPv= 6 traffic with EHs in hardware as well (Figure 7). Juniper appears to support this on the MX router (see https://www.juniper.n= et/documentation/en_US/junos/topics/reference/general/firewall-filter-match= -conditions-for-ipv6-traffic.html) extension-headers header-type Match an extension header type that is contained in the packet by identifyi= ng a Next Header value. Note: This match condition is only supported on MPCs in MX Series routers. In the first fragment of a packet, the filter searches for a match in any o= f the extension header types. When a packet with a fragment header is found= (a subsequent fragment), the filter only searches for a match of the next = extension header type because the location of other extension headers is un= predictable. In place of the numeric value, you can specify one of the following text sy= nonyms (the field values are also listed): ah (51), destination (60), esp (= 50), fragment (44), hop-by-hop (0), mobility (135), or routing (43). To match any value for the extension header option, use the text synonym an= y. For MX Series routers with MPCs, initialize new firewall filters that inclu= de this condition by walking the corresponding SNMP MIB. So, no matter where the fragment header is (even with subsequent extended h= eaders (to me the Authenticating Header, or ESP header is the actual protoc= ol)) before the actual protocol, matching on protocol 44 works and is map-a= ble to Cisco/Juniper ALCs where they do not need to use the control plane -= or am I missing something here? Regards Jon From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of ietf-sup= jps-mohamed.boucadair@orange.com Sent: 16 April 2018 12:11 To: Konda, Tirumaleswar Reddy; Jon Shallow; dots@ietf.org Subject: Re: [Dots] Data Channel ACL fragments Hi all, I do agree with the conclusion of this thread for IPv4 but not for IPv6. For example, a DOTS client may send this POST request to filter fragmented = packets (including atomic ones): { "ietf-dots-data-channel:acls": { "acl": [ { "name": "dns-fragments", "type": "ipv6-acl-type", "aces": { "ace": [ { "name": "drop-all-fragments", "matches": { "ipv6": { "protocol": 44 } }, "actions": { "forwarding": "drop" } } ] "ace": [ { "name": "allow-dns-packets", "matches": { "ipv6": { "destination-ipv6-network": "2001:db8::/32" } "udp": { "destination-port": { "operator": "eq", "port": 53 } } }, "actions": { "forwarding": "accept" } } ] } } ] } } But these ACEs are efficient only if the next-header of the IPv6 header poi= nts to 44. If the IPv6 packet includes other EHs and the Fragment header is= not the one which is immediately preceding the base header, then fragmente= d packets won't match the "drop-all-fragments" ACE. Cheers, Med De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] Envoy=E9 : samedi 14 avril 2018 06:48 =C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: [Dots] Data Channel ACL fragments Sure, Appendix looks like the right place to add the filtering rule example= s for both IPv4 and IPv6. -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Friday, April 13, 2018 6:00 PM To: Konda, Tirumaleswar Reddy >; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] Data Channel ACL fragments Hi Tiru, Thanks. I think that we do need an example in the draft of how to do this though...= . IPv6 will not be using flags, but looking instead for the next header of pr= otocol 44. Regards Jon From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of Konda, T= irumaleswar Reddy Sent: 13 April 2018 13:25 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] Data Channel ACL fragments [Jon6] - Yes - I stand corrected, your ordering is correct. A2 no longer n= eeds destination-port. Yup. The summary of our discussion is to use the flags defined in netmod-ac= l-model to drop fragments (both initial and non-initial), and v4-fragments = and v6-fragments and the associated text added to drop non-initial fragment= s discussed in Section 4.1 will be removed from the draft. Cheers -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Friday, April 13, 2018 3:39 PM To: Konda, Tirumaleswar Reddy >; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] Data Channel ACL fragments Hi Tiru, See inline [Jon6] Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 13 April 2018 10:03 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] Data Channel ACL fragments Hi Jon, Please see inline [TR4] From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Konda@mcafee.com= ] Sent: 10 April 2018 07:10 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] Data Channel ACL fragments [Jon2] The "flags->fragment" definition is ambiguous for an ACE (but valid = as to whether to allow a packet to get fragmented or not - is that really a= ACE?) which I would like to use. [TR] I don't get it. What purpose does it serve to create a ACE rule using = "fragment" bit ? [Jon3] Agreed - This definition has not been thought through for an ACE. I= think they have just emulated the DF bit in RFC791 as this general flags d= efinition is the same as for the flags in RFC791. [TR2] You may want to inform the authors of netmod-acl draft, surprisingly = BGP flowspec also uses "fragment" bit. [Jon4] On my ToDo list for a clean solution. But we do now have a solution= - see below. "Flags->more" definition covers all fragments but the last fragment... "Off= set" is unfortunately not a range, but otherwise would get used for the fin= al fragment. ~jon2 [TR] It looks like two ACE entries are required to drop all the fragments (= "flags->more" set to 1 in the first ACE and "flags->more" set to 0 in the s= econd ACE). How to use the "Offset" field for the final fragment ? [Jon3] I read "flags-more" to refer to the IP_MF in the IP header (RFC791 M= F or more-fragments flag). This is set for all fragments apart from the fi= nal (as in last part of packet, not the order in which they are sent - fort= unately that early decision to send them in the wrong order was phased out,= but still there in some legacy systems!) [TR2] Yes, why can't "flags->more" be set to 0 as one ACE entry to drop the= final fragment along with "flags->more" set to 1 to drop the first fragmen= t as another ACE entry so as to drop all fragments to the target ? [Jon4] If "flags->more" is configured and it is configured with a value of = 0, this will match not only the final fragment, but also a non-fragmented p= acket. If "flags->more" is not configured, then this will match a non-frag= mented packet only. [TR3] net-mod-acl says "Setting the value to 0 indicates this is the last f= ragment, and setting the value to 1 indicates more fragments are coming.". = I think it means, if "flags->more" is set to zero and offset is not zero th= en it indicates this is the last fragments; the flags can be used in isolat= ion without comparing if offset value is zero or non-zero. We should check = with netmod-acl authors for confirmation. [Jon5]. The netmod-acl text for flags and offset is effectively a word for= word copy out of RFC791 3.1 Internet Header Format. So I think it is mean= t to be interpreted as being an exact match for the same - including the of= fset specific value. Flags: 3 bits Various Control Flags. Bit 0: reserved, must be zero Bit 1: (DF) 0 =3D May Fragment, 1 =3D Don't Fragment. Bit 2: (MF) 0 =3D Last Fragment, 1 =3D More Fragments. 0 1 2 +---+---+---+ | | D | M | | 0 | F | F | +---+---+---+ Fragment Offset: 13 bits This field indicates where in the datagram this fragment belongs. The fragment offset is measured in units of 8 octets (64 bits). The first fragment has offset zero. ---- Versus ---- leaf flags { type bits { bit reserved { position 0; description "Reserved. Must be zero."; } bit fragment { position 1; description "Setting value to 0 indicates may fragment, while setting the value to 1 indicates do not fragment."; } bit more { position 2; description "Setting the value to 0 indicates this is the last fragment, and setting the value to 1 indicates more fragments are coming."; } } description "Bit definitions for the flags field in IPv4 header."; } leaf offset { type uint16 { range "20..65535"; } description "The fragment offset is measured in units of 8 octets (64 bits). The first fragment has offset zero. The length is 13 bits"; } [Jon4] So, a L4 ACE without "flags->more" defined and "allow", followed by = an ACE with "flags->more" =3D 1 and "drop", followed by an ACE with "flags-= >more" =3D 0 and "drop" will cause all fragmented packets to get dropped, b= ut still allow through the non-fragmented packet. So, we have a solution f= or "allow all traffic to port 53, but drop all fragmented packets". [TR3] I don't think the above solution will work. In the above line, I thin= k you meant L3 ACE, and the first fragment will match the first entry and = is allowed. [Jon5]No, the first ACE is a L3/L4 match. If you have (a1 allows through a= ll non-fragmented packets, a2 & a3 drops all fragmented packets) the follow= ing [TR4] The first fragment will have both L3 and L4 information, and matches = a1 and is allowed, but if the order is changed to a3, a1 and a2 (a3 will dr= op all fragments except last-fragment, the last fragment will not have L4 i= nfo, so will not match a1 but will match a2 and get dropped). [Jon6] - Yes - I stand corrected, your ordering is correct. A2 no longer n= eeds destination-port. ~jon6 -Tiru ... { "aces": [{ "ace": { "name": "a1", "matches": [{ "ipv4": = { = "destination-network": "1.2.3.0/24" }, "udp": { = "destination-port": 53 } }], "actions": { "forward= ing": "accept" } } }, { "ace": { "name": "a2", "matches": [{ "ipv4": = { = "flags": { = "destination-network": "1.2.3.0/24", = "more": 0 = }, = "udp": { = "destination-port": 53 = } } }], "actions": { "forward= ing": "drop" } } }, { "ace": { "name": "a3", "matches": [{ "ipv4": = { = "flags": { = "more": 1 = } } }], "actions": { "forward= ing": "drop" } } } ] } ... [Jon5] It will work -Tiru ~jon4 -Tiru [Jon3] But as the final fragment of the sequence could have any offset, the= use of the offset field is not that helpful here. Even if we do go with o= ur DOTS fragments definition (but widened to cover all fragments), we still= cannot generate a netmod-acl entry for onward processing by an upstream mi= tigator. [Jon3] FYI, for Juniper, you just need to set 'first-fragment' and 'is-frag= ment' in their ACL. BGP FlowSpec does support fragmentation detection prop= erly (RFC5575 Type 12 Fragment). -Tiru --_000_787AE7BB302AE849A7480A190F8B93302DF10737OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,

 

Given the clarification provide= d by the authors of the netmod-acl I-D, the current design for handling IPv= 6 fragments in the DOTS data channel specification is the appropriate way to proceed.

 

I consider this issue as closed= .

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf= @jpshallow.com]
Envoy=E9 : lundi 16 avril 2018 16:46
=C0 : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; dot= s@ietf.org
Objet : RE: [Dots] Data Channel ACL fragments=

 

Hi Med,=

&n= bsp;

I think= that this comes down to external integration.  Whilst out of scope, t= he data model communication method for transferring the ACL/ACEs between a = DOTS Server and a DOTS Mitigator cannot be using standard netmod-acl as there is no way to define how to handle fragm= entation usage in it (following your reasoning/interpretation of netmod-acl= ) unless there is a separate augmentation in that data model to include fra= gments definitions.

&n= bsp;

Perhaps= the right answer is to get the text in netmod-acl tightened up for clarity= between protocol and next-header (along with what is flags-> fragment r= eally meant to do for an ACL in grouping acl-ipv4-header-fields).

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 16 April 2018 13:23
To: Jon Shallow; Konda, Tirumaleswar Reddy; dots@ietf.org
Subject: Re: [Dots] Data Channel ACL fragments

 

Jon,

 

I’m afraid the current ne= tmod-acl does not allow to appropriately handle IPv6 fragments (and more fi= ltering based on Extension Header Types in general). At least, the text is not clear whether “protocol” applies for th= e next-header of the base header or the one of any enclosed EH.

 

The use of v6-fragment keyword = (in the data-channel draft) solves this by performing a check whether a Fra= gment header is present.

 

     &= nbsp;    "ace": [

     &= nbsp;      {

     &= nbsp;        "name": "dro= p-all-fragments",

     &= nbsp;        "matches": {=

     &= nbsp;          "ipv6"= ;: {

     &= nbsp;            &qu= ot;v6-fragment"

     &= nbsp;          }

     &= nbsp;        },

     &= nbsp;        "actions": {=

     &= nbsp;          "forwardin= g": "drop"

     &= nbsp;        }

     &= nbsp;      }

     &= nbsp;    ]

 

This check is exactly what Cisc= o and Juniper are doing in the excerpts you provided.

 

Cheers,

Med

 

J= on Shallow [mailto:supjps-ietf= @jpshallow.com]
Envoy=E9 : lundi 16 = avril 2018 14:08
=C0 : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; dots@ietf.org
Objet : RE: [Dots] Data Channel ACL fragments=

 

Hi Med,=

&n= bsp;

Current= ly we disagree over IPv6 and fragmentation.

&n= bsp;

As per = https://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_pap= er0900aecd8054d37d.html , ACL filtering does work on “fragments&#= 8221;.

&n= bsp;

Filtering Based on Extension H= eader Type

 

Routers can be explicitly inst= ructed to look at and act on traffic that contains certain extension header= types. This functionality is available on Cisco platforms and can be configured with the help of IPv6 Access List options:=

 

deny protocol {source-ipv6-pre= fix/prefix-length | any | host source-ipv6-address} [operator [port-number]= ] {destination-ipv6-prefix/prefix-length | any | host destination-ipv6-address} [operator [port-number]] [dest-option-type = [doh-number | doh-type]] [dscp value] [flow-label value] [fragments] [log] = [log-input] [mobility] [mobility-type [mh-number | mh-type]] [routing] [rou= ting-type routing-number] [sequence value] [time-range name] [undetermined-transport]

 

Example 1: Access List Filteri= ng based on Extension Header Type

ipv6 access-list EH-type<= /o:p>

deny ipv6 any 2001:2B8:1:1::/6= 4 routing

 

In order to permit or deny cer= tain types of extension headers, routers are configured with the ACL featur= es listed above to filter based on the "Header Type" value (see Table 1).

 

Note that in this case, the co= ntent of the EH is not processed and the router simply makes a decision bas= ed on the presence of a certain EH type. Software platforms can also analyze and filter based on additional EH fields such a= s the "Type Field". These filtering capabilities are very useful = in implementing, for instance, security policies such as blocking source ro= uting.

…

Since this functionality is im= plemented through ACLs, platforms that support hardware forwarding when ACL= s are applied, will be able to handle the IPv6 traffic with EHs in hardware as well (Figure 7).

&n= bsp;

Juniper= appears to support this on the MX router (see https://www.juniper.net/documentation/en_US/junos/topics/reference/general/= firewall-filter-match-conditions-for-ipv6-traffic.html)

&n= bsp;

extension-headers header-type<= o:p>

 

Match an extension header type= that is contained in the packet by identifying a Next Header value.

Note: This match condition is = only supported on MPCs in MX Series routers.

 

In the first fragment of a pac= ket, the filter searches for a match in any of the extension header types. = When a packet with a fragment header is found (a subsequent fragment), the filter only searches for a match of the next ext= ension header type because the location of other extension headers is unpre= dictable.

In place of the numeric value,= you can specify one of the following text synonyms (the field values are a= lso listed): ah (51), destination (60), esp (50), fragment (44), hop-by-hop (0), mobility (135), or routing (43).=

To match any value for the ext= ension header option, use the text synonym any.

For MX Series routers with MPC= s, initialize new firewall filters that include this condition by walking t= he corresponding SNMP MIB.

&n= bsp;

So, no = matter where the fragment header is (even with subsequent extended headers = (to me the Authenticating Header, or ESP header is the actual protocol)) be= fore the actual protocol, matching on protocol 44 works and is map-able to Cisco/Juniper ALCs where they do not = need to use the control plane – or am I missing something here?<= /o:p>

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto:ietf-sup= jps-dots-bounces@ietf.org] On Behalf Of ietf-supjps-mohamed.boucadair@orange.com
Sent: 16 April 2018 12:11
To: Konda, Tirumaleswar Reddy; Jon Shallow; dots@ietf.org
Subject: Re: [Dots] Data Channel ACL fragments

 

Hi all,

 

I do agree with the conclusion = of this thread for IPv4 but not for IPv6.

 

For example, a DOTS client may = send this POST request to filter fragmented packets (including atomic ones)= :

 

{

  "ietf-dots-data-cha= nnel:acls": {

    "acl&qu= ot;: [

      = {

     &= nbsp;  "name": "dns-fragments",<= /p>

     &= nbsp;  "type": "ipv6-acl-type",<= /p>

     &= nbsp;  "aces": {

     &= nbsp;    "ace": [

     &= nbsp;      {

     &= nbsp;        "name": "dro= p-all-fragments",

     &= nbsp;        "matches": {=

     &= nbsp;          "ipv6"= ;: {

     &= nbsp;            &qu= ot;protocol": 44

     &= nbsp;          }

     &= nbsp;        },

     &= nbsp;        "actions": {=

     &= nbsp;          "forwardin= g": "drop"

     &= nbsp;        }

     &= nbsp;      }

     &= nbsp;    ]

     &= nbsp;    "ace": [

     &= nbsp;      {

     &= nbsp;        "name": "all= ow-dns-packets",

     &= nbsp;        "matches": {=

     &= nbsp;          "ipv6"= ;: {

     &= nbsp;            &qu= ot;destination-ipv6-network": "2001:db8::/32"

     &= nbsp;          }

       &nbs= p;        "udp": {<= /span>

       &nbs= p;          "destination-= port": {

       &nbs= p;            "= operator": "eq",

       &nbs= p;            "= port": 53

       &nbs= p;          }

     &= nbsp;          }

     &= nbsp;        },

     &= nbsp;        "actions": {=

     &= nbsp;          "forwardin= g": "accept"

     &= nbsp;        }

     &= nbsp;      }

     &= nbsp;    ]

     &= nbsp;  }

      = }

    ]=

  }

}

 

But these ACEs are efficient on= ly if the next-header of the IPv6 header points to 44. If the IPv6 packet i= ncludes other EHs and the Fragment header is not the one which is immediately preceding the base header, then fragmented pa= ckets won’t match the "drop-all-fragments" ACE.<= /span>

 

Cheers,

Med

 

De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_= Konda@McAfee.com]
Envoy=E9 : samedi 14 avril 2018 06:48
=C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: [Dots] Data Channel ACL fragments=

 

Sure, Appendix looks like the right place to add the filtering rule e= xamples for both IPv4 and IPv6.

 

-Tiru

 

From: Jon Shallow [mailto:s= upjps-ietf@jpshallow.com]
Sent: Friday, April 13, 2018 6:00 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; mohamed.boucadair@orange.co= m; dots@ietf.org
Subject: RE: [Dots] Data Channel ACL fragments

 

Hi Tiru= ,

&n= bsp;

Thanks.=

&n= bsp;

I think= that we do need an example in the draft of how to do this though….

&n= bsp;

IPv6 wi= ll not be using flags, but looking instead for the next header of protocol = 44.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto:ietf-sup= jps-dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 13 April 2018 13:25
To: Jon Shallow; moh= amed.boucadair@orange.com; dots@ietf.org
Subject: Re: [Dots] Data Channel ACL fragments

 

[Jon6] = – Yes – I stand corrected, your ordering is correct.  A2 n= o longer needs destination-port.

 

Yup. The summary of our discussion is to use the flags defined in net= mod-acl-model to drop fragments (both initial and non-initial), and v4-frag= ments and v6-fragments and the associated text added to drop non-initial fragments discussed in Section 4.1 will be = removed from the draft.

 

Cheers

-Tiru

 

From: Jon Shallow [mailto:s= upjps-ietf@jpshallow.com]
Sent: Friday, April 13, 2018 3:39 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; mohamed.boucadair@orange.co= m; dots@ietf.org
Subject: RE: [Dots] Data Channel ACL fragments

 

Hi Tiru= ,

&n= bsp;

See inl= ine [Jon6]

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 13 April 2018 10:03
To: Jon Shallow; moh= amed.boucadair@orange.com; dots@ietf.org
Subject: Re: [Dots] Data Channel ACL fragments

 

Hi Jon,

 

Please see inline [TR4]

 

&n= bsp;

From:= Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Konda@mcafee.com]
Sent: 10 April 2018 07:10
To: Jon Shallow; moh= amed.boucadair@orange.com; dots@ietf.org
Subject: RE: [Dots] Data Channel ACL fragments

 

[Jon2] = The “flags->fragment” definition is ambiguous for an ACE (bu= t valid as to whether to allow a packet to get fragmented or not – is= that really a ACE?) which I would like to use. 

&n= bsp;

[TR] I = don’t get it. What purpose does it serve to create a ACE rule using &= #8220;fragment” bit ?

[Jon3] = Agreed – This definition has not been thought through for an ACE.&nbs= p; I think they have just emulated the DF bit in RFC791 as this general fla= gs definition is the same as for the flags in RFC791.

 

[TR2] You may want to inform th= e authors of netmod-acl draft, surprisingly BGP flowspec also uses “f= ragment” bit.<= /p>

[Jon4] = On my ToDo list for a clean solution.  But we do now have a solution &= #8211; see below.

 

&n= bsp;

“= Flags->more” definition covers all fragments but the last fragment= ... “Offset” is unfortunately not a range, but otherwise would = get used for the final fragment.

~jon2

&n= bsp;

[TR] It= looks like two ACE entries are required to drop all the fragments (“= flags->more” set to 1 in the first ACE and “flags->more&#= 8221; set to 0 in the second ACE). How to use the “Offset” &nbs= p;field for the final fragment ?

&n= bsp;

[Jon3] = I read “flags-more” to refer to the IP_MF in the IP header (RFC= 791 MF or more-fragments flag).  This is set for all fragments apart f= rom the final (as in last part of packet, not the order in which they are sent – fortunately that early decision to send the= m in the wrong order was phased out, but still there in some legacy systems= !)

 

[TR2] Yes, why can’t R= 20;flags->more” be set to 0 as one ACE entry to drop the final fra= gment along with “flags->more” set to 1 to drop the first fr= agment as another ACE entry so as to drop all fragments to the target ?

[Jon4] = If “flags->more” is configured and it is configured with a v= alue of 0, this will match not only the final fragment, but also a non-frag= mented packet.  If “flags->more” is not configured, the= n this will match a non-fragmented packet only.

 

[TR3] net-mod-acl says "Se= tting the value to 0 indicates this is the last fragment, and setting the v= alue to 1 indicates more fragments are coming.". I think it means, if = “flags->more” is set to zero and offset is not zero then it indicates this is the last fragments; the flags can be used i= n isolation without comparing if offset value is zero or non-zero. We shoul= d check with netmod-acl authors for confirmation.

&n= bsp;

[Jon5].=   The netmod-acl text for flags and offset is effectively a word for w= ord copy out of RFC791 3.1 Internet Header Format.  So I think it is m= eant to be interpreted as being an exact match for the same – including the offset specific value.

&n= bsp;

  Flags:  3 bits

 

    Various Control Flags.<= /span>

 

      Bit 0: reserved, must = be zero

      Bit 1: (DF) 0 =3D May = Fragment,  1 =3D Don't Fragment.

      Bit 2: (MF) 0 =3D Last= Fragment, 1 =3D More Fragments.

 

         = ; 0   1   2

        +---&#= 43;---+---+

        | &nb= sp; | D | M |

        | 0 | F | = F |

        +---&#= 43;---+---+

 

  Fragment Offset:  13 bits

 

    This field indicates where in the = datagram this fragment belongs.

 

    The fragment offset is measured in= units of 8 octets (64 bits).  The

    first fragment has offset zero.

 

 

----

 

Versus

 

----

    leaf flags {

      type bits {=

        bit reserv= ed {

         = ; position 0;

         = ; description

         = ;   "Reserved. Must be zero.";

        }

        bit fragme= nt {

         = ; position 1;

         = ; description

         = ;   "Setting value to 0 indicates may fragment, while settin= g

         = ;    the value to 1 indicates do not fragment.";

        }

        bit more {=

         = ; position 2;

         = ; description

         = ;   "Setting the value to 0 indicates this is the last fragm= ent,

         = ;    and setting the value to 1 indicates more fragments are=

         = ;    coming.";

        }

      }

      description=

        "Bit = definitions for the flags field in IPv4 header.";

    }

 

    leaf offset {

      type uint16 {

        range &quo= t;20..65535";

      }

 

      description=

        "The = fragment offset is measured in units of 8 octets (64 bits).

         The = first fragment has offset zero. The length is 13 bits";

    }

&n= bsp;

[Jon4] = So, a L4 ACE without “flags->more” defined and “allow&= #8221;, followed by an ACE with “flags->more” =3D 1 and R= 20;drop”, followed by an ACE with “flags->more” =3D 0 = and “drop” will cause all fragmented packets to get dropped, but still allow through the non-fragmented packet.=   So, we have a solution for

“= allow all traffic to port 53, but drop all fragmented packets”.<= /o:p>

 

[TR3] I don’t think the a= bove solution will work. In the above line, I think you  meant L3 ACE,= and the first fragment will match the first entry and is allowed.

&n= bsp;

[Jon5]N= o, the first ACE is a L3/L4 match.  If you have (a1 allows through all= non-fragmented packets, a2 & a3 drops all fragmented packets) the foll= owing

 

[TR4] The first fragment will h= ave both L3 and L4 information, and matches a1 and is allowed, but if the o= rder is changed to a3, a1 and a2 (a3 will drop all fragments except last-fr= agment, the last fragment will not have L4 info, so will not match a1 but will match a2 and get dropped).

&n= bsp;

[Jon6] = – Yes – I stand corrected, your ordering is correct.  A2 n= o longer needs destination-port.

~jon6

 

-Tiru

&n= bsp;

…=

{

       "aces"= : [{

         = ;            &n= bsp;            = ;   "ace": {

         = ;            &n= bsp;            = ;            &n= bsp;     "name": "a1",

         = ;            &n= bsp;            = ;            &n= bsp;     "matches": [{

         = ;            &n= bsp;            = ;            &n= bsp;            = ;        "ipv4": {<= /span>

         = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;          "destinatio= n-network": "1.2.3.0/24"

         = ;            &n= bsp;            = ;            &n= bsp;            = ;        },

         = ;            &n= bsp;            = ;            &n= bsp;            = ;        "udp": {

         = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;          "destinatio= n-port": 53

         = ;            &n= bsp;            = ;            &n= bsp;            = ;        }

         = ;            &n= bsp;            = ;            &n= bsp;     }],

         = ;            &n= bsp;            = ;            &n= bsp;     "actions": {

         = ;            &n= bsp;            = ;            &n= bsp;            = ;        "forwarding": "a= ccept"

         = ;            &n= bsp;            = ;            &n= bsp;     }

         = ;            &n= bsp;            = ;   }

         = ;             }= ,

         = ;             {=

         = ;            &n= bsp;            = ;   "ace": {

         = ;            &n= bsp;            = ;            &n= bsp;     "name": "a2",

         = ;            &n= bsp;            = ;            &n= bsp;     "matches": [{

         = ;            &n= bsp;            = ;            &n= bsp;            = ;        "ipv4": {<= /span>

         = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;          "flags"= ;: {

         = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;             &= quot;destination-network": "1.2.3.0/24",

         = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;             &= quot;more": 0

         = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;          },

         = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;          "udp":= {

         = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;             &= quot;destination-port": 53

         = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;          }

         = ;            &n= bsp;            = ;            &n= bsp;            = ;        }

         = ;            &n= bsp;            = ;            &n= bsp;     }],

         = ;            &n= bsp;            = ;            &n= bsp;     "actions": {

         = ;            &n= bsp;            = ;            &n= bsp;            = ;        "forwarding": "d= rop"

         = ;            &n= bsp;            = ;            &n= bsp;     }

 

         = ;            &n= bsp;            = ;   }

         = ;             }= ,

         = ;             {=

         = ;            &n= bsp;            = ;   "ace": {

         = ;            &n= bsp;            = ;            &n= bsp;     "name": "a3",

         = ;            &n= bsp;            = ;            &n= bsp;     "matches": [{

         = ;            &n= bsp;            = ;            &n= bsp;            = ;        "ipv4": {<= /span>

         = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;          "flags"= ;: {

         = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;             &= quot;more": 1

         = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;          }

         = ;            &n= bsp;            = ;            &n= bsp;            = ;        }

         = ;            &n= bsp;            = ;            &n= bsp;     }],

         = ;            &n= bsp;            = ;            &n= bsp;     "actions": {

         = ;            &n= bsp;            = ;            &n= bsp;            = ;        "forwarding": "d= rop"

         = ;            &n= bsp;            = ;            &n= bsp;     }

         = ;            &n= bsp;            = ;   }

         = ;             }=

       ]

}<= /o:p>

…=

[Jon5] = It will work

 

-Tiru

 

~jon4

 

-Tiru

&n= bsp;

[Jon3] = But as the final fragment of the sequence could have any offset, the use of= the offset field is not that helpful here.  Even if we do go with our= DOTS fragments definition (but widened to cover all fragments), we still cannot generate a netmod-acl entry for onwa= rd processing by an upstream mitigator.

&n= bsp;

[Jon3] = FYI, for Juniper, you just need to set ‘first-fragment’ and = 216;is-fragment’ in their ACL.  BGP FlowSpec does support fragme= ntation detection properly (RFC5575 Type 12 Fragment).

 

&n= bsp;

-Tiru<= /span>

--_000_787AE7BB302AE849A7480A190F8B93302DF10737OPEXCLILMA3corp_-- From nobody Wed Apr 25 04:59:09 2018 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 D2631126DD9 for ; Wed, 25 Apr 2018 04:59:07 -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 zRooXFKV6z2c for ; Wed, 25 Apr 2018 04:59: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 E21AE126D0C for ; Wed, 25 Apr 2018 04:59:05 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.90_1) (envelope-from ) id 1fBJ4g-0007KB-Sp for ietf-supjps-dots@ietf.org; Wed, 25 Apr 2018 12:59:02 +0100 From: "Jon Shallow" To: Date: Wed, 25 Apr 2018 12:59:01 +0100 Message-ID: <006901d3dc8c$cd1e6610$675b3230$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006A_01D3DC95.2EE36A50" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdPcjMsE8ckpBFbCSNuFe2wUQEInWA== Content-Language: en-gb Archived-At: Subject: [Dots] data channel and pending-lifetime 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: Wed, 25 Apr 2018 11:59:08 -0000 This is a multipart message in MIME format. ------=_NextPart_000_006A_01D3DC95.2EE36A50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi there, To make pending-lifetime work, the Alias / ACL needs to periodically be refreshed by the DOTS client to make sure the entry does not go stale and consequently get deleted by the DOTS server. RESTCONF RFC 8040 4.4.1 Create Resource Mode If the data resource already exists, then the POST request MUST fail and a "409 Conflict" status-line MUST be returned. The error-tag value "resource-denied" is used in this case. So, we cannot really use POST to refresh the Alias / ACL unless the 409 is to be ignored. RFC 8040 4.5 PUT Consistent with [RFC7231], if the PUT request creates a new resource, a "201 Created" status-line is returned. If an existing resource is modified, a "204 No Content" status-line is returned. So, PUT will work. In draft-ietf-dots-data-channel-15, there are no sections on describing how Aliases / ACLS are to be refreshed other than A DOTS server MUST maintain a [filtering rule|alias] for at least 10080 minutes (1 week). If no refresh request is seen from the DOTS client, the DOTS server removes expired entries. I assume that a PUT refresh request must be an exact match for the initial request (or an echo back of the GET response with some fields stripped out that are ro). Correct? Regards Jon ------=_NextPart_000_006A_01D3DC95.2EE36A50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = there,

 

To make pending-lifetime work, the Alias / ACL needs = to periodically be refreshed by the DOTS client to make sure the entry = does not go stale and consequently get deleted by the DOTS = server.

 

RESTCONF RFC 8040 4.4.1 Create Resource = Mode

 

   If the data resource already exists, then = the POST request MUST fail

   and a "409 Conflict" = status-line MUST be returned.  The error-tag

   value "resource-denied" is used = in this case.

 

So, we cannot really use POST to refresh the Alias / = ACL unless the 409 is to be ignored.

 

RFC 8040 4.5 = PUT

 

   Consistent with [RFC7231], if the PUT = request creates a new resource,

   a "201 Created" status-line is = returned.  If an existing resource is

   modified, a "204 No Content" = status-line is returned.

 

So, PUT will = work.

 

In draft-ietf-dots-data-channel-15, there are no = sections on describing how Aliases / ACLS are to be refreshed other = than

 

   A DOTS server MUST maintain a [filtering = rule|alias] for at least 10080

   minutes (1 week).  If no refresh = request is seen from the DOTS

   client, the DOTS server removes expired = entries.

 

I assume that a PUT refresh request must be an exact = match for the initial request (or an echo back of the GET response with = some fields stripped out that are ro).  Correct?

 

Regards

 

Jon

------=_NextPart_000_006A_01D3DC95.2EE36A50-- From nobody Wed Apr 25 05:24:07 2018 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 2857C126B6E for ; Wed, 25 Apr 2018 05:23:59 -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, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-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 5X8RocYxZ1tu for ; Wed, 25 Apr 2018 05:23:54 -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 158411252BA for ; Wed, 25 Apr 2018 05:23:52 -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=1524659033; 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: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-microsoft-antispam: x-ms-traffictypediagnostic:x-microsoft-antispam-prvs: x-exchange-antispam-report-test:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Office365-Filtering-Correlation-Id: X-MS-Exchange-CrossTenant-Network-Message-Id: 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=5Ry9mshvj319/qACiIAmiS4NDW18VA/uSoApXZ TlBZc=; b=lgDgy4ssAUpnlI/BRoIv3K4Q1CrdhcJ+KycqvV4R Wn0N2xXEeqVDhHxQuAp5QKKzFAGZdC2y9FAhbh+hVD9gI9nAIq +Itl7eboDg46Ng5G/GhhR0dVzE/bW/7mxhEp4uM+9QmhhH+4dX Cy8/erKbI8GmwjCUjlM17dQlPgsQK+0= Received: from DNVEXAPP1N04.corpzone.internalzone.com (unknown [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 2bfc_b424_3b79a80c_fd46_494a_96af_03ede72f0d40; Wed, 25 Apr 2018 07:23:52 -0500 Received: from DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 25 Apr 2018 06:23:45 -0600 Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 25 Apr 2018 06:23:45 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Wed, 25 Apr 2018 06:23:44 -0600 Received: from NAM01-BY2-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.1347.2; Wed, 25 Apr 2018 06:22:02 -0600 Received: from BN6PR16MB1425.namprd16.prod.outlook.com (10.172.207.19) by BN6PR16MB1553.namprd16.prod.outlook.com (10.172.208.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.715.18; Wed, 25 Apr 2018 12:22:03 +0000 Received: from BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::4430:6104:630b:a067]) by BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::4430:6104:630b:a067%3]) with mapi id 15.20.0696.020; Wed, 25 Apr 2018 12:22:03 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] data channel and pending-lifetime Thread-Index: AdPcjMsE8ckpBFbCSNuFe2wUQEInWAAAovCw Date: Wed, 25 Apr 2018 12:22:02 +0000 Message-ID: References: <006901d3dc8c$cd1e6610$675b3230$@jpshallow.com> In-Reply-To: <006901d3dc8c$cd1e6610$675b3230$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.300.84 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [122.167.135.187] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR16MB1553; 7:PdMhYMfU0CwmePAcpJD2QjumoryjhCoVDVdYpoYLs8P6LVepVGd7cIwDQe4clgLda9WwpwIrVW6LOGzGEdKMH85vS7cptJjrVSqSA6S9EBuNfwr6w23g2GSbxzXSLDgsceR5epJtbAUBdVKsJ+fsrHhUEW+isjtc7QSgZ/l2rbr04uqyXquIrRxTXJ+aqVbskLvcxO+JfnasgBfK6IEoAHYKCSXk6wEWmzGqfAEJD50j/vuMwPp3OIlJWeuPpKn1 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BN6PR16MB1553; x-ms-traffictypediagnostic: BN6PR16MB1553: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3231232)(944501410)(52105095)(3002001)(93006095)(93001095)(6041310)(20161123562045)(20161123558120)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:BN6PR16MB1553; BCL:0; PCL:0; RULEID:; SRVR:BN6PR16MB1553; x-forefront-prvs: 06530126A4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39860400002)(366004)(396003)(346002)(39380400002)(32952001)(189003)(199004)(76176011)(7736002)(74316002)(33656002)(486006)(14454004)(7696005)(26005)(316002)(2900100001)(5660300001)(59450400001)(229853002)(110136005)(102836004)(6506007)(53546011)(2501003)(5890100001)(5250100002)(81166006)(99286004)(106356001)(105586002)(6246003)(81156014)(2906002)(80792005)(68736007)(6436002)(790700001)(6116002)(3846002)(186003)(8936002)(86362001)(53936002)(8676002)(6306002)(54896002)(9686003)(55016002)(97736004)(72206003)(446003)(19609705001)(476003)(3660700001)(11346002)(66066001)(25786009)(3280700002)(478600001)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR16MB1553; H:BN6PR16MB1425.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: oLsQeEtVCTNX34vmxX3gB0NttXUuxhCFgUfwQ2Xs7CsQTtAgIO10WqDhe0ffS6xxemXK5GTgDrdAushyBmzs+9+Ea//v/wrue6lvqAYOz9d7+sp/IcFRsxt1XATXulZRccwfqdWwK9rF2sv5851dMHAQRGHFlj0Lzr3KXsT76pyGqswmOtEBbe5mri9ziOGQO/ju/5G1Ycawn4gVEFHTOQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR16MB1425CBA71F277C2A61264536EA8F0BN6PR16MB1425namp_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: b0161bb7-34cb-45a8-8540-08d5aaa726d0 X-MS-Exchange-CrossTenant-Network-Message-Id: b0161bb7-34cb-45a8-8540-08d5aaa726d0 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Apr 2018 12:22:02.8161 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR16MB1553 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6272> : inlines <6586> : streams <1785049> : uri <2631442> Archived-At: Subject: Re: [Dots] data channel and pending-lifetime 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: Wed, 25 Apr 2018 12:23:59 -0000 --_000_BN6PR16MB1425CBA71F277C2A61264536EA8F0BN6PR16MB1425namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogRG90cyBbbWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEpv biBTaGFsbG93DQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDI1LCAyMDE4IDU6MjkgUE0NClRvOiBk b3RzQGlldGYub3JnDQpTdWJqZWN0OiBbRG90c10gZGF0YSBjaGFubmVsIGFuZCBwZW5kaW5nLWxp ZmV0aW1lDQoNCg0KQ0FVVElPTjogVGhpcyBlbWFpbCBvcmlnaW5hdGVkIGZyb20gb3V0c2lkZSBv ZiB0aGUgb3JnYW5pemF0aW9uLiBEbyBub3QgY2xpY2sgbGlua3Mgb3Igb3BlbiBhdHRhY2htZW50 cyB1bmxlc3MgeW91IHJlY29nbml6ZSB0aGUgc2VuZGVyIGFuZCBrbm93IHRoZSBjb250ZW50IGlz IHNhZmUuDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkhpIHRoZXJlLA0K DQpUbyBtYWtlIHBlbmRpbmctbGlmZXRpbWUgd29yaywgdGhlIEFsaWFzIC8gQUNMIG5lZWRzIHRv IHBlcmlvZGljYWxseSBiZSByZWZyZXNoZWQgYnkgdGhlIERPVFMgY2xpZW50IHRvIG1ha2Ugc3Vy ZSB0aGUgZW50cnkgZG9lcyBub3QgZ28gc3RhbGUgYW5kIGNvbnNlcXVlbnRseSBnZXQgZGVsZXRl ZCBieSB0aGUgRE9UUyBzZXJ2ZXIuDQoNClJFU1RDT05GIFJGQyA4MDQwIDQuNC4xIENyZWF0ZSBS ZXNvdXJjZSBNb2RlDQoNCiAgIElmIHRoZSBkYXRhIHJlc291cmNlIGFscmVhZHkgZXhpc3RzLCB0 aGVuIHRoZSBQT1NUIHJlcXVlc3QgTVVTVCBmYWlsDQogICBhbmQgYSAiNDA5IENvbmZsaWN0IiBz dGF0dXMtbGluZSBNVVNUIGJlIHJldHVybmVkLiAgVGhlIGVycm9yLXRhZw0KICAgdmFsdWUgInJl c291cmNlLWRlbmllZCIgaXMgdXNlZCBpbiB0aGlzIGNhc2UuDQoNClNvLCB3ZSBjYW5ub3QgcmVh bGx5IHVzZSBQT1NUIHRvIHJlZnJlc2ggdGhlIEFsaWFzIC8gQUNMIHVubGVzcyB0aGUgNDA5IGlz IHRvIGJlIGlnbm9yZWQuDQoNClJGQyA4MDQwIDQuNSBQVVQNCg0KICAgQ29uc2lzdGVudCB3aXRo IFtSRkM3MjMxXSwgaWYgdGhlIFBVVCByZXF1ZXN0IGNyZWF0ZXMgYSBuZXcgcmVzb3VyY2UsDQog ICBhICIyMDEgQ3JlYXRlZCIgc3RhdHVzLWxpbmUgaXMgcmV0dXJuZWQuICBJZiBhbiBleGlzdGlu ZyByZXNvdXJjZSBpcw0KICAgbW9kaWZpZWQsIGEgIjIwNCBObyBDb250ZW50IiBzdGF0dXMtbGlu ZSBpcyByZXR1cm5lZC4NCg0KU28sIFBVVCB3aWxsIHdvcmsuDQoNCkluIGRyYWZ0LWlldGYtZG90 cy1kYXRhLWNoYW5uZWwtMTUsIHRoZXJlIGFyZSBubyBzZWN0aW9ucyBvbiBkZXNjcmliaW5nIGhv dyBBbGlhc2VzIC8gQUNMUyBhcmUgdG8gYmUgcmVmcmVzaGVkIG90aGVyIHRoYW4NCg0KICAgQSBE T1RTIHNlcnZlciBNVVNUIG1haW50YWluIGEgW2ZpbHRlcmluZyBydWxlfGFsaWFzXSBmb3IgYXQg bGVhc3QgMTAwODANCiAgIG1pbnV0ZXMgKDEgd2VlaykuICBJZiBubyByZWZyZXNoIHJlcXVlc3Qg aXMgc2VlbiBmcm9tIHRoZSBET1RTDQogICBjbGllbnQsIHRoZSBET1RTIHNlcnZlciByZW1vdmVz IGV4cGlyZWQgZW50cmllcy4NCg0KSSBhc3N1bWUgdGhhdCBhIFBVVCByZWZyZXNoIHJlcXVlc3Qg bXVzdCBiZSBhbiBleGFjdCBtYXRjaCBmb3IgdGhlIGluaXRpYWwgcmVxdWVzdCAob3IgYW4gZWNo byBiYWNrIG9mIHRoZSBHRVQgcmVzcG9uc2Ugd2l0aCBzb21lIGZpZWxkcyBzdHJpcHBlZCBvdXQg dGhhdCBhcmUgcm8pLiAgQ29ycmVjdD8NCg0KW1RSXSBZZXMuDQoNCi1UaXJ1DQoNClJlZ2FyZHMN Cg0KSm9uDQo= --_000_BN6PR16MB1425CBA71F277C2A61264536EA8F0BN6PR16MB1425namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpEZW5nWGlhbjsNCglwYW5vc2UtMToy IDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJcQERlbmdYaWFuIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0 eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVM7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5t c29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFt ZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBp bjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9u dC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFu LkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHls ZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEu MGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+IERvdHMgW21haWx0bzpkb3RzLWJv dW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkpvbiBTaGFsbG93PGJyPg0KPGI+ U2VudDo8L2I+IFdlZG5lc2RheSwgQXByaWwgMjUsIDIwMTggNToyOSBQTTxicj4NCjxiPlRvOjwv Yj4gZG90c0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbRG90c10gZGF0YSBjaGFubmVs IGFuZCBwZW5kaW5nLWxpZmV0aW1lPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHRhYmxlIGNsYXNzPSJNc29O b3JtYWxUYWJsZSIgYm9yZGVyPSIxIiBjZWxsc3BhY2luZz0iMyIgY2VsbHBhZGRpbmc9IjAiIHN0 eWxlPSJiYWNrZ3JvdW5kOiNGNEYxRTM7Ym9yZGVyOnNvbGlkICM5QjlBODcgMS41cHQiPg0KPHRi b2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJib3JkZXI6bm9uZTtwYWRkaW5nOi43NXB0IC43NXB0IC43 NXB0IC43NXB0Ij4NCjxwPjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzlCOEIzRSI+Q0FVVElPTjwvc3Bhbj48L3N0cm9u Zz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojOUI4QjNFIj46PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4gVGhpcyBlbWFpbCBvcmlnaW5hdGVkIGZy b20gb3V0c2lkZSBvZiB0aGUNCiBvcmdhbml6YXRpb24uIERvIG5vdCBjbGljayBsaW5rcyBvciBv cGVuIGF0dGFjaG1lbnRzIHVubGVzcyB5b3UgcmVjb2duaXplIHRoZSBzZW5kZXIgYW5kIGtub3cg dGhlIGNvbnRlbnQgaXMgc2FmZS48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8 L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJj ZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+DQo8aHIgc2l6ZT0iMyIgd2lkdGg9IjEwMCUi IGFsaWduPSJjZW50ZXIiPg0KPC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+SGkgdGhlcmUsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5UbyBt YWtlIHBlbmRpbmctbGlmZXRpbWUgd29yaywgdGhlIEFsaWFzIC8gQUNMIG5lZWRzIHRvIHBlcmlv ZGljYWxseSBiZSByZWZyZXNoZWQgYnkgdGhlIERPVFMgY2xpZW50IHRvIG1ha2Ugc3VyZSB0aGUg ZW50cnkgZG9lcyBub3QgZ28gc3RhbGUgYW5kIGNvbnNlcXVlbnRseSBnZXQgZGVsZXRlZCBieSB0 aGUgRE9UUyBzZXJ2ZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5SRVNUQ09ORiBSRkMgODA0MCA0LjQu MSBDcmVhdGUgUmVzb3VyY2UgTW9kZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7Jm5ic3A7IElm IHRoZSBkYXRhIHJlc291cmNlIGFscmVhZHkgZXhpc3RzLCB0aGVuIHRoZSBQT1NUIHJlcXVlc3Qg TVVTVCBmYWlsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiPiZuYnNwOyZuYnNwOyBhbmQgYSAmcXVvdDs0MDkgQ29uZmxpY3QmcXVv dDsgc3RhdHVzLWxpbmUgTVVTVCBiZSByZXR1cm5lZC4mbmJzcDsgVGhlIGVycm9yLXRhZzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC Ij4mbmJzcDsmbmJzcDsgdmFsdWUgJnF1b3Q7cmVzb3VyY2UtZGVuaWVkJnF1b3Q7IGlzIHVzZWQg aW4gdGhpcyBjYXNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+U28sIHdlIGNhbm5vdCByZWFsbHkgdXNl IFBPU1QgdG8gcmVmcmVzaCB0aGUgQWxpYXMgLyBBQ0wgdW5sZXNzIHRoZSA0MDkgaXMgdG8gYmUg aWdub3JlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPlJGQyA4MDQwIDQuNSBQVVQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiPiZuYnNwOyZuYnNwOyBDb25zaXN0ZW50IHdpdGggW1JGQzcyMzFdLCBpZiB0aGUgUFVU IHJlcXVlc3QgY3JlYXRlcyBhIG5ldyByZXNvdXJjZSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7Jm5ic3A7IGEgJnF1 b3Q7MjAxIENyZWF0ZWQmcXVvdDsgc3RhdHVzLWxpbmUgaXMgcmV0dXJuZWQuJm5ic3A7IElmIGFu IGV4aXN0aW5nIHJlc291cmNlIGlzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOyZuYnNwOyBtb2RpZmllZCwgYSAmcXVv dDsyMDQgTm8gQ29udGVudCZxdW90OyBzdGF0dXMtbGluZSBpcyByZXR1cm5lZC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiPlNvLCBQVVQgd2lsbCB3b3JrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+SW4gZHJhZnQt aWV0Zi1kb3RzLWRhdGEtY2hhbm5lbC0xNSwgdGhlcmUgYXJlIG5vIHNlY3Rpb25zIG9uIGRlc2Ny aWJpbmcgaG93IEFsaWFzZXMgLyBBQ0xTIGFyZSB0byBiZSByZWZyZXNoZWQgb3RoZXIgdGhhbjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7Jm5ic3A7IEEgRE9UUyBzZXJ2ZXIgTVVTVCBtYWludGFp biBhIFtmaWx0ZXJpbmcgcnVsZXxhbGlhc10gZm9yIGF0IGxlYXN0IDEwMDgwPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNw OyZuYnNwOyBtaW51dGVzICgxIHdlZWspLiZuYnNwOyBJZiBubyByZWZyZXNoIHJlcXVlc3QgaXMg c2VlbiBmcm9tIHRoZSBET1RTPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOyZuYnNwOyBjbGllbnQsIHRoZSBET1RTIHNl cnZlciByZW1vdmVzIGV4cGlyZWQgZW50cmllcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPkkgYXNzdW1l IHRoYXQgYSBQVVQgcmVmcmVzaCByZXF1ZXN0IG11c3QgYmUgYW4gZXhhY3QgbWF0Y2ggZm9yIHRo ZSBpbml0aWFsIHJlcXVlc3QgKG9yIGFuIGVjaG8gYmFjayBvZiB0aGUgR0VUIHJlc3BvbnNlIHdp dGggc29tZSBmaWVsZHMgc3RyaXBwZWQgb3V0IHRoYXQgYXJlIHJvKS4mbmJzcDsgQ29ycmVjdD88 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiPltUUl0gWWVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+LVRpcnU8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiPlJlZ2FyZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPkpvbjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BN6PR16MB1425CBA71F277C2A61264536EA8F0BN6PR16MB1425namp_-- From nobody Wed Apr 25 05:30:52 2018 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 68364124E15 for ; Wed, 25 Apr 2018 05:30:51 -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 b_jUbqz9Z1ec for ; Wed, 25 Apr 2018 05:30:49 -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 6DF83120454 for ; Wed, 25 Apr 2018 05:30:49 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.90_1) (envelope-from ) id 1fBJZO-0007Le-Ii; Wed, 25 Apr 2018 13:30:46 +0100 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , References: <006901d3dc8c$cd1e6610$675b3230$@jpshallow.com> In-Reply-To: Date: Wed, 25 Apr 2018 13:30:45 +0100 Message-ID: <008b01d3dc91$3bcaee40$b360cac0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_008C_01D3DC99.9D901990" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIEBmIuXb5DqKdyQgEJB/mUC3BNzwM7KjpEo5c7P2A= Content-Language: en-gb Archived-At: Subject: Re: [Dots] data channel and pending-lifetime 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: Wed, 25 Apr 2018 12:30:51 -0000 This is a multipart message in MIME format. ------=_NextPart_000_008C_01D3DC99.9D901990 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tiru, =20 Can we then please have some suitable text added (e.g. use PUT, and = refresh should be the same as the previous request (It could be = different if the client wants to change a parameter, but keep the same = name)) so that the next implementer does not have to deduce the = information. =20 Thanks =20 Jon =20 From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Wednesday, April 25, 2018 5:29 PM To: dots@ietf.org Subject: [Dots] data channel and pending-lifetime _____ =20 Hi there, =20 To make pending-lifetime work, the Alias / ACL needs to periodically be = refreshed by the DOTS client to make sure the entry does not go stale = and consequently get deleted by the DOTS server. =20 RESTCONF RFC 8040 4.4.1 Create Resource Mode =20 If the data resource already exists, then the POST request MUST fail and a "409 Conflict" status-line MUST be returned. The error-tag value "resource-denied" is used in this case. =20 So, we cannot really use POST to refresh the Alias / ACL unless the 409 = is to be ignored. =20 RFC 8040 4.5 PUT =20 Consistent with [RFC7231], if the PUT request creates a new resource, a "201 Created" status-line is returned. If an existing resource is modified, a "204 No Content" status-line is returned. =20 So, PUT will work. =20 In draft-ietf-dots-data-channel-15, there are no sections on describing = how Aliases / ACLS are to be refreshed other than =20 A DOTS server MUST maintain a [filtering rule|alias] for at least = 10080 minutes (1 week). If no refresh request is seen from the DOTS client, the DOTS server removes expired entries. =20 I assume that a PUT refresh request must be an exact match for the = initial request (or an echo back of the GET response with some fields = stripped out that are ro). Correct? =20 [TR] Yes. =20 -Tiru =20 Regards =20 Jon ------=_NextPart_000_008C_01D3DC99.9D901990 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

Can we then please have = some suitable text added (e.g. use PUT, and refresh should be the same = as the previous request (It could be different if the client wants to = change a parameter, but keep the same name)) so that the next = implementer does not have to deduce the = information.

 

Thanks

 

Jon

 

From: Dots = [mailto:dots-bounces@ietf.org] On Behalf Of Jon = Shallow
Sent: Wednesday, April 25, 2018 5:29 PM
To: = dots@ietf.org
Subject: [Dots] data channel and = pending-lifetime

Hi = there,

 

To make pending-lifetime work, the Alias / ACL needs = to periodically be refreshed by the DOTS client to make sure the entry = does not go stale and consequently get deleted by the DOTS = server.

 

RESTCONF RFC 8040 4.4.1 Create Resource = Mode

 

   If the data resource already exists, then = the POST request MUST fail

   and a "409 Conflict" = status-line MUST be returned.  The error-tag

   value "resource-denied" is used = in this case.

 

So, we cannot really use POST to refresh the Alias / = ACL unless the 409 is to be ignored.

 

RFC 8040 4.5 = PUT

 

   Consistent with [RFC7231], if the PUT = request creates a new resource,

   a "201 Created" status-line is = returned.  If an existing resource is

   modified, a "204 No Content" = status-line is returned.

 

So, PUT will = work.

 

In draft-ietf-dots-data-channel-15, there are no = sections on describing how Aliases / ACLS are to be refreshed other = than

 

   A DOTS server MUST maintain a [filtering = rule|alias] for at least 10080

   minutes (1 week).  If no refresh = request is seen from the DOTS

   client, the DOTS server removes expired = entries.

 

I assume that a PUT refresh request must be an exact = match for the initial request (or an echo back of the GET response with = some fields stripped out that are ro).  Correct?

 

[TR] = Yes.

 

-Tiru

 

Regards

 

Jon

------=_NextPart_000_008C_01D3DC99.9D901990-- From nobody Wed Apr 25 05:39:17 2018 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 759AA126B6E for ; Wed, 25 Apr 2018 05:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2i-VvwNBSzSp for ; Wed, 25 Apr 2018 05:39:08 -0700 (PDT) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6996312711D for ; Wed, 25 Apr 2018 05:39:08 -0700 (PDT) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 39F1BC11B3; Wed, 25 Apr 2018 14:39:07 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.42]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 11FE418008C; Wed, 25 Apr 2018 14:39:07 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM41.corporate.adroot.infra.ftgroup ([fe80::c845:f762:8997:ec86%19]) with mapi id 14.03.0389.001; Wed, 25 Apr 2018 14:39:06 +0200 From: To: Jon Shallow , "'Konda, Tirumaleswar Reddy'" , "dots@ietf.org" Thread-Topic: [Dots] data channel and pending-lifetime Thread-Index: AQIEBmIu8ckpBFbCSNuFe2wUQEInWAM7KjpEo5c7P2CAAALgMA== Date: Wed, 25 Apr 2018 12:39:06 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DF11468@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <006901d3dc8c$cd1e6610$675b3230$@jpshallow.com> <008b01d3dc91$3bcaee40$b360cac0$@jpshallow.com> In-Reply-To: <008b01d3dc91$3bcaee40$b360cac0$@jpshallow.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93302DF11468OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] data channel and pending-lifetime 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: Wed, 25 Apr 2018 12:39:17 -0000 --_000_787AE7BB302AE849A7480A190F8B93302DF11468OPEXCLILMA3corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSm9uLA0KDQpXaHkgZG8geW91IHdhbnQgdG8gcmVzdHJpY3QgdGhlIHJlZnJlc2ggdG8gdGhl IGV4YWN0IGNvbnRlbnQgb2YgdGhlIGluaXRpYWwgcmVxdWVzdD8NCg0KV2hhdCBpcyBpbXBvcnRh bnQgaXMgdGhlIG5hbWUgb2YgdGhlIGFsaWFzLCBzdWItY2xhdXNlcyBtYXkgY2hhbmdlIChlLmcu LCBwcmVmaXggY2hhbmdlKS4gV2UgZG8gYWxyZWFkeSBoYXZlIHRoaXMgdGV4dCBpbiB0aGUgZHJh ZnQ6DQoNCiAgIEEgRE9UUyBjbGllbnQgdXNlcyB0aGUgUFVUIHJlcXVlc3QgdG8gbW9kaWZ5IHRo ZSBhbGlhc2VzIGluIHRoZSBET1RTDQogICBzZXJ2ZXIuICBJbiBwYXJ0aWN1bGFyLCBhIERPVFMg Y2xpZW50IE1VU1QgdXBkYXRlIGl0cyBhbGlhcyBlbnRyaWVzDQogICB1cG9uIGNoYW5nZSBvZiB0 aGUgcHJlZml4IGluZGljYXRlZCBpbiB0aGUgJ3RhcmdldC1wcmVmaXgnLg0KDQpEaWQgSSBtaXNz ZWQgc29tZXRoaW5nPw0KDQpDaGVlcnMsDQpNZWQNCg0KRGUgOiBEb3RzIFttYWlsdG86ZG90cy1i b3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIEpvbiBTaGFsbG93DQpFbnZvecOpIDogbWVy Y3JlZGkgMjUgYXZyaWwgMjAxOCAxNDozMQ0Kw4AgOiAnS29uZGEsIFRpcnVtYWxlc3dhciBSZWRk eSc7IGRvdHNAaWV0Zi5vcmcNCk9iamV0IDogUmU6IFtEb3RzXSBkYXRhIGNoYW5uZWwgYW5kIHBl bmRpbmctbGlmZXRpbWUNCg0KSGkgVGlydSwNCg0KQ2FuIHdlIHRoZW4gcGxlYXNlIGhhdmUgc29t ZSBzdWl0YWJsZSB0ZXh0IGFkZGVkIChlLmcuIHVzZSBQVVQsIGFuZCByZWZyZXNoIHNob3VsZCBi ZSB0aGUgc2FtZSBhcyB0aGUgcHJldmlvdXMgcmVxdWVzdCAoSXQgY291bGQgYmUgZGlmZmVyZW50 IGlmIHRoZSBjbGllbnQgd2FudHMgdG8gY2hhbmdlIGEgcGFyYW1ldGVyLCBidXQga2VlcCB0aGUg c2FtZSBuYW1lKSkgc28gdGhhdCB0aGUgbmV4dCBpbXBsZW1lbnRlciBkb2VzIG5vdCBoYXZlIHRv IGRlZHVjZSB0aGUgaW5mb3JtYXRpb24uDQoNClRoYW5rcw0KDQpKb24NCg0KRnJvbTogRG90cyBb bWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEpvbiBTaGFsbG93DQpT ZW50OiBXZWRuZXNkYXksIEFwcmlsIDI1LCAyMDE4IDU6MjkgUE0NClRvOiBkb3RzQGlldGYub3Jn PG1haWx0bzpkb3RzQGlldGYub3JnPg0KU3ViamVjdDogW0RvdHNdIGRhdGEgY2hhbm5lbCBhbmQg cGVuZGluZy1saWZldGltZQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkhpIHRo ZXJlLA0KDQpUbyBtYWtlIHBlbmRpbmctbGlmZXRpbWUgd29yaywgdGhlIEFsaWFzIC8gQUNMIG5l ZWRzIHRvIHBlcmlvZGljYWxseSBiZSByZWZyZXNoZWQgYnkgdGhlIERPVFMgY2xpZW50IHRvIG1h a2Ugc3VyZSB0aGUgZW50cnkgZG9lcyBub3QgZ28gc3RhbGUgYW5kIGNvbnNlcXVlbnRseSBnZXQg ZGVsZXRlZCBieSB0aGUgRE9UUyBzZXJ2ZXIuDQoNClJFU1RDT05GIFJGQyA4MDQwIDQuNC4xIENy ZWF0ZSBSZXNvdXJjZSBNb2RlDQoNCiAgIElmIHRoZSBkYXRhIHJlc291cmNlIGFscmVhZHkgZXhp c3RzLCB0aGVuIHRoZSBQT1NUIHJlcXVlc3QgTVVTVCBmYWlsDQogICBhbmQgYSAiNDA5IENvbmZs aWN0IiBzdGF0dXMtbGluZSBNVVNUIGJlIHJldHVybmVkLiAgVGhlIGVycm9yLXRhZw0KICAgdmFs dWUgInJlc291cmNlLWRlbmllZCIgaXMgdXNlZCBpbiB0aGlzIGNhc2UuDQoNClNvLCB3ZSBjYW5u b3QgcmVhbGx5IHVzZSBQT1NUIHRvIHJlZnJlc2ggdGhlIEFsaWFzIC8gQUNMIHVubGVzcyB0aGUg NDA5IGlzIHRvIGJlIGlnbm9yZWQuDQoNClJGQyA4MDQwIDQuNSBQVVQNCg0KICAgQ29uc2lzdGVu dCB3aXRoIFtSRkM3MjMxXSwgaWYgdGhlIFBVVCByZXF1ZXN0IGNyZWF0ZXMgYSBuZXcgcmVzb3Vy Y2UsDQogICBhICIyMDEgQ3JlYXRlZCIgc3RhdHVzLWxpbmUgaXMgcmV0dXJuZWQuICBJZiBhbiBl eGlzdGluZyByZXNvdXJjZSBpcw0KICAgbW9kaWZpZWQsIGEgIjIwNCBObyBDb250ZW50IiBzdGF0 dXMtbGluZSBpcyByZXR1cm5lZC4NCg0KU28sIFBVVCB3aWxsIHdvcmsuDQoNCkluIGRyYWZ0LWll dGYtZG90cy1kYXRhLWNoYW5uZWwtMTUsIHRoZXJlIGFyZSBubyBzZWN0aW9ucyBvbiBkZXNjcmli aW5nIGhvdyBBbGlhc2VzIC8gQUNMUyBhcmUgdG8gYmUgcmVmcmVzaGVkIG90aGVyIHRoYW4NCg0K ICAgQSBET1RTIHNlcnZlciBNVVNUIG1haW50YWluIGEgW2ZpbHRlcmluZyBydWxlfGFsaWFzXSBm b3IgYXQgbGVhc3QgMTAwODANCiAgIG1pbnV0ZXMgKDEgd2VlaykuICBJZiBubyByZWZyZXNoIHJl cXVlc3QgaXMgc2VlbiBmcm9tIHRoZSBET1RTDQogICBjbGllbnQsIHRoZSBET1RTIHNlcnZlciBy ZW1vdmVzIGV4cGlyZWQgZW50cmllcy4NCg0KSSBhc3N1bWUgdGhhdCBhIFBVVCByZWZyZXNoIHJl cXVlc3QgbXVzdCBiZSBhbiBleGFjdCBtYXRjaCBmb3IgdGhlIGluaXRpYWwgcmVxdWVzdCAob3Ig YW4gZWNobyBiYWNrIG9mIHRoZSBHRVQgcmVzcG9uc2Ugd2l0aCBzb21lIGZpZWxkcyBzdHJpcHBl ZCBvdXQgdGhhdCBhcmUgcm8pLiAgQ29ycmVjdD8NCg0KW1RSXSBZZXMuDQoNCi1UaXJ1DQoNClJl Z2FyZHMNCg0KSm9uDQo= --_000_787AE7BB302AE849A7480A190F8B93302DF11468OPEXCLILMA3corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJn aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQcsOpZm9ybWF0w6kgSFRNTCBDYXIiOw0KCW1hcmdp bjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRp di5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi VGV4dGUgZGUgYnVsbGVzIENhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlm IjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJp Z2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFu LkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uVGV4dGVkZWJ1bGxlc0Nhcg0K CXttc28tc3R5bGUtbmFtZToiVGV4dGUgZGUgYnVsbGVzIENhciI7DQoJbXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJUZXh0ZSBkZSBidWxsZXMiOw0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpz cGFuLkVtYWlsU3R5bGUyNA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrOw0KCWZvbnQtd2VpZ2h0Om5vcm1h bDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQpzcGFuLlByZm9ybWF0SFRNTENhcg0KCXttc28tc3R5 bGUtbmFtZToiUHLDqWZvcm1hdMOpIEhUTUwgQ2FyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IlByw6lmb3JtYXTDqSBIVE1MIjsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw dCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJGUiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj5IaSBKb24sDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+V2h5IGRvIHlvdSB3YW50IHRvIHJlc3RyaWN0IHRoZSByZWZyZXNoIHRvIHRoZSBl eGFjdCBjb250ZW50IG9mIHRoZSBpbml0aWFsIHJlcXVlc3Q/DQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+V2hhdCBpcyBpbXBvcnRhbnQgaXMgdGhl IG5hbWUgb2YgdGhlIGFsaWFzLCBzdWItY2xhdXNlcyBtYXkgY2hhbmdlIChlLmcuLCBwcmVmaXgg Y2hhbmdlKS4gV2UgZG8gYWxyZWFkeSBoYXZlIHRoaXMgdGV4dCBpbiB0aGUgZHJhZnQ6PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlIi PiZuYnNwOyZuYnNwOyBBIERPVFMgY2xpZW50IHVzZXMgdGhlIFBVVCByZXF1ZXN0IHRvIG1vZGlm eSB0aGUgYWxpYXNlcyBpbiB0aGUgRE9UUzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpG UiI+Jm5ic3A7Jm5ic3A7IHNlcnZlci4mbmJzcDsgSW4gcGFydGljdWxhciwgYSBET1RTIGNsaWVu dCBNVVNUIHVwZGF0ZSBpdHMgYWxpYXMgZW50cmllczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Ozttc28tZmFyZWFzdC1sYW5n dWFnZTpGUiI+Jm5ic3A7Jm5ic3A7IHVwb24gY2hhbmdlIG9mIHRoZSBwcmVmaXggaW5kaWNhdGVk IGluIHRoZSAndGFyZ2V0LXByZWZpeCcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPkRpZCBJIG1pc3NlZCBzb21ldGhpbmc/PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkNoZWVycyw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPk1lZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAx LjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20g MGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpGUiI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpGUiI+IERvdHMgW21haWx0 bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5EZSBsYSBwYXJ0IGRlPC9iPiBKb24gU2hhbGxv dzxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiBtZXJjcmVkaSAyNSBhdnJpbCAyMDE4IDE0OjMx PGJyPg0KPGI+w4AmbmJzcDs6PC9iPiAnS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSc7IGRvdHNA aWV0Zi5vcmc8YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+IFJlOiBbRG90c10gZGF0YSBjaGFubmVs IGFuZCBwZW5kaW5nLWxpZmV0aW1lPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5IaSBU aXJ1LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xv cjojMUY0OTdEIj5DYW4gd2UgdGhlbiBwbGVhc2UgaGF2ZSBzb21lIHN1aXRhYmxlIHRleHQgYWRk ZWQgKGUuZy4gdXNlIFBVVCwgYW5kIHJlZnJlc2ggc2hvdWxkIGJlIHRoZSBzYW1lIGFzIHRoZSBw cmV2aW91cyByZXF1ZXN0IChJdCBjb3VsZCBiZSBkaWZmZXJlbnQgaWYgdGhlIGNsaWVudCB3YW50 cyB0byBjaGFuZ2UgYSBwYXJhbWV0ZXIsIGJ1dCBrZWVwIHRoZQ0KIHNhbWUgbmFtZSkpIHNvIHRo YXQgdGhlIG5leHQgaW1wbGVtZW50ZXIgZG9lcyBub3QgaGF2ZSB0byBkZWR1Y2UgdGhlIGluZm9y bWF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJj b2xvcjojMUY0OTdEIj5UaGFua3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Sm9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0 OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiBEb3RzIFs8YSBocmVm PSJtYWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86ZG90cy1ib3VuY2VzQGlldGYu b3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Sm9uIFNoYWxsb3c8YnI+DQo8Yj5TZW50Ojwv Yj4gV2VkbmVzZGF5LCBBcHJpbCAyNSwgMjAxOCA1OjI5IFBNPGJyPg0KPGI+VG86PC9iPiA8YSBo cmVmPSJtYWlsdG86ZG90c0BpZXRmLm9yZyI+ZG90c0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gW0RvdHNdIGRhdGEgY2hhbm5lbCBhbmQgcGVuZGluZy1saWZldGltZTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50 ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+DQo8aHIgc2l6ZT0iMyIgd2lkdGg9IjEwMCUiIGFs aWduPSJjZW50ZXIiPg0KPC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiI+SGkgdGhlcmUsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5UbyBtYWtl IHBlbmRpbmctbGlmZXRpbWUgd29yaywgdGhlIEFsaWFzIC8gQUNMIG5lZWRzIHRvIHBlcmlvZGlj YWxseSBiZSByZWZyZXNoZWQgYnkgdGhlIERPVFMgY2xpZW50IHRvIG1ha2Ugc3VyZSB0aGUgZW50 cnkgZG9lcyBub3QgZ28gc3RhbGUgYW5kIGNvbnNlcXVlbnRseSBnZXQgZGVsZXRlZCBieSB0aGUg RE9UUyBzZXJ2ZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5SRVNUQ09ORiBSRkMgODA0MCA0LjQuMSBD cmVhdGUgUmVzb3VyY2UgTW9kZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7Jm5ic3A7IElmIHRo ZSBkYXRhIHJlc291cmNlIGFscmVhZHkgZXhpc3RzLCB0aGVuIHRoZSBQT1NUIHJlcXVlc3QgTVVT VCBmYWlsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tR0IiPiZuYnNwOyZuYnNwOyBhbmQgYSAmcXVvdDs0MDkgQ29uZmxpY3QmcXVvdDsg c3RhdHVzLWxpbmUgTVVTVCBiZSByZXR1cm5lZC4mbmJzcDsgVGhlIGVycm9yLXRhZzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj4m bmJzcDsmbmJzcDsgdmFsdWUgJnF1b3Q7cmVzb3VyY2UtZGVuaWVkJnF1b3Q7IGlzIHVzZWQgaW4g dGhpcyBjYXNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+U28sIHdlIGNhbm5vdCByZWFsbHkgdXNlIFBP U1QgdG8gcmVmcmVzaCB0aGUgQWxpYXMgLyBBQ0wgdW5sZXNzIHRoZSA0MDkgaXMgdG8gYmUgaWdu b3JlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPlJGQyA4MDQwIDQuNSBQVVQ8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t R0IiPiZuYnNwOyZuYnNwOyBDb25zaXN0ZW50IHdpdGggW1JGQzcyMzFdLCBpZiB0aGUgUFVUIHJl cXVlc3QgY3JlYXRlcyBhIG5ldyByZXNvdXJjZSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7Jm5ic3A7IGEgJnF1b3Q7 MjAxIENyZWF0ZWQmcXVvdDsgc3RhdHVzLWxpbmUgaXMgcmV0dXJuZWQuJm5ic3A7IElmIGFuIGV4 aXN0aW5nIHJlc291cmNlIGlzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOyZuYnNwOyBtb2RpZmllZCwgYSAmcXVvdDsy MDQgTm8gQ29udGVudCZxdW90OyBzdGF0dXMtbGluZSBpcyByZXR1cm5lZC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiPlNvLCBQVVQgd2lsbCB3b3JrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+SW4gZHJhZnQtaWV0 Zi1kb3RzLWRhdGEtY2hhbm5lbC0xNSwgdGhlcmUgYXJlIG5vIHNlY3Rpb25zIG9uIGRlc2NyaWJp bmcgaG93IEFsaWFzZXMgLyBBQ0xTIGFyZSB0byBiZSByZWZyZXNoZWQgb3RoZXIgdGhhbjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiI+Jm5ic3A7Jm5ic3A7IEEgRE9UUyBzZXJ2ZXIgTVVTVCBtYWludGFpbiBh IFtmaWx0ZXJpbmcgcnVsZXxhbGlhc10gZm9yIGF0IGxlYXN0IDEwMDgwPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOyZu YnNwOyBtaW51dGVzICgxIHdlZWspLiZuYnNwOyBJZiBubyByZWZyZXNoIHJlcXVlc3QgaXMgc2Vl biBmcm9tIHRoZSBET1RTPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOyZuYnNwOyBjbGllbnQsIHRoZSBET1RTIHNlcnZl ciByZW1vdmVzIGV4cGlyZWQgZW50cmllcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPkkgYXNzdW1lIHRo YXQgYSBQVVQgcmVmcmVzaCByZXF1ZXN0IG11c3QgYmUgYW4gZXhhY3QgbWF0Y2ggZm9yIHRoZSBp bml0aWFsIHJlcXVlc3QgKG9yIGFuIGVjaG8gYmFjayBvZiB0aGUgR0VUIHJlc3BvbnNlIHdpdGgg c29tZSBmaWVsZHMgc3RyaXBwZWQgb3V0IHRoYXQgYXJlIHJvKS4mbmJzcDsgQ29ycmVjdD88bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiPltUUl0gWWVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+LVRpcnU8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tR0IiPlJlZ2FyZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPkpvbjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_787AE7BB302AE849A7480A190F8B93302DF11468OPEXCLILMA3corp_-- From nobody Wed Apr 25 05:50:08 2018 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 D9CA61205D3 for ; Wed, 25 Apr 2018 05:50:06 -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 V2XzDLwAvldR for ; Wed, 25 Apr 2018 05:50:00 -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 32642126BFD for ; Wed, 25 Apr 2018 05:49:58 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.90_1) (envelope-from ) id 1fBJrv-0007MU-Ds; Wed, 25 Apr 2018 13:49:55 +0100 From: "Jon Shallow" To: , "Konda, Tirumaleswar Reddy" , References: <006901d3dc8c$cd1e6610$675b3230$@jpshallow.com> <008b01d3dc91$3bcaee40$b360cac0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DF11468@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DF11468@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Wed, 25 Apr 2018 13:49:54 +0100 Message-ID: <00ad01d3dc93$e88db2a0$b9a917e0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AE_01D3DC9C.4A537A30" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIEBmIuXb5DqKdyQgEJB/mUC3BNzwM7KjpEAhQaVfgB1KEyUaN3+V6A Content-Language: en-gb Archived-At: Subject: Re: [Dots] data channel and pending-lifetime 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: Wed, 25 Apr 2018 12:50:07 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00AE_01D3DC9C.4A537A30 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Med, =20 The Alias is pretty straight forward =E2=80=93 it is a single object and = can easily be updated / replaced or just refreshed by what is in the PUT = body. =20 The ACL is much more complex. The PUT needs to be done at the ACL level = in order for pending-lifetime to get refreshed. Over time, additional = ACEs can get added to the ACL, orders of ACEs changed etc., so I just = wanted to make sure that the data in the refresh PUT actually has the = ACEs in the correct order etc. so that the refreshed ACL still has the = same intended filtering ordering. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com Sent: 25 April 2018 13:39 To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org Subject: Re: [Dots] data channel and pending-lifetime =20 Hi Jon,=20 =20 Why do you want to restrict the refresh to the exact content of the = initial request?=20 =20 What is important is the name of the alias, sub-clauses may change = (e.g., prefix change). We do already have this text in the draft: =20 A DOTS client uses the PUT request to modify the aliases in the DOTS server. In particular, a DOTS client MUST update its alias entries upon change of the prefix indicated in the 'target-prefix'. =20 Did I missed something? =20 Cheers, Med =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=C3=A9 : mercredi 25 avril 2018 14:31 =C3=80 : 'Konda, Tirumaleswar Reddy'; dots@ietf.org Objet : Re: [Dots] data channel and pending-lifetime =20 Hi Tiru, =20 Can we then please have some suitable text added (e.g. use PUT, and = refresh should be the same as the previous request (It could be = different if the client wants to change a parameter, but keep the same = name)) so that the next implementer does not have to deduce the = information. =20 Thanks =20 Jon =20 From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Wednesday, April 25, 2018 5:29 PM To: dots@ietf.org Subject: [Dots] data channel and pending-lifetime _____ =20 Hi there, =20 To make pending-lifetime work, the Alias / ACL needs to periodically be = refreshed by the DOTS client to make sure the entry does not go stale = and consequently get deleted by the DOTS server. =20 RESTCONF RFC 8040 4.4.1 Create Resource Mode =20 If the data resource already exists, then the POST request MUST fail and a "409 Conflict" status-line MUST be returned. The error-tag value "resource-denied" is used in this case. =20 So, we cannot really use POST to refresh the Alias / ACL unless the 409 = is to be ignored. =20 RFC 8040 4.5 PUT =20 Consistent with [RFC7231], if the PUT request creates a new resource, a "201 Created" status-line is returned. If an existing resource is modified, a "204 No Content" status-line is returned. =20 So, PUT will work. =20 In draft-ietf-dots-data-channel-15, there are no sections on describing = how Aliases / ACLS are to be refreshed other than =20 A DOTS server MUST maintain a [filtering rule|alias] for at least = 10080 minutes (1 week). If no refresh request is seen from the DOTS client, the DOTS server removes expired entries. =20 I assume that a PUT refresh request must be an exact match for the = initial request (or an echo back of the GET response with some fields = stripped out that are ro). Correct? =20 [TR] Yes. =20 -Tiru =20 Regards =20 Jon ------=_NextPart_000_00AE_01D3DC9C.4A537A30 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Med,

 

The Alias is pretty = straight forward =E2=80=93 it is a single object and can easily be = updated / replaced or just refreshed by what is in the PUT = body.

 

The ACL is much more = complex.=C2=A0 The PUT needs to be done at the ACL level in order for = pending-lifetime to get refreshed.=C2=A0 Over time, additional ACEs can = get added to the ACL, orders of ACEs changed etc., so I just wanted to = make sure that the data in the refresh PUT actually has the ACEs in the = correct order etc. so that the refreshed ACL still has the same intended = filtering ordering.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com
Sent: 25 April 2018 = 13:39
To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; = dots@ietf.org
Subject: Re: [Dots] data channel and = pending-lifetime

 

Hi Jon,

 

Why do you want to restrict the refresh to the exact = content of the initial request?

 

What is important is the name of the alias, = sub-clauses may change (e.g., prefix change). We do already have this = text in the draft:

 

   A DOTS client uses the PUT = request to modify the aliases in the DOTS

   server.  In particular, = a DOTS client MUST update its alias entries

   upon change of the prefix = indicated in the 'target-prefix'.

 

Did I missed something?

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de = Jon Shallow
Envoy=C3=A9 : mercredi 25 avril 2018 = 14:31
=C3=80 : 'Konda, Tirumaleswar Reddy'; = dots@ietf.org
Objet : Re: [Dots] data channel and = pending-lifetime

 

Hi = Tiru,

 

Can we then please have = some suitable text added (e.g. use PUT, and refresh should be the same = as the previous request (It could be different if the client wants to = change a parameter, but keep the same name)) so that the next = implementer does not have to deduce the = information.

 

Thanks

 

Jon

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of Jon Shallow
Sent: Wednesday, April 25, = 2018 5:29 PM
To: dots@ietf.org
Subject: = [Dots] data channel and pending-lifetime

Hi = there,

 

To make pending-lifetime work, the Alias / ACL needs = to periodically be refreshed by the DOTS client to make sure the entry = does not go stale and consequently get deleted by the DOTS = server.

 

RESTCONF RFC 8040 4.4.1 Create Resource = Mode

 

   If the data resource already exists, then = the POST request MUST fail

   and a "409 Conflict" = status-line MUST be returned.  The error-tag

   value "resource-denied" is used = in this case.

 

So, we cannot really use POST to refresh the Alias / = ACL unless the 409 is to be ignored.

 

RFC 8040 4.5 = PUT

 

   Consistent with [RFC7231], if the PUT = request creates a new resource,

   a "201 Created" status-line is = returned.  If an existing resource is

   modified, a "204 No Content" = status-line is returned.

 

So, PUT will = work.

 

In draft-ietf-dots-data-channel-15, there are no = sections on describing how Aliases / ACLS are to be refreshed other = than

 

   A DOTS server MUST maintain a [filtering = rule|alias] for at least 10080

   minutes (1 week).  If no refresh = request is seen from the DOTS

   client, the DOTS server removes expired = entries.

 

I assume that a PUT refresh request must be an exact = match for the initial request (or an echo back of the GET response with = some fields stripped out that are ro).  Correct?

 

[TR] = Yes.

 

-Tiru

 

Regards

 

Jon

------=_NextPart_000_00AE_01D3DC9C.4A537A30-- From nobody Wed Apr 25 06:02:03 2018 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 46BB5126C3D for ; Wed, 25 Apr 2018 06:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HuRwUcWpVY6j for ; Wed, 25 Apr 2018 06:02:00 -0700 (PDT) Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 912281205D3 for ; Wed, 25 Apr 2018 06:01:59 -0700 (PDT) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 3A79620978; Wed, 25 Apr 2018 15:01:58 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.58]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 163671A007E; Wed, 25 Apr 2018 15:01:58 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM33.corporate.adroot.infra.ftgroup ([fe80::3881:fc15:b4b2:9017%19]) with mapi id 14.03.0389.001; Wed, 25 Apr 2018 15:01:57 +0200 From: To: Jon Shallow , "Konda, Tirumaleswar Reddy" , "dots@ietf.org" Thread-Topic: [Dots] data channel and pending-lifetime Thread-Index: AQIEBmIu8ckpBFbCSNuFe2wUQEInWAM7KjpEAhQaVfgB1KEyUaN3+V6AgAADsTA= Date: Wed, 25 Apr 2018 13:01:57 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DF114E8@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <006901d3dc8c$cd1e6610$675b3230$@jpshallow.com> <008b01d3dc91$3bcaee40$b360cac0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DF11468@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <00ad01d3dc93$e88db2a0$b9a917e0$@jpshallow.com> In-Reply-To: <00ad01d3dc93$e88db2a0$b9a917e0$@jpshallow.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93302DF114E8OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] data channel and pending-lifetime 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: Wed, 25 Apr 2018 13:02:02 -0000 --_000_787AE7BB302AE849A7480A190F8B93302DF114E8OPEXCLILMA3corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmUtLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCkRlIDogSm9uIFNo YWxsb3cgW21haWx0bzpzdXBqcHMtaWV0ZkBqcHNoYWxsb3cuY29tXQ0KRW52b3nDqSA6IG1lcmNy ZWRpIDI1IGF2cmlsIDIwMTggMTQ6NTANCsOAIDogQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTjsg S29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeTsgZG90c0BpZXRmLm9yZw0KT2JqZXQgOiBSRTogW0Rv dHNdIGRhdGEgY2hhbm5lbCBhbmQgcGVuZGluZy1saWZldGltZQ0KDQpIaSBNZWQsDQoNClRoZSBB bGlhcyBpcyBwcmV0dHkgc3RyYWlnaHQgZm9yd2FyZCDigJMgaXQgaXMgYSBzaW5nbGUgb2JqZWN0 IGFuZCBjYW4gZWFzaWx5IGJlIHVwZGF0ZWQgLyByZXBsYWNlZCBvciBqdXN0IHJlZnJlc2hlZCBi eSB3aGF0IGlzIGluIHRoZSBQVVQgYm9keS4NCltNZWRdIEFncmVlLiBJIGRvbuKAmXQgdGhpbmsg YSBjaGFuZ2UgaXMgbmVlZGVkIHRvIHRoZSBjdXJyZW50IHRleHQuDQoNClRoZSBBQ0wgaXMgbXVj aCBtb3JlIGNvbXBsZXguICBUaGUgUFVUIG5lZWRzIHRvIGJlIGRvbmUgYXQgdGhlIEFDTCBsZXZl bCBpbiBvcmRlciBmb3IgcGVuZGluZy1saWZldGltZSB0byBnZXQgcmVmcmVzaGVkLiAgT3ZlciB0 aW1lLCBhZGRpdGlvbmFsIEFDRXMgY2FuIGdldCBhZGRlZCB0byB0aGUgQUNMLCBvcmRlcnMgb2Yg QUNFcyBjaGFuZ2VkIGV0Yy4sIHNvIEkganVzdCB3YW50ZWQgdG8gbWFrZSBzdXJlIHRoYXQgdGhl IGRhdGEgaW4gdGhlIHJlZnJlc2ggUFVUIGFjdHVhbGx5IGhhcyB0aGUgQUNFcyBpbiB0aGUgY29y cmVjdCBvcmRlciBldGMuIHNvIHRoYXQgdGhlIHJlZnJlc2hlZCBBQ0wgc3RpbGwgaGFzIHRoZSBz YW1lIGludGVuZGVkIGZpbHRlcmluZyBvcmRlcmluZy4NCg0KW01lZF0gV291bGQgaXQgYmUgYmV0 dGVyIGlmIHdlIG1ha2UgdGhpcyBjaGFuZ2U6DQoNCk9MRDoNCiAgIEEgRE9UUyBzZXJ2ZXIgTVVT VCBtYWludGFpbiBhIGZpbHRlcmluZyBydWxlIGZvciBhdCBsZWFzdCAxMDA4MA0KICAgbWludXRl cyAoMSB3ZWVrKS4gIElmIG5vIHJlZnJlc2ggcmVxdWVzdCBpcyBzZWVuIGZyb20gdGhlIERPVFMN CiAgIGNsaWVudCwgdGhlIERPVFMgc2VydmVyIHJlbW92ZXMgZXhwaXJlZCBlbnRyaWVzLg0KDQpO RVc6DQogICBBIERPVFMgc2VydmVyIE1VU1QgbWFpbnRhaW4gYSBmaWx0ZXJpbmcgcnVsZSBmb3Ig YXQgbGVhc3QgMTAwODANCiAgIG1pbnV0ZXMgKDEgd2VlaykuICBJZiBubyByZWZyZXNoIHJlcXVl c3QgaXMgc2VlbiBmcm9tIHRoZSBET1RTDQogICBjbGllbnQsIHRoZSBET1RTIHNlcnZlciByZW1v dmVzIGV4cGlyZWQgZW50cmllcy4gVHlwaWNhbGx5LCBhIHJlZnJlc2gNCiAgIHJlcXVlc3QgaXMg YSBQVVQgcmVxdWVzdCB3aGljaCBlY2hvZXMgdGhlIGNvbnRlbnQgYSByZXNwb25zZSB0byBhIEdF VA0KDQogICByZXF1ZXN0IChleGNlcHQgdGhlIHBlbmRpbmctbGlmZXRpbWUpLg0KDQoNClJlZ2Fy ZHMNCg0KSm9uDQoNCkZyb206IERvdHMgW21haWx0bzogZG90cy1ib3VuY2VzQGlldGYub3JnPG1h aWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgbW9oYW1lZC5ib3VjYWRh aXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4NClNlbnQ6 IDI1IEFwcmlsIDIwMTggMTM6MzkNClRvOiBKb24gU2hhbGxvdzsgJ0tvbmRhLCBUaXJ1bWFsZXN3 YXIgUmVkZHknOyBkb3RzQGlldGYub3JnPG1haWx0bzpkb3RzQGlldGYub3JnPg0KU3ViamVjdDog UmU6IFtEb3RzXSBkYXRhIGNoYW5uZWwgYW5kIHBlbmRpbmctbGlmZXRpbWUNCg0KSGkgSm9uLA0K DQpXaHkgZG8geW91IHdhbnQgdG8gcmVzdHJpY3QgdGhlIHJlZnJlc2ggdG8gdGhlIGV4YWN0IGNv bnRlbnQgb2YgdGhlIGluaXRpYWwgcmVxdWVzdD8NCg0KV2hhdCBpcyBpbXBvcnRhbnQgaXMgdGhl IG5hbWUgb2YgdGhlIGFsaWFzLCBzdWItY2xhdXNlcyBtYXkgY2hhbmdlIChlLmcuLCBwcmVmaXgg Y2hhbmdlKS4gV2UgZG8gYWxyZWFkeSBoYXZlIHRoaXMgdGV4dCBpbiB0aGUgZHJhZnQ6DQoNCiAg IEEgRE9UUyBjbGllbnQgdXNlcyB0aGUgUFVUIHJlcXVlc3QgdG8gbW9kaWZ5IHRoZSBhbGlhc2Vz IGluIHRoZSBET1RTDQogICBzZXJ2ZXIuICBJbiBwYXJ0aWN1bGFyLCBhIERPVFMgY2xpZW50IE1V U1QgdXBkYXRlIGl0cyBhbGlhcyBlbnRyaWVzDQogICB1cG9uIGNoYW5nZSBvZiB0aGUgcHJlZml4 IGluZGljYXRlZCBpbiB0aGUgJ3RhcmdldC1wcmVmaXgnLg0KDQpEaWQgSSBtaXNzZWQgc29tZXRo aW5nPw0KDQpDaGVlcnMsDQpNZWQNCg0KRGUgOiBEb3RzIFttYWlsdG86ZG90cy1ib3VuY2VzQGll dGYub3JnXSBEZSBsYSBwYXJ0IGRlIEpvbiBTaGFsbG93DQpFbnZvecOpIDogbWVyY3JlZGkgMjUg YXZyaWwgMjAxOCAxNDozMQ0Kw4AgOiAnS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSc7IGRvdHNA aWV0Zi5vcmc8bWFpbHRvOmRvdHNAaWV0Zi5vcmc+DQpPYmpldCA6IFJlOiBbRG90c10gZGF0YSBj aGFubmVsIGFuZCBwZW5kaW5nLWxpZmV0aW1lDQoNCkhpIFRpcnUsDQoNCkNhbiB3ZSB0aGVuIHBs ZWFzZSBoYXZlIHNvbWUgc3VpdGFibGUgdGV4dCBhZGRlZCAoZS5nLiB1c2UgUFVULCBhbmQgcmVm cmVzaCBzaG91bGQgYmUgdGhlIHNhbWUgYXMgdGhlIHByZXZpb3VzIHJlcXVlc3QgKEl0IGNvdWxk IGJlIGRpZmZlcmVudCBpZiB0aGUgY2xpZW50IHdhbnRzIHRvIGNoYW5nZSBhIHBhcmFtZXRlciwg YnV0IGtlZXAgdGhlIHNhbWUgbmFtZSkpIHNvIHRoYXQgdGhlIG5leHQgaW1wbGVtZW50ZXIgZG9l cyBub3QgaGF2ZSB0byBkZWR1Y2UgdGhlIGluZm9ybWF0aW9uLg0KDQpUaGFua3MNCg0KSm9uDQoN CkZyb206IERvdHMgW21haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBK b24gU2hhbGxvdw0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCAyNSwgMjAxOCA1OjI5IFBNDQpUbzog ZG90c0BpZXRmLm9yZzxtYWlsdG86ZG90c0BpZXRmLm9yZz4NClN1YmplY3Q6IFtEb3RzXSBkYXRh IGNoYW5uZWwgYW5kIHBlbmRpbmctbGlmZXRpbWUNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpIaSB0aGVyZSwNCg0KVG8gbWFrZSBwZW5kaW5nLWxpZmV0aW1lIHdvcmssIHRoZSBB bGlhcyAvIEFDTCBuZWVkcyB0byBwZXJpb2RpY2FsbHkgYmUgcmVmcmVzaGVkIGJ5IHRoZSBET1RT IGNsaWVudCB0byBtYWtlIHN1cmUgdGhlIGVudHJ5IGRvZXMgbm90IGdvIHN0YWxlIGFuZCBjb25z ZXF1ZW50bHkgZ2V0IGRlbGV0ZWQgYnkgdGhlIERPVFMgc2VydmVyLg0KDQpSRVNUQ09ORiBSRkMg ODA0MCA0LjQuMSBDcmVhdGUgUmVzb3VyY2UgTW9kZQ0KDQogICBJZiB0aGUgZGF0YSByZXNvdXJj ZSBhbHJlYWR5IGV4aXN0cywgdGhlbiB0aGUgUE9TVCByZXF1ZXN0IE1VU1QgZmFpbA0KICAgYW5k IGEgIjQwOSBDb25mbGljdCIgc3RhdHVzLWxpbmUgTVVTVCBiZSByZXR1cm5lZC4gIFRoZSBlcnJv ci10YWcNCiAgIHZhbHVlICJyZXNvdXJjZS1kZW5pZWQiIGlzIHVzZWQgaW4gdGhpcyBjYXNlLg0K DQpTbywgd2UgY2Fubm90IHJlYWxseSB1c2UgUE9TVCB0byByZWZyZXNoIHRoZSBBbGlhcyAvIEFD TCB1bmxlc3MgdGhlIDQwOSBpcyB0byBiZSBpZ25vcmVkLg0KDQpSRkMgODA0MCA0LjUgUFVUDQoN CiAgIENvbnNpc3RlbnQgd2l0aCBbUkZDNzIzMV0sIGlmIHRoZSBQVVQgcmVxdWVzdCBjcmVhdGVz IGEgbmV3IHJlc291cmNlLA0KICAgYSAiMjAxIENyZWF0ZWQiIHN0YXR1cy1saW5lIGlzIHJldHVy bmVkLiAgSWYgYW4gZXhpc3RpbmcgcmVzb3VyY2UgaXMNCiAgIG1vZGlmaWVkLCBhICIyMDQgTm8g Q29udGVudCIgc3RhdHVzLWxpbmUgaXMgcmV0dXJuZWQuDQoNClNvLCBQVVQgd2lsbCB3b3JrLg0K DQpJbiBkcmFmdC1pZXRmLWRvdHMtZGF0YS1jaGFubmVsLTE1LCB0aGVyZSBhcmUgbm8gc2VjdGlv bnMgb24gZGVzY3JpYmluZyBob3cgQWxpYXNlcyAvIEFDTFMgYXJlIHRvIGJlIHJlZnJlc2hlZCBv dGhlciB0aGFuDQoNCiAgIEEgRE9UUyBzZXJ2ZXIgTVVTVCBtYWludGFpbiBhIFtmaWx0ZXJpbmcg cnVsZXxhbGlhc10gZm9yIGF0IGxlYXN0IDEwMDgwDQogICBtaW51dGVzICgxIHdlZWspLiAgSWYg bm8gcmVmcmVzaCByZXF1ZXN0IGlzIHNlZW4gZnJvbSB0aGUgRE9UUw0KICAgY2xpZW50LCB0aGUg RE9UUyBzZXJ2ZXIgcmVtb3ZlcyBleHBpcmVkIGVudHJpZXMuDQoNCkkgYXNzdW1lIHRoYXQgYSBQ VVQgcmVmcmVzaCByZXF1ZXN0IG11c3QgYmUgYW4gZXhhY3QgbWF0Y2ggZm9yIHRoZSBpbml0aWFs IHJlcXVlc3QgKG9yIGFuIGVjaG8gYmFjayBvZiB0aGUgR0VUIHJlc3BvbnNlIHdpdGggc29tZSBm aWVsZHMgc3RyaXBwZWQgb3V0IHRoYXQgYXJlIHJvKS4gIENvcnJlY3Q/DQoNCltUUl0gWWVzLg0K DQotVGlydQ0KDQpSZWdhcmRzDQoNCkpvbg0K --_000_787AE7BB302AE849A7480A190F8B93302DF114E8OPEXCLILMA3corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5v c2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnByZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlByw6lmb3JtYXTDqSBIVE1M IENhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1z b0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJUZXh0 ZSBkZSBidWxsZXMgQ2FyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0Kc3Bhbi5QcmZvcm1hdEhUTUxDYXINCgl7 bXNvLXN0eWxlLW5hbWU6IlByw6lmb3JtYXTDqSBIVE1MIENhciI7DQoJbXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQcsOpZm9ybWF0w6kgSFRNTCI7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLlRleHRlZGVidWxsZXNDYXINCgl7bXNvLXN0eWxlLW5h bWU6IlRleHRlIGRlIGJ1bGxlcyBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiVGV4dGUgZGUgYnVsbGVzIjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KcC5tc29ub3JtYWwwLCBs aS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1h cmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxl ZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjt9DQpwLkhUTUxQcmVmb3JtYXR0ZWQsIGxpLkhUTUxQcmVmb3JtYXR0ZWQsIGRpdi5I VE1MUHJlZm9ybWF0dGVkDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJ bXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpz cGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1h dHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU TUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgltc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUzt9DQpwLkJhbGxvb25UZXh0LCBsaS5CYWxsb29uVGV4dCwgZGl2LkJhbGxv b25UZXh0DQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQiOw0KCW1zby1zdHlsZS1saW5r OiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCnNwYW4uQmFsbG9vblRleHRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJU YWhvbWEiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpzcGFu LkVtYWlsU3R5bGUyNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMjgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTI5DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUzMA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNr Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQpzcGFuLkVtYWls U3R5bGUzMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzINCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 IjsNCgljb2xvcjpibGFjazsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3Jt YWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4w cHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZSIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+UmUtLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+UGxlYXNlIHNlZSBpbmxpbmUuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+TWVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41 cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBj bSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlIiPkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlIiPiBKb24gU2hhbGxvdyBb bWFpbHRvOnN1cGpwcy1pZXRmQGpwc2hhbGxvdy5jb21dDQo8YnI+DQo8Yj5FbnZvecOpJm5ic3A7 OjwvYj4gbWVyY3JlZGkgMjUgYXZyaWwgMjAxOCAxNDo1MDxicj4NCjxiPsOAJm5ic3A7OjwvYj4g Qk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTjsgS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeTsgZG90 c0BpZXRmLm9yZzxicj4NCjxiPk9iamV0Jm5ic3A7OjwvYj4gUkU6IFtEb3RzXSBkYXRhIGNoYW5u ZWwgYW5kIHBlbmRpbmctbGlmZXRpbWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkhp IE1lZCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+VGhlIEFsaWFzIGlzIHByZXR0eSBzdHJhaWdodCBmb3J3YXJkIOKAkyBpdCBp cyBhIHNpbmdsZSBvYmplY3QgYW5kIGNhbiBlYXNpbHkgYmUgdXBkYXRlZCAvIHJlcGxhY2VkIG9y IGp1c3QgcmVmcmVzaGVkIGJ5IHdoYXQgaXMgaW4gdGhlIFBVVCBib2R5LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+W01lZF0gQWdyZWUuIEkgZG9u4oCZdCB0aGluayBhIGNoYW5nZSBpcyBuZWVkZWQg dG8gdGhlIGN1cnJlbnQgdGV4dC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5UaGUgQUNMIGlzIG11Y2ggbW9yZSBjb21wbGV4 LiZuYnNwOyBUaGUgUFVUIG5lZWRzIHRvIGJlIGRvbmUgYXQgdGhlIEFDTCBsZXZlbCBpbiBvcmRl ciBmb3IgcGVuZGluZy1saWZldGltZSB0byBnZXQgcmVmcmVzaGVkLiZuYnNwOyBPdmVyIHRpbWUs IGFkZGl0aW9uYWwgQUNFcyBjYW4gZ2V0IGFkZGVkIHRvIHRoZSBBQ0wsIG9yZGVycyBvZiBBQ0Vz IGNoYW5nZWQNCiBldGMuLCBzbyBJIGp1c3Qgd2FudGVkIHRvIG1ha2Ugc3VyZSB0aGF0IHRoZSBk YXRhIGluIHRoZSByZWZyZXNoIFBVVCBhY3R1YWxseSBoYXMgdGhlIEFDRXMgaW4gdGhlIGNvcnJl Y3Qgb3JkZXIgZXRjLiBzbyB0aGF0IHRoZSByZWZyZXNoZWQgQUNMIHN0aWxsIGhhcyB0aGUgc2Ft ZSBpbnRlbmRlZCBmaWx0ZXJpbmcgb3JkZXJpbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPltNZWRdIFdvdWxkIGl0IGJlIGJldHRlciBpZiB3ZSBt YWtlIHRoaXMgY2hhbmdlOg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6YmxhY2siPk9MRDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlIiPiZuYnNw OyZuYnNwOyBBIERPVFMgc2VydmVyIE1VU1QgbWFpbnRhaW4gYSBmaWx0ZXJpbmcgcnVsZSBmb3Ig YXQgbGVhc3QgMTAwODA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlIiPiZuYnNwOyZu YnNwOyBtaW51dGVzICgxIHdlZWspLiZuYnNwOyBJZiBubyByZWZyZXNoIHJlcXVlc3QgaXMgc2Vl biBmcm9tIHRoZSBET1RTPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOkZSIj4mbmJzcDsm bmJzcDsgY2xpZW50LCB0aGUgRE9UUyBzZXJ2ZXIgcmVtb3ZlcyBleHBpcmVkIGVudHJpZXMuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPk5FVzo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlIiPiZuYnNwOyZuYnNwOyBBIERPVFMgc2VydmVy IE1VU1QgbWFpbnRhaW4gYSBmaWx0ZXJpbmcgcnVsZSBmb3IgYXQgbGVhc3QgMTAwODA8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlIiPiZuYnNwOyZuYnNwOyBtaW51dGVzICgxIHdlZWsp LiZuYnNwOyBJZiBubyByZWZyZXNoIHJlcXVlc3QgaXMgc2VlbiBmcm9tIHRoZSBET1RTPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOkZSIj4mbmJzcDsmbmJzcDsgY2xpZW50LCB0aGUgRE9U UyBzZXJ2ZXIgcmVtb3ZlcyBleHBpcmVkIGVudHJpZXMuIFR5cGljYWxseSwgYSByZWZyZXNoPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOkZSIj4mbmJzcDsgJm5ic3A7cmVxdWVzdCBpcyBh IFBVVCByZXF1ZXN0IHdoaWNoIGVjaG9lcyB0aGUgY29udGVudCBhIHJlc3BvbnNlIHRvIGEgR0VU PG86cD48L286cD48L3NwYW4+PC9wPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RlIiPiZuYnNwOyZuYnNwOyByZXF1ZXN0IChleGNlcHQgdGhlIHBlbmRp bmctbGlmZXRpbWUpLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpGUiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOkZSIj4mbmJzcDsmbmJzcDsNCjwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+UmVnYXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5Kb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNt IDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tR0IiPiBEb3RzIFttYWlsdG86DQo8YSBocmVmPSJtYWlsdG86ZG90cy1ib3VuY2Vz QGlldGYub3JnIj5kb3RzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSA8Yj5PbiBCZWhhbGYgT2YNCjwv Yj48YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+bW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbTwvYT48YnI+DQo8Yj5TZW50OjwvYj4gMjUgQXByaWwgMjAxOCAx MzozOTxicj4NCjxiPlRvOjwvYj4gSm9uIFNoYWxsb3c7ICdLb25kYSwgVGlydW1hbGVzd2FyIFJl ZGR5JzsgPGEgaHJlZj0ibWFpbHRvOmRvdHNAaWV0Zi5vcmciPg0KZG90c0BpZXRmLm9yZzwvYT48 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtEb3RzXSBkYXRhIGNoYW5uZWwgYW5kIHBlbmRpbmct bGlmZXRpbWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj ayI+SGkgSm9uLA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 YmxhY2siPldoeSBkbyB5b3Ugd2FudCB0byByZXN0cmljdCB0aGUgcmVmcmVzaCB0byB0aGUgZXhh Y3QgY29udGVudCBvZiB0aGUgaW5pdGlhbCByZXF1ZXN0Pw0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPldoYXQgaXMgaW1wb3J0YW50IGlzIHRoZSBu YW1lIG9mIHRoZSBhbGlhcywgc3ViLWNsYXVzZXMgbWF5IGNoYW5nZSAoZS5nLiwgcHJlZml4IGNo YW5nZSkuIFdlIGRvIGFscmVhZHkgaGF2ZSB0aGlzIHRleHQgaW4gdGhlIGRyYWZ0OjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOkZSIj4m bmJzcDsmbmJzcDsgQSBET1RTIGNsaWVudCB1c2VzIHRoZSBQVVQgcmVxdWVzdCB0byBtb2RpZnkg dGhlIGFsaWFzZXMgaW4gdGhlIERPVFM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlIi PiZuYnNwOyZuYnNwOyBzZXJ2ZXIuJm5ic3A7IEluIHBhcnRpY3VsYXIsIGEgRE9UUyBjbGllbnQg TVVTVCB1cGRhdGUgaXRzIGFsaWFzIGVudHJpZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RlIiPiZuYnNwOyZuYnNwOyB1cG9uIGNoYW5nZSBvZiB0aGUgcHJlZml4IGluZGljYXRlZCBp biB0aGUgJ3RhcmdldC1wcmVmaXgnLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj5EaWQgSSBtaXNzZWQgc29tZXRoaW5nPzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5DaGVlcnMsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj5NZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41 cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBj bSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlIiPkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlIiPiBEb3RzIFs8YSBocmVm PSJtYWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86ZG90cy1ib3VuY2VzQGlldGYu b3JnPC9hPl0NCjxiPkRlIGxhIHBhcnQgZGU8L2I+IEpvbiBTaGFsbG93PGJyPg0KPGI+RW52b3nD qSZuYnNwOzo8L2I+IG1lcmNyZWRpIDI1IGF2cmlsIDIwMTggMTQ6MzE8YnI+DQo8Yj7DgCZuYnNw Ozo8L2I+ICdLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5JzsgPGEgaHJlZj0ibWFpbHRvOmRvdHNA aWV0Zi5vcmciPmRvdHNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBSZTog W0RvdHNdIGRhdGEgY2hhbm5lbCBhbmQgcGVuZGluZy1saWZldGltZTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+SGkgVGlydSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Q2FuIHdlIHRoZW4gcGxlYXNlIGhhdmUgc29t ZSBzdWl0YWJsZSB0ZXh0IGFkZGVkIChlLmcuIHVzZSBQVVQsIGFuZCByZWZyZXNoIHNob3VsZCBi ZSB0aGUgc2FtZSBhcyB0aGUgcHJldmlvdXMgcmVxdWVzdCAoSXQgY291bGQgYmUgZGlmZmVyZW50 IGlmIHRoZSBjbGllbnQgd2FudHMgdG8gY2hhbmdlIGEgcGFyYW1ldGVyLCBidXQga2VlcCB0aGUN CiBzYW1lIG5hbWUpKSBzbyB0aGF0IHRoZSBuZXh0IGltcGxlbWVudGVyIGRvZXMgbm90IGhhdmUg dG8gZGVkdWNlIHRoZSBpbmZvcm1hdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhhbmtzPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkpvbjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iY29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkZyb206PC9z cGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpI LUNOIj4gRG90cyBbPGEgaHJlZj0ibWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRv OmRvdHMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkpvbiBTaGFs bG93PGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgQXByaWwgMjUsIDIwMTggNToyOSBQTTxi cj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmRvdHNAaWV0Zi5vcmciPmRvdHNAaWV0Zi5v cmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtEb3RzXSBkYXRhIGNoYW5uZWwgYW5kIHBlbmRp bmctbGlmZXRpbWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iTXNv Tm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPg0KPGhyIHNpemU9 IjMiIHdpZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVyIj4NCjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPkhpIHRoZXJlLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiI+VG8gbWFrZSBwZW5kaW5nLWxpZmV0aW1lIHdvcmssIHRoZSBBbGlhcyAvIEFD TCBuZWVkcyB0byBwZXJpb2RpY2FsbHkgYmUgcmVmcmVzaGVkIGJ5IHRoZSBET1RTIGNsaWVudCB0 byBtYWtlIHN1cmUgdGhlIGVudHJ5IGRvZXMgbm90IGdvIHN0YWxlIGFuZCBjb25zZXF1ZW50bHkg Z2V0IGRlbGV0ZWQgYnkgdGhlIERPVFMgc2VydmVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+UkVTVENP TkYgUkZDIDgwNDAgNC40LjEgQ3JlYXRlIFJlc291cmNlIE1vZGU8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii PiZuYnNwOyZuYnNwOyBJZiB0aGUgZGF0YSByZXNvdXJjZSBhbHJlYWR5IGV4aXN0cywgdGhlbiB0 aGUgUE9TVCByZXF1ZXN0IE1VU1QgZmFpbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDsmbmJzcDsgYW5kIGEgJnF1b3Q7 NDA5IENvbmZsaWN0JnF1b3Q7IHN0YXR1cy1saW5lIE1VU1QgYmUgcmV0dXJuZWQuJm5ic3A7IFRo ZSBlcnJvci10YWc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7Jm5ic3A7IHZhbHVlICZxdW90O3Jlc291cmNlLWRlbmll ZCZxdW90OyBpcyB1c2VkIGluIHRoaXMgY2FzZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPlNvLCB3ZSBj YW5ub3QgcmVhbGx5IHVzZSBQT1NUIHRvIHJlZnJlc2ggdGhlIEFsaWFzIC8gQUNMIHVubGVzcyB0 aGUgNDA5IGlzIHRvIGJlIGlnbm9yZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5SRkMgODA0MCA0LjUg UFVUPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDsmbmJzcDsgQ29uc2lzdGVudCB3aXRoIFtSRkM3 MjMxXSwgaWYgdGhlIFBVVCByZXF1ZXN0IGNyZWF0ZXMgYSBuZXcgcmVzb3VyY2UsPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPiZu YnNwOyZuYnNwOyBhICZxdW90OzIwMSBDcmVhdGVkJnF1b3Q7IHN0YXR1cy1saW5lIGlzIHJldHVy bmVkLiZuYnNwOyBJZiBhbiBleGlzdGluZyByZXNvdXJjZSBpczxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDsmbmJzcDsg bW9kaWZpZWQsIGEgJnF1b3Q7MjA0IE5vIENvbnRlbnQmcXVvdDsgc3RhdHVzLWxpbmUgaXMgcmV0 dXJuZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5TbywgUFVUIHdpbGwgd29yay48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiPkluIGRyYWZ0LWlldGYtZG90cy1kYXRhLWNoYW5uZWwtMTUsIHRoZXJlIGFyZSBubyBz ZWN0aW9ucyBvbiBkZXNjcmliaW5nIGhvdyBBbGlhc2VzIC8gQUNMUyBhcmUgdG8gYmUgcmVmcmVz aGVkIG90aGVyIHRoYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOyZuYnNwOyBBIERPVFMgc2Vy dmVyIE1VU1QgbWFpbnRhaW4gYSBbZmlsdGVyaW5nIHJ1bGV8YWxpYXNdIGZvciBhdCBsZWFzdCAx MDA4MDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIj4mbmJzcDsmbmJzcDsgbWludXRlcyAoMSB3ZWVrKS4mbmJzcDsgSWYgbm8gcmVm cmVzaCByZXF1ZXN0IGlzIHNlZW4gZnJvbSB0aGUgRE9UUzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDsmbmJzcDsgY2xp ZW50LCB0aGUgRE9UUyBzZXJ2ZXIgcmVtb3ZlcyBleHBpcmVkIGVudHJpZXMuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIj5JIGFzc3VtZSB0aGF0IGEgUFVUIHJlZnJlc2ggcmVxdWVzdCBtdXN0IGJlIGFuIGV4 YWN0IG1hdGNoIGZvciB0aGUgaW5pdGlhbCByZXF1ZXN0IChvciBhbiBlY2hvIGJhY2sgb2YgdGhl IEdFVCByZXNwb25zZSB3aXRoIHNvbWUgZmllbGRzIHN0cmlwcGVkIG91dCB0aGF0IGFyZSBybyku Jm5ic3A7IENvcnJlY3Q/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5bVFJdIFllcy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiPi1UaXJ1PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5SZWdhcmRzPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC Ij5Kb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_787AE7BB302AE849A7480A190F8B93302DF114E8OPEXCLILMA3corp_-- From nobody Wed Apr 25 06:13:38 2018 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 AB1341275F4 for ; Wed, 25 Apr 2018 06:13:36 -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 gQeYiv4UcHWH for ; Wed, 25 Apr 2018 06:13:35 -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 C5A45127241 for ; Wed, 25 Apr 2018 06:13:34 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.90_1) (envelope-from ) id 1fBKEm-0007O0-0F; Wed, 25 Apr 2018 14:13:32 +0100 From: "Jon Shallow" To: , "Konda, Tirumaleswar Reddy" , References: <006901d3dc8c$cd1e6610$675b3230$@jpshallow.com> <008b01d3dc91$3bcaee40$b360cac0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DF11468@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <00ad01d3dc93$e88db2a0$b9a917e0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DF114E8@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DF114E8@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Wed, 25 Apr 2018 14:13:30 +0100 Message-ID: <00df01d3dc97$34e45cf0$9ead16d0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E0_01D3DC9F.96AB8410" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIEBmIuXb5DqKdyQgEJB/mUC3BNzwM7KjpEAhQaVfgB1KEyUQH9hv1BASuogZijXrbksA== Content-Language: en-gb Archived-At: Subject: Re: [Dots] data channel and pending-lifetime 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: Wed, 25 Apr 2018 13:13:37 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00E0_01D3DC9F.96AB8410 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Med, =20 See inline [Jon] =20 Regards =20 Jon =20 =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=C3=A9 : mercredi 25 avril 2018 14:50 =C3=80 : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; = dots@ietf.org Objet : RE: [Dots] data channel and pending-lifetime =20 Hi Med, =20 The Alias is pretty straight forward =E2=80=93 it is a single object and = can easily be updated / replaced or just refreshed by what is in the PUT = body. [Med] Agree. I don=E2=80=99t think a change is needed to the current = text.=20 [Jon] I think the text could be updated (by adding =E2=80=98or = refresh=E2=80=99) to A DOTS client uses the PUT request to modify or refresh the aliases = in the DOTS server. In particular, a DOTS client MUST update its alias entries upon change of the prefix indicated in the 'target-prefix'. =20 =20 The ACL is much more complex. The PUT needs to be done at the ACL level = in order for pending-lifetime to get refreshed. Over time, additional = ACEs can get added to the ACL, orders of ACEs changed etc., so I just = wanted to make sure that the data in the refresh PUT actually has the = ACEs in the correct order etc. so that the refreshed ACL still has the = same intended filtering ordering. =20 [Med] Would it be better if we make this change:=20 =20 OLD: A DOTS server MUST maintain a filtering rule for at least 10080 minutes (1 week). If no refresh request is seen from the DOTS client, the DOTS server removes expired entries. =20 NEW: A DOTS server MUST maintain a filtering rule for at least 10080 minutes (1 week). If no refresh request is seen from the DOTS client, the DOTS server removes expired entries. Typically, a refresh request is a PUT request which echoes the content a response to a GET request (except the pending-lifetime).=20 =20 [Jon] A GET will return other ro entries =E2=80=93 such as statistics = (matched-packets etc.), all of which need to get stripped out. A better = version would be =20 NEW: A DOTS server MUST maintain a filtering rule for at least 10080 minutes (1 week). If no refresh request is seen from the DOTS client, the DOTS server removes expired entries. Typically, a refresh request is a PUT request which echoes the content of a response to a = GET request with all of the read-only parameters stripped out(e.g. = pending-lifetime).=20 =20 =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com Sent: 25 April 2018 13:39 To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org Subject: Re: [Dots] data channel and pending-lifetime =20 Hi Jon,=20 =20 Why do you want to restrict the refresh to the exact content of the = initial request?=20 =20 What is important is the name of the alias, sub-clauses may change = (e.g., prefix change). We do already have this text in the draft: =20 A DOTS client uses the PUT request to modify the aliases in the DOTS server. In particular, a DOTS client MUST update its alias entries upon change of the prefix indicated in the 'target-prefix'. =20 Did I missed something? =20 Cheers, Med =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=C3=A9 : mercredi 25 avril 2018 14:31 =C3=80 : 'Konda, Tirumaleswar Reddy'; dots@ietf.org Objet : Re: [Dots] data channel and pending-lifetime =20 Hi Tiru, =20 Can we then please have some suitable text added (e.g. use PUT, and = refresh should be the same as the previous request (It could be = different if the client wants to change a parameter, but keep the same = name)) so that the next implementer does not have to deduce the = information. =20 Thanks =20 Jon =20 From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Wednesday, April 25, 2018 5:29 PM To: dots@ietf.org Subject: [Dots] data channel and pending-lifetime _____ =20 Hi there, =20 To make pending-lifetime work, the Alias / ACL needs to periodically be = refreshed by the DOTS client to make sure the entry does not go stale = and consequently get deleted by the DOTS server. =20 RESTCONF RFC 8040 4.4.1 Create Resource Mode =20 If the data resource already exists, then the POST request MUST fail and a "409 Conflict" status-line MUST be returned. The error-tag value "resource-denied" is used in this case. =20 So, we cannot really use POST to refresh the Alias / ACL unless the 409 = is to be ignored. =20 RFC 8040 4.5 PUT =20 Consistent with [RFC7231], if the PUT request creates a new resource, a "201 Created" status-line is returned. If an existing resource is modified, a "204 No Content" status-line is returned. =20 So, PUT will work. =20 In draft-ietf-dots-data-channel-15, there are no sections on describing = how Aliases / ACLS are to be refreshed other than =20 A DOTS server MUST maintain a [filtering rule|alias] for at least = 10080 minutes (1 week). If no refresh request is seen from the DOTS client, the DOTS server removes expired entries. =20 I assume that a PUT refresh request must be an exact match for the = initial request (or an echo back of the GET response with some fields = stripped out that are ro). Correct? =20 [TR] Yes. =20 -Tiru =20 Regards =20 Jon ------=_NextPart_000_00E0_01D3DC9F.96AB8410 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Med,

 

See inline = [Jon]

 

Regards

 

Jon

 

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] =
Envoy=C3=A9 : mercredi 25 avril 2018 = 14:50
=C3=80 : BOUCADAIR Mohamed IMT/OLN; Konda, = Tirumaleswar Reddy; dots@ietf.org
Objet : RE: [Dots] data = channel and pending-lifetime

 

Hi = Med,

 

The Alias is pretty = straight forward =E2=80=93 it is a single object and can easily be = updated / replaced or just refreshed by what is in the PUT = body.

[Med] = Agree. I don=E2=80=99t think a change is needed to the current text. =

[Jon] I think the text could be updated (by = adding =E2=80=98or refresh=E2=80=99) to

   A DOTS client uses the PUT = request to modify or refresh the aliases in the = DOTS

   server.  In particular, = a DOTS client MUST update its alias entries

   upon change of the prefix = indicated in the 'target-prefix'.

 

 

The ACL is much more = complex.  The PUT needs to be done at the ACL level in order for = pending-lifetime to get refreshed.  Over time, additional ACEs can = get added to the ACL, orders of ACEs changed etc., so I just wanted to = make sure that the data in the refresh PUT actually has the ACEs in the = correct order etc. so that the refreshed ACL still has the same intended = filtering ordering.

 

[Med] = Would it be better if we make this change:

 

OLD:

   A DOTS server MUST maintain a = filtering rule for at least 10080

   minutes (1 week).  If no = refresh request is seen from the DOTS

   client, the DOTS server = removes expired entries.

 

NEW:

   A DOTS server MUST maintain a = filtering rule for at least 10080

   minutes (1 week).  If no = refresh request is seen from the DOTS

   client, the DOTS server = removes expired entries. Typically, a refresh

   request is a PUT request = which echoes the content a response to a = GET

   request (except the =
pending-lifetime).

 

<= p class=3DMsoNormal>[Jon] A GET will return = other ro entries =E2=80=93 such as statistics (matched-packets etc.), = all of which need to get stripped out.=C2=A0 A better version would = be

 <= /p>

NEW:

   A DOTS server MUST maintain a = filtering rule for at least 10080

   minutes (1 week).  If no = refresh request is seen from the DOTS

   client, the DOTS server = removes expired entries. Typically, a refresh

   request is a PUT request = which echoes the content of a response to a = GET

   request with all of the =
read-only parameters stripped out(e.g. pending-lifetime). =

 <= /p>

  

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of mohamed.boucadair@orange.com=
Sent: 25 April 2018 13:39
To: Jon Shallow; = 'Konda, Tirumaleswar Reddy'; dots@ietf.org
Subject: Re: = [Dots] data channel and = pending-lifetime

 

Hi Jon,

 

Why do you want to restrict the refresh to the exact = content of the initial request?

 

What is important is the name of the alias, = sub-clauses may change (e.g., prefix change). We do already have this = text in the draft:

 

   A DOTS client uses the PUT = request to modify the aliases in the DOTS

   server.  In particular, = a DOTS client MUST update its alias entries

   upon change of the prefix = indicated in the 'target-prefix'.

 

Did I missed something?

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] = De la part de Jon Shallow
Envoy=C3=A9 : mercredi = 25 avril 2018 14:31
=C3=80 : 'Konda, Tirumaleswar Reddy'; = dots@ietf.org
Objet : = Re: [Dots] data channel and = pending-lifetime

 

Hi = Tiru,

 

Can we then please have = some suitable text added (e.g. use PUT, and refresh should be the same = as the previous request (It could be different if the client wants to = change a parameter, but keep the same name)) so that the next = implementer does not have to deduce the = information.

 

Thanks

 

Jon

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of Jon Shallow
Sent: Wednesday, April 25, = 2018 5:29 PM
To: dots@ietf.org
Subject: = [Dots] data channel and pending-lifetime

Hi = there,

 

To make pending-lifetime work, the Alias / ACL needs = to periodically be refreshed by the DOTS client to make sure the entry = does not go stale and consequently get deleted by the DOTS = server.

 

RESTCONF RFC 8040 4.4.1 Create Resource = Mode

 

   If the data resource already exists, then = the POST request MUST fail

   and a "409 Conflict" = status-line MUST be returned.  The error-tag

   value "resource-denied" is used = in this case.

 

So, we cannot really use POST to refresh the Alias / = ACL unless the 409 is to be ignored.

 

RFC 8040 4.5 = PUT

 

   Consistent with [RFC7231], if the PUT = request creates a new resource,

   a "201 Created" status-line is = returned.  If an existing resource is

   modified, a "204 No Content" = status-line is returned.

 

So, PUT will = work.

 

In draft-ietf-dots-data-channel-15, there are no = sections on describing how Aliases / ACLS are to be refreshed other = than

 

   A DOTS server MUST maintain a [filtering = rule|alias] for at least 10080

   minutes (1 week).  If no refresh = request is seen from the DOTS

   client, the DOTS server removes expired = entries.

 

I assume that a PUT refresh request must be an exact = match for the initial request (or an echo back of the GET response with = some fields stripped out that are ro).  Correct?

 

[TR] = Yes.

 

-Tiru

 

Regards

 

Jon

------=_NextPart_000_00E0_01D3DC9F.96AB8410-- From nobody Wed Apr 25 06:16:16 2018 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 0BAD31241FC for ; Wed, 25 Apr 2018 06:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PwbKzS3TjnZa for ; Wed, 25 Apr 2018 06:16:12 -0700 (PDT) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 988931205D3 for ; Wed, 25 Apr 2018 06:16:11 -0700 (PDT) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 252A8160677; Wed, 25 Apr 2018 15:16:10 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.42]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id E7C67C0077; Wed, 25 Apr 2018 15:16:09 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM41.corporate.adroot.infra.ftgroup ([fe80::c845:f762:8997:ec86%19]) with mapi id 14.03.0389.001; Wed, 25 Apr 2018 15:16:09 +0200 From: To: Jon Shallow , "Konda, Tirumaleswar Reddy" , "dots@ietf.org" Thread-Topic: [Dots] data channel and pending-lifetime Thread-Index: AQIEBmIu8ckpBFbCSNuFe2wUQEInWAM7KjpEAhQaVfgB1KEyUQH9hv1BASuogZijXrbksIAAApHQ Date: Wed, 25 Apr 2018 13:16:09 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DF11542@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <006901d3dc8c$cd1e6610$675b3230$@jpshallow.com> <008b01d3dc91$3bcaee40$b360cac0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DF11468@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <00ad01d3dc93$e88db2a0$b9a917e0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DF114E8@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <00df01d3dc97$34e45cf0$9ead16d0$@jpshallow.com> In-Reply-To: <00df01d3dc97$34e45cf0$9ead16d0$@jpshallow.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93302DF11542OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] data channel and pending-lifetime 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: Wed, 25 Apr 2018 13:16:14 -0000 --_000_787AE7BB302AE849A7480A190F8B93302DF11542OPEXCLILMA3corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmUtLA0KDQpXb3JrcyBmb3IgbWUuIFRoYW5rcy4NCg0KQ2hlZXJzLA0KTWVkDQoNCkRlIDogSm9u IFNoYWxsb3cgW21haWx0bzpzdXBqcHMtaWV0ZkBqcHNoYWxsb3cuY29tXQ0KRW52b3nDqSA6IG1l cmNyZWRpIDI1IGF2cmlsIDIwMTggMTU6MTQNCsOAIDogQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09M TjsgS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeTsgZG90c0BpZXRmLm9yZw0KT2JqZXQgOiBSRTog W0RvdHNdIGRhdGEgY2hhbm5lbCBhbmQgcGVuZGluZy1saWZldGltZQ0KDQpIaSBNZWQsDQoNClNl ZSBpbmxpbmUgW0pvbl0NCg0KUmVnYXJkcw0KDQpKb24NCg0KDQpEZSA6IEpvbiBTaGFsbG93IFtt YWlsdG86c3VwanBzLWlldGZAanBzaGFsbG93LmNvbV0NCkVudm95w6kgOiBtZXJjcmVkaSAyNSBh dnJpbCAyMDE4IDE0OjUwDQrDgCA6IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE47IEtvbmRhLCBU aXJ1bWFsZXN3YXIgUmVkZHk7IGRvdHNAaWV0Zi5vcmc8bWFpbHRvOmRvdHNAaWV0Zi5vcmc+DQpP YmpldCA6IFJFOiBbRG90c10gZGF0YSBjaGFubmVsIGFuZCBwZW5kaW5nLWxpZmV0aW1lDQoNCkhp IE1lZCwNCg0KVGhlIEFsaWFzIGlzIHByZXR0eSBzdHJhaWdodCBmb3J3YXJkIOKAkyBpdCBpcyBh IHNpbmdsZSBvYmplY3QgYW5kIGNhbiBlYXNpbHkgYmUgdXBkYXRlZCAvIHJlcGxhY2VkIG9yIGp1 c3QgcmVmcmVzaGVkIGJ5IHdoYXQgaXMgaW4gdGhlIFBVVCBib2R5Lg0KW01lZF0gQWdyZWUuIEkg ZG9u4oCZdCB0aGluayBhIGNoYW5nZSBpcyBuZWVkZWQgdG8gdGhlIGN1cnJlbnQgdGV4dC4NCltK b25dIEkgdGhpbmsgdGhlIHRleHQgY291bGQgYmUgdXBkYXRlZCAoYnkgYWRkaW5nIOKAmG9yIHJl ZnJlc2jigJkpIHRvDQogICBBIERPVFMgY2xpZW50IHVzZXMgdGhlIFBVVCByZXF1ZXN0IHRvIG1v ZGlmeSBvciByZWZyZXNoIHRoZSBhbGlhc2VzIGluIHRoZSBET1RTDQogICBzZXJ2ZXIuICBJbiBw YXJ0aWN1bGFyLCBhIERPVFMgY2xpZW50IE1VU1QgdXBkYXRlIGl0cyBhbGlhcyBlbnRyaWVzDQog ICB1cG9uIGNoYW5nZSBvZiB0aGUgcHJlZml4IGluZGljYXRlZCBpbiB0aGUgJ3RhcmdldC1wcmVm aXgnLg0KDQoNClRoZSBBQ0wgaXMgbXVjaCBtb3JlIGNvbXBsZXguICBUaGUgUFVUIG5lZWRzIHRv IGJlIGRvbmUgYXQgdGhlIEFDTCBsZXZlbCBpbiBvcmRlciBmb3IgcGVuZGluZy1saWZldGltZSB0 byBnZXQgcmVmcmVzaGVkLiAgT3ZlciB0aW1lLCBhZGRpdGlvbmFsIEFDRXMgY2FuIGdldCBhZGRl ZCB0byB0aGUgQUNMLCBvcmRlcnMgb2YgQUNFcyBjaGFuZ2VkIGV0Yy4sIHNvIEkganVzdCB3YW50 ZWQgdG8gbWFrZSBzdXJlIHRoYXQgdGhlIGRhdGEgaW4gdGhlIHJlZnJlc2ggUFVUIGFjdHVhbGx5 IGhhcyB0aGUgQUNFcyBpbiB0aGUgY29ycmVjdCBvcmRlciBldGMuIHNvIHRoYXQgdGhlIHJlZnJl c2hlZCBBQ0wgc3RpbGwgaGFzIHRoZSBzYW1lIGludGVuZGVkIGZpbHRlcmluZyBvcmRlcmluZy4N Cg0KW01lZF0gV291bGQgaXQgYmUgYmV0dGVyIGlmIHdlIG1ha2UgdGhpcyBjaGFuZ2U6DQoNCk9M RDoNCiAgIEEgRE9UUyBzZXJ2ZXIgTVVTVCBtYWludGFpbiBhIGZpbHRlcmluZyBydWxlIGZvciBh dCBsZWFzdCAxMDA4MA0KICAgbWludXRlcyAoMSB3ZWVrKS4gIElmIG5vIHJlZnJlc2ggcmVxdWVz dCBpcyBzZWVuIGZyb20gdGhlIERPVFMNCiAgIGNsaWVudCwgdGhlIERPVFMgc2VydmVyIHJlbW92 ZXMgZXhwaXJlZCBlbnRyaWVzLg0KDQpORVc6DQogICBBIERPVFMgc2VydmVyIE1VU1QgbWFpbnRh aW4gYSBmaWx0ZXJpbmcgcnVsZSBmb3IgYXQgbGVhc3QgMTAwODANCiAgIG1pbnV0ZXMgKDEgd2Vl aykuICBJZiBubyByZWZyZXNoIHJlcXVlc3QgaXMgc2VlbiBmcm9tIHRoZSBET1RTDQogICBjbGll bnQsIHRoZSBET1RTIHNlcnZlciByZW1vdmVzIGV4cGlyZWQgZW50cmllcy4gVHlwaWNhbGx5LCBh IHJlZnJlc2gNCiAgIHJlcXVlc3QgaXMgYSBQVVQgcmVxdWVzdCB3aGljaCBlY2hvZXMgdGhlIGNv bnRlbnQgYSByZXNwb25zZSB0byBhIEdFVA0KDQogICByZXF1ZXN0IChleGNlcHQgdGhlIHBlbmRp bmctbGlmZXRpbWUpLg0KDQpbSm9uXSBBIEdFVCB3aWxsIHJldHVybiBvdGhlciBybyBlbnRyaWVz IOKAkyBzdWNoIGFzIHN0YXRpc3RpY3MgKG1hdGNoZWQtcGFja2V0cyBldGMuKSwgYWxsIG9mIHdo aWNoIG5lZWQgdG8gZ2V0IHN0cmlwcGVkIG91dC4gIEEgYmV0dGVyIHZlcnNpb24gd291bGQgYmUN Cg0KTkVXOg0KICAgQSBET1RTIHNlcnZlciBNVVNUIG1haW50YWluIGEgZmlsdGVyaW5nIHJ1bGUg Zm9yIGF0IGxlYXN0IDEwMDgwDQogICBtaW51dGVzICgxIHdlZWspLiAgSWYgbm8gcmVmcmVzaCBy ZXF1ZXN0IGlzIHNlZW4gZnJvbSB0aGUgRE9UUw0KICAgY2xpZW50LCB0aGUgRE9UUyBzZXJ2ZXIg cmVtb3ZlcyBleHBpcmVkIGVudHJpZXMuIFR5cGljYWxseSwgYSByZWZyZXNoDQogICByZXF1ZXN0 IGlzIGEgUFVUIHJlcXVlc3Qgd2hpY2ggZWNob2VzIHRoZSBjb250ZW50IG9mIGEgcmVzcG9uc2Ug dG8gYSBHRVQNCg0KICAgcmVxdWVzdCB3aXRoIGFsbCBvZiB0aGUgcmVhZC1vbmx5IHBhcmFtZXRl cnMgc3RyaXBwZWQgb3V0KGUuZy4gcGVuZGluZy1saWZldGltZSkuDQoNCg0KUmVnYXJkcw0KDQpK b24NCg0KRnJvbTogRG90cyBbbWFpbHRvOiBkb3RzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmRv dHMtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBtb2hhbWVkLmJvdWNhZGFpckBvcmFu Z2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPg0KU2VudDogMjUgQXBy aWwgMjAxOCAxMzozOQ0KVG86IEpvbiBTaGFsbG93OyAnS29uZGEsIFRpcnVtYWxlc3dhciBSZWRk eSc7IGRvdHNAaWV0Zi5vcmc8bWFpbHRvOmRvdHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0Rv dHNdIGRhdGEgY2hhbm5lbCBhbmQgcGVuZGluZy1saWZldGltZQ0KDQpIaSBKb24sDQoNCldoeSBk byB5b3Ugd2FudCB0byByZXN0cmljdCB0aGUgcmVmcmVzaCB0byB0aGUgZXhhY3QgY29udGVudCBv ZiB0aGUgaW5pdGlhbCByZXF1ZXN0Pw0KDQpXaGF0IGlzIGltcG9ydGFudCBpcyB0aGUgbmFtZSBv ZiB0aGUgYWxpYXMsIHN1Yi1jbGF1c2VzIG1heSBjaGFuZ2UgKGUuZy4sIHByZWZpeCBjaGFuZ2Up LiBXZSBkbyBhbHJlYWR5IGhhdmUgdGhpcyB0ZXh0IGluIHRoZSBkcmFmdDoNCg0KICAgQSBET1RT IGNsaWVudCB1c2VzIHRoZSBQVVQgcmVxdWVzdCB0byBtb2RpZnkgdGhlIGFsaWFzZXMgaW4gdGhl IERPVFMNCiAgIHNlcnZlci4gIEluIHBhcnRpY3VsYXIsIGEgRE9UUyBjbGllbnQgTVVTVCB1cGRh dGUgaXRzIGFsaWFzIGVudHJpZXMNCiAgIHVwb24gY2hhbmdlIG9mIHRoZSBwcmVmaXggaW5kaWNh dGVkIGluIHRoZSAndGFyZ2V0LXByZWZpeCcuDQoNCkRpZCBJIG1pc3NlZCBzb21ldGhpbmc/DQoN CkNoZWVycywNCk1lZA0KDQpEZSA6IERvdHMgW21haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmdd IERlIGxhIHBhcnQgZGUgSm9uIFNoYWxsb3cNCkVudm95w6kgOiBtZXJjcmVkaSAyNSBhdnJpbCAy MDE4IDE0OjMxDQrDgCA6ICdLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5JzsgZG90c0BpZXRmLm9y ZzxtYWlsdG86ZG90c0BpZXRmLm9yZz4NCk9iamV0IDogUmU6IFtEb3RzXSBkYXRhIGNoYW5uZWwg YW5kIHBlbmRpbmctbGlmZXRpbWUNCg0KSGkgVGlydSwNCg0KQ2FuIHdlIHRoZW4gcGxlYXNlIGhh dmUgc29tZSBzdWl0YWJsZSB0ZXh0IGFkZGVkIChlLmcuIHVzZSBQVVQsIGFuZCByZWZyZXNoIHNo b3VsZCBiZSB0aGUgc2FtZSBhcyB0aGUgcHJldmlvdXMgcmVxdWVzdCAoSXQgY291bGQgYmUgZGlm ZmVyZW50IGlmIHRoZSBjbGllbnQgd2FudHMgdG8gY2hhbmdlIGEgcGFyYW1ldGVyLCBidXQga2Vl cCB0aGUgc2FtZSBuYW1lKSkgc28gdGhhdCB0aGUgbmV4dCBpbXBsZW1lbnRlciBkb2VzIG5vdCBo YXZlIHRvIGRlZHVjZSB0aGUgaW5mb3JtYXRpb24uDQoNClRoYW5rcw0KDQpKb24NCg0KRnJvbTog RG90cyBbbWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEpvbiBTaGFs bG93DQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDI1LCAyMDE4IDU6MjkgUE0NClRvOiBkb3RzQGll dGYub3JnPG1haWx0bzpkb3RzQGlldGYub3JnPg0KU3ViamVjdDogW0RvdHNdIGRhdGEgY2hhbm5l bCBhbmQgcGVuZGluZy1saWZldGltZQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CkhpIHRoZXJlLA0KDQpUbyBtYWtlIHBlbmRpbmctbGlmZXRpbWUgd29yaywgdGhlIEFsaWFzIC8g QUNMIG5lZWRzIHRvIHBlcmlvZGljYWxseSBiZSByZWZyZXNoZWQgYnkgdGhlIERPVFMgY2xpZW50 IHRvIG1ha2Ugc3VyZSB0aGUgZW50cnkgZG9lcyBub3QgZ28gc3RhbGUgYW5kIGNvbnNlcXVlbnRs eSBnZXQgZGVsZXRlZCBieSB0aGUgRE9UUyBzZXJ2ZXIuDQoNClJFU1RDT05GIFJGQyA4MDQwIDQu NC4xIENyZWF0ZSBSZXNvdXJjZSBNb2RlDQoNCiAgIElmIHRoZSBkYXRhIHJlc291cmNlIGFscmVh ZHkgZXhpc3RzLCB0aGVuIHRoZSBQT1NUIHJlcXVlc3QgTVVTVCBmYWlsDQogICBhbmQgYSAiNDA5 IENvbmZsaWN0IiBzdGF0dXMtbGluZSBNVVNUIGJlIHJldHVybmVkLiAgVGhlIGVycm9yLXRhZw0K ICAgdmFsdWUgInJlc291cmNlLWRlbmllZCIgaXMgdXNlZCBpbiB0aGlzIGNhc2UuDQoNClNvLCB3 ZSBjYW5ub3QgcmVhbGx5IHVzZSBQT1NUIHRvIHJlZnJlc2ggdGhlIEFsaWFzIC8gQUNMIHVubGVz cyB0aGUgNDA5IGlzIHRvIGJlIGlnbm9yZWQuDQoNClJGQyA4MDQwIDQuNSBQVVQNCg0KICAgQ29u c2lzdGVudCB3aXRoIFtSRkM3MjMxXSwgaWYgdGhlIFBVVCByZXF1ZXN0IGNyZWF0ZXMgYSBuZXcg cmVzb3VyY2UsDQogICBhICIyMDEgQ3JlYXRlZCIgc3RhdHVzLWxpbmUgaXMgcmV0dXJuZWQuICBJ ZiBhbiBleGlzdGluZyByZXNvdXJjZSBpcw0KICAgbW9kaWZpZWQsIGEgIjIwNCBObyBDb250ZW50 IiBzdGF0dXMtbGluZSBpcyByZXR1cm5lZC4NCg0KU28sIFBVVCB3aWxsIHdvcmsuDQoNCkluIGRy YWZ0LWlldGYtZG90cy1kYXRhLWNoYW5uZWwtMTUsIHRoZXJlIGFyZSBubyBzZWN0aW9ucyBvbiBk ZXNjcmliaW5nIGhvdyBBbGlhc2VzIC8gQUNMUyBhcmUgdG8gYmUgcmVmcmVzaGVkIG90aGVyIHRo YW4NCg0KICAgQSBET1RTIHNlcnZlciBNVVNUIG1haW50YWluIGEgW2ZpbHRlcmluZyBydWxlfGFs aWFzXSBmb3IgYXQgbGVhc3QgMTAwODANCiAgIG1pbnV0ZXMgKDEgd2VlaykuICBJZiBubyByZWZy ZXNoIHJlcXVlc3QgaXMgc2VlbiBmcm9tIHRoZSBET1RTDQogICBjbGllbnQsIHRoZSBET1RTIHNl cnZlciByZW1vdmVzIGV4cGlyZWQgZW50cmllcy4NCg0KSSBhc3N1bWUgdGhhdCBhIFBVVCByZWZy ZXNoIHJlcXVlc3QgbXVzdCBiZSBhbiBleGFjdCBtYXRjaCBmb3IgdGhlIGluaXRpYWwgcmVxdWVz dCAob3IgYW4gZWNobyBiYWNrIG9mIHRoZSBHRVQgcmVzcG9uc2Ugd2l0aCBzb21lIGZpZWxkcyBz dHJpcHBlZCBvdXQgdGhhdCBhcmUgcm8pLiAgQ29ycmVjdD8NCg0KW1RSXSBZZXMuDQoNCi1UaXJ1 DQoNClJlZ2FyZHMNCg0KSm9uDQo= --_000_787AE7BB302AE849A7480A190F8B93302DF11542OPEXCLILMA3corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5v c2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnByZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlByw6lmb3JtYXTDqSBIVE1M IENhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1z b0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJUZXh0 ZSBkZSBidWxsZXMgQ2FyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0Kc3Bhbi5QcmZvcm1hdEhUTUxDYXINCgl7 bXNvLXN0eWxlLW5hbWU6IlByw6lmb3JtYXTDqSBIVE1MIENhciI7DQoJbXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQcsOpZm9ybWF0w6kgSFRNTCI7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLlRleHRlZGVidWxsZXNDYXINCgl7bXNvLXN0eWxlLW5h bWU6IlRleHRlIGRlIGJ1bGxlcyBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiVGV4dGUgZGUgYnVsbGVzIjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KcC5tc29ub3JtYWwwLCBs aS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1h cmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxl ZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjt9DQpwLkhUTUxQcmVmb3JtYXR0ZWQsIGxpLkhUTUxQcmVmb3JtYXR0ZWQsIGRpdi5I VE1MUHJlZm9ybWF0dGVkDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJ bXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpz cGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1h dHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU TUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgltc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUzt9DQpwLkJhbGxvb25UZXh0LCBsaS5CYWxsb29uVGV4dCwgZGl2LkJhbGxv b25UZXh0DQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQiOw0KCW1zby1zdHlsZS1saW5r OiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCnNwYW4uQmFsbG9vblRleHRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJU YWhvbWEiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpzcGFu LkVtYWlsU3R5bGUyNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMjgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTI5DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUzMA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNr Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQpzcGFuLkVtYWls U3R5bGUzMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzINCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglj b2xvcjpibGFjazsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0K c3Bhbi5FbWFpbFN0eWxlMzMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxT dHlsZTM0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQt c3R5bGU6bm9ybWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEy LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJGUiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPlJlLSw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPldvcmtzIGZvciBtZS4gVGhhbmtzLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5NZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz LjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpGUiI+RGUmbmJzcDs6PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpGUiI+IEpv biBTaGFsbG93IFttYWlsdG86c3VwanBzLWlldGZAanBzaGFsbG93LmNvbV0NCjxicj4NCjxiPkVu dm95w6kmbmJzcDs6PC9iPiBtZXJjcmVkaSAyNSBhdnJpbCAyMDE4IDE1OjE0PGJyPg0KPGI+w4Am bmJzcDs6PC9iPiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xOOyBLb25kYSwgVGlydW1hbGVzd2Fy IFJlZGR5OyBkb3RzQGlldGYub3JnPGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBSRTogW0RvdHNd IGRhdGEgY2hhbm5lbCBhbmQgcGVuZGluZy1saWZldGltZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+SGkgTWVkLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJjb2xvcjojMUY0OTdEIj5TZWUgaW5saW5lIFtKb25dPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlJlZ2FyZHM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+Sm9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpGUiI+RGUmbmJzcDs6PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpG UiI+IEpvbiBTaGFsbG93IFs8YSBocmVmPSJtYWlsdG86c3VwanBzLWlldGZAanBzaGFsbG93LmNv bSI+bWFpbHRvOnN1cGpwcy1pZXRmQGpwc2hhbGxvdy5jb208L2E+XQ0KPGJyPg0KPGI+RW52b3nD qSZuYnNwOzo8L2I+IG1lcmNyZWRpIDI1IGF2cmlsIDIwMTggMTQ6NTA8YnI+DQo8Yj7DgCZuYnNw Ozo8L2I+IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE47IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVk ZHk7IDxhIGhyZWY9Im1haWx0bzpkb3RzQGlldGYub3JnIj4NCmRvdHNAaWV0Zi5vcmc8L2E+PGJy Pg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBSRTogW0RvdHNdIGRhdGEgY2hhbm5lbCBhbmQgcGVuZGlu Zy1saWZldGltZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SGkgTWVkLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5U aGUgQWxpYXMgaXMgcHJldHR5IHN0cmFpZ2h0IGZvcndhcmQg4oCTIGl0IGlzIGEgc2luZ2xlIG9i amVjdCBhbmQgY2FuIGVhc2lseSBiZSB1cGRhdGVkIC8gcmVwbGFjZWQgb3IganVzdCByZWZyZXNo ZWQgYnkgd2hhdCBpcyBpbiB0aGUgUFVUIGJvZHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5bTWVk XSBBZ3JlZS4gSSBkb27igJl0IHRoaW5rIGEgY2hhbmdlIGlzIG5lZWRlZCB0byB0aGUgY3VycmVu dCB0ZXh0Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5bSm9uXSBJIHRoaW5rIHRoZSB0 ZXh0IGNvdWxkIGJlIHVwZGF0ZWQgKGJ5IGFkZGluZyDigJhvciByZWZyZXNo4oCZKSB0bzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpGUiI+Jm5ic3A7Jm5ic3A7IEEgRE9UUyBjbGllbnQg dXNlcyB0aGUgUFVUIHJlcXVlc3QgdG8gbW9kaWZ5IG9yIHJlZnJlc2ggdGhlIGFsaWFzZXMgaW4g dGhlIERPVFM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlIiPiZuYnNwOyZuYnNwOyBz ZXJ2ZXIuJm5ic3A7IEluIHBhcnRpY3VsYXIsIGEgRE9UUyBjbGllbnQgTVVTVCB1cGRhdGUgaXRz IGFsaWFzIGVudHJpZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlIiPiZuYnNwOyZu YnNwOyB1cG9uIGNoYW5nZSBvZiB0aGUgcHJlZml4IGluZGljYXRlZCBpbiB0aGUgJ3RhcmdldC1w cmVmaXgnLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlRoZSBBQ0wg aXMgbXVjaCBtb3JlIGNvbXBsZXguJm5ic3A7IFRoZSBQVVQgbmVlZHMgdG8gYmUgZG9uZSBhdCB0 aGUgQUNMIGxldmVsIGluIG9yZGVyIGZvciBwZW5kaW5nLWxpZmV0aW1lIHRvIGdldCByZWZyZXNo ZWQuJm5ic3A7IE92ZXIgdGltZSwgYWRkaXRpb25hbCBBQ0VzIGNhbiBnZXQgYWRkZWQgdG8gdGhl IEFDTCwgb3JkZXJzIG9mIEFDRXMgY2hhbmdlZA0KIGV0Yy4sIHNvIEkganVzdCB3YW50ZWQgdG8g bWFrZSBzdXJlIHRoYXQgdGhlIGRhdGEgaW4gdGhlIHJlZnJlc2ggUFVUIGFjdHVhbGx5IGhhcyB0 aGUgQUNFcyBpbiB0aGUgY29ycmVjdCBvcmRlciBldGMuIHNvIHRoYXQgdGhlIHJlZnJlc2hlZCBB Q0wgc3RpbGwgaGFzIHRoZSBzYW1lIGludGVuZGVkIGZpbHRlcmluZyBvcmRlcmluZy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+W01lZF0gV291bGQg aXQgYmUgYmV0dGVyIGlmIHdlIG1ha2UgdGhpcyBjaGFuZ2U6DQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+T0xEOjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Ozttc28tZmFyZWFz dC1sYW5ndWFnZTpGUiI+Jm5ic3A7Jm5ic3A7IEEgRE9UUyBzZXJ2ZXIgTVVTVCBtYWludGFpbiBh IGZpbHRlcmluZyBydWxlIGZvciBhdCBsZWFzdCAxMDA4MDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Ozttc28tZmFyZWFzdC1s YW5ndWFnZTpGUiI+Jm5ic3A7Jm5ic3A7IG1pbnV0ZXMgKDEgd2VlaykuJm5ic3A7IElmIG5vIHJl ZnJlc2ggcmVxdWVzdCBpcyBzZWVuIGZyb20gdGhlIERPVFM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RlIiPiZuYnNwOyZuYnNwOyBjbGllbnQsIHRoZSBET1RTIHNlcnZlciByZW1vdmVz IGV4cGlyZWQgZW50cmllcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+TkVXOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpGUiI+Jm5ic3A7 Jm5ic3A7IEEgRE9UUyBzZXJ2ZXIgTVVTVCBtYWludGFpbiBhIGZpbHRlcmluZyBydWxlIGZvciBh dCBsZWFzdCAxMDA4MDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpGUiI+Jm5ic3A7Jm5i c3A7IG1pbnV0ZXMgKDEgd2VlaykuJm5ic3A7IElmIG5vIHJlZnJlc2ggcmVxdWVzdCBpcyBzZWVu IGZyb20gdGhlIERPVFM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlIiPiZuYnNwOyZu YnNwOyBjbGllbnQsIHRoZSBET1RTIHNlcnZlciByZW1vdmVzIGV4cGlyZWQgZW50cmllcy4gVHlw aWNhbGx5LCBhIHJlZnJlc2g8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlIiPiZuYnNw OyAmbmJzcDtyZXF1ZXN0IGlzIGEgUFVUIHJlcXVlc3Qgd2hpY2ggZWNob2VzIHRoZSBjb250ZW50 IGEgcmVzcG9uc2UgdG8gYSBHRVQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpGUiI+Jm5ic3A7Jm5ic3A7IHJlcXVl c3QgKGV4Y2VwdCB0aGUgcGVuZGluZy1saWZldGltZSkuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5 N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFG NDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpGUiI+W0pvbl0gQSBHRVQgd2lsbCByZXR1cm4gb3Ro ZXIgcm8gZW50cmllcyDigJMgc3VjaCBhcyBzdGF0aXN0aWNzIChtYXRjaGVkLXBhY2tldHMgZXRj LiksIGFsbCBvZiB3aGljaCBuZWVkIHRvIGdldCBzdHJpcHBlZCBvdXQuJm5ic3A7IEEgYmV0dGVy IHZlcnNpb24gd291bGQgYmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+TkVXOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztt c28tZmFyZWFzdC1sYW5ndWFnZTpGUiI+Jm5ic3A7Jm5ic3A7IEEgRE9UUyBzZXJ2ZXIgTVVTVCBt YWludGFpbiBhIGZpbHRlcmluZyBydWxlIGZvciBhdCBsZWFzdCAxMDA4MDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Ozttc28t ZmFyZWFzdC1sYW5ndWFnZTpGUiI+Jm5ic3A7Jm5ic3A7IG1pbnV0ZXMgKDEgd2VlaykuJm5ic3A7 IElmIG5vIHJlZnJlc2ggcmVxdWVzdCBpcyBzZWVuIGZyb20gdGhlIERPVFM8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RlIiPiZuYnNwOyZuYnNwOyBjbGllbnQsIHRoZSBET1RTIHNlcnZl ciByZW1vdmVzIGV4cGlyZWQgZW50cmllcy4gVHlwaWNhbGx5LCBhIHJlZnJlc2g8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlIiPiZuYnNwOyAmbmJzcDtyZXF1ZXN0IGlzIGEgUFVUIHJl cXVlc3Qgd2hpY2ggZWNob2VzIHRoZSBjb250ZW50DQo8Yj5vZjwvYj4gYSByZXNwb25zZSB0byBh IEdFVDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O21z by1mYXJlYXN0LWxhbmd1YWdlOkZSIj4mbmJzcDsmbmJzcDsgcmVxdWVzdCB3aXRoIGFsbCBvZiB0 aGUgcmVhZC1vbmx5IHBhcmFtZXRlcnMgc3RyaXBwZWQgb3V0KGUuZy4gcGVuZGluZy1saWZldGlt ZSkuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkZS Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlIiPiZuYnNwOyZuYnNwOw0K PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj5SZWdhcmRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkpvbjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1HQiI+IERvdHMgW21haWx0bzoNCjxhIGhyZWY9Im1haWx0bzpkb3Rz LWJvdW5jZXNAaWV0Zi5vcmciPmRvdHMtYm91bmNlc0BpZXRmLm9yZzwvYT5dIDxiPk9uIEJlaGFs ZiBPZg0KPC9iPjxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIj5t b2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPjxicj4NCjxiPlNlbnQ6PC9iPiAyNSBBcHJp bCAyMDE4IDEzOjM5PGJyPg0KPGI+VG86PC9iPiBKb24gU2hhbGxvdzsgJ0tvbmRhLCBUaXJ1bWFs ZXN3YXIgUmVkZHknOyA8YSBocmVmPSJtYWlsdG86ZG90c0BpZXRmLm9yZyI+DQpkb3RzQGlldGYu b3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0RvdHNdIGRhdGEgY2hhbm5lbCBhbmQg cGVuZGluZy1saWZldGltZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrIj5IaSBKb24sDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+V2h5IGRvIHlvdSB3YW50IHRvIHJlc3RyaWN0IHRoZSByZWZyZXNoIHRv IHRoZSBleGFjdCBjb250ZW50IG9mIHRoZSBpbml0aWFsIHJlcXVlc3Q/DQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+V2hhdCBpcyBpbXBvcnRhbnQg aXMgdGhlIG5hbWUgb2YgdGhlIGFsaWFzLCBzdWItY2xhdXNlcyBtYXkgY2hhbmdlIChlLmcuLCBw cmVmaXggY2hhbmdlKS4gV2UgZG8gYWxyZWFkeSBoYXZlIHRoaXMgdGV4dCBpbiB0aGUgZHJhZnQ6 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RlIiPiZuYnNwOyZuYnNwOyBBIERPVFMgY2xpZW50IHVzZXMgdGhlIFBVVCByZXF1ZXN0IHRv IG1vZGlmeSB0aGUgYWxpYXNlcyBpbiB0aGUgRE9UUzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Ozttc28tZmFyZWFzdC1sYW5n dWFnZTpGUiI+Jm5ic3A7Jm5ic3A7IHNlcnZlci4mbmJzcDsgSW4gcGFydGljdWxhciwgYSBET1RT IGNsaWVudCBNVVNUIHVwZGF0ZSBpdHMgYWxpYXMgZW50cmllczxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Ozttc28tZmFyZWFz dC1sYW5ndWFnZTpGUiI+Jm5ic3A7Jm5ic3A7IHVwb24gY2hhbmdlIG9mIHRoZSBwcmVmaXggaW5k aWNhdGVkIGluIHRoZSAndGFyZ2V0LXByZWZpeCcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkRpZCBJIG1pc3NlZCBzb21ldGhpbmc/PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkNoZWVycyw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPk1lZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg Ymx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpGUiI+RGUmbmJzcDs6PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpGUiI+IERvdHMg WzxhIGhyZWY9Im1haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpkb3RzLWJvdW5j ZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+RGUgbGEgcGFydCBkZTwvYj4gSm9uIFNoYWxsb3c8YnI+DQo8 Yj5FbnZvecOpJm5ic3A7OjwvYj4gbWVyY3JlZGkgMjUgYXZyaWwgMjAxOCAxNDozMTxicj4NCjxi PsOAJm5ic3A7OjwvYj4gJ0tvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHknOyA8YSBocmVmPSJtYWls dG86ZG90c0BpZXRmLm9yZyI+ZG90c0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5PYmpldCZuYnNwOzo8 L2I+IFJlOiBbRG90c10gZGF0YSBjaGFubmVsIGFuZCBwZW5kaW5nLWxpZmV0aW1lPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJjb2xvcjojMUY0OTdEIj5IaSBUaXJ1LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5DYW4gd2UgdGhlbiBwbGVhc2Ug aGF2ZSBzb21lIHN1aXRhYmxlIHRleHQgYWRkZWQgKGUuZy4gdXNlIFBVVCwgYW5kIHJlZnJlc2gg c2hvdWxkIGJlIHRoZSBzYW1lIGFzIHRoZSBwcmV2aW91cyByZXF1ZXN0IChJdCBjb3VsZCBiZSBk aWZmZXJlbnQgaWYgdGhlIGNsaWVudCB3YW50cyB0byBjaGFuZ2UgYSBwYXJhbWV0ZXIsIGJ1dCBr ZWVwIHRoZQ0KIHNhbWUgbmFtZSkpIHNvIHRoYXQgdGhlIG5leHQgaW1wbGVtZW50ZXIgZG9lcyBu b3QgaGF2ZSB0byBkZWR1Y2UgdGhlIGluZm9ybWF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5UaGFua3M8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Sm9u PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNO Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6WkgtQ04iPiBEb3RzIFs8YSBocmVmPSJtYWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3Jn Ij5tYWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+ Sm9uIFNoYWxsb3c8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBBcHJpbCAyNSwgMjAxOCA1 OjI5IFBNPGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86ZG90c0BpZXRmLm9yZyI+ZG90 c0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW0RvdHNdIGRhdGEgY2hhbm5lbCBh bmQgcGVuZGluZy1saWZldGltZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IGNs YXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+DQo8 aHIgc2l6ZT0iMyIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiPg0KPC9zcGFuPjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+SGkgdGhlcmUs PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIj5UbyBtYWtlIHBlbmRpbmctbGlmZXRpbWUgd29yaywgdGhlIEFs aWFzIC8gQUNMIG5lZWRzIHRvIHBlcmlvZGljYWxseSBiZSByZWZyZXNoZWQgYnkgdGhlIERPVFMg Y2xpZW50IHRvIG1ha2Ugc3VyZSB0aGUgZW50cnkgZG9lcyBub3QgZ28gc3RhbGUgYW5kIGNvbnNl cXVlbnRseSBnZXQgZGVsZXRlZCBieSB0aGUgRE9UUyBzZXJ2ZXIuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC Ij5SRVNUQ09ORiBSRkMgODA0MCA0LjQuMSBDcmVhdGUgUmVzb3VyY2UgTW9kZTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiI+Jm5ic3A7Jm5ic3A7IElmIHRoZSBkYXRhIHJlc291cmNlIGFscmVhZHkgZXhpc3Rz LCB0aGVuIHRoZSBQT1NUIHJlcXVlc3QgTVVTVCBmYWlsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOyZuYnNwOyBhbmQg YSAmcXVvdDs0MDkgQ29uZmxpY3QmcXVvdDsgc3RhdHVzLWxpbmUgTVVTVCBiZSByZXR1cm5lZC4m bmJzcDsgVGhlIGVycm9yLXRhZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDsmbmJzcDsgdmFsdWUgJnF1b3Q7cmVzb3Vy Y2UtZGVuaWVkJnF1b3Q7IGlzIHVzZWQgaW4gdGhpcyBjYXNlLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+ U28sIHdlIGNhbm5vdCByZWFsbHkgdXNlIFBPU1QgdG8gcmVmcmVzaCB0aGUgQWxpYXMgLyBBQ0wg dW5sZXNzIHRoZSA0MDkgaXMgdG8gYmUgaWdub3JlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPlJGQyA4 MDQwIDQuNSBQVVQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOyZuYnNwOyBDb25zaXN0ZW50IHdp dGggW1JGQzcyMzFdLCBpZiB0aGUgUFVUIHJlcXVlc3QgY3JlYXRlcyBhIG5ldyByZXNvdXJjZSw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiI+Jm5ic3A7Jm5ic3A7IGEgJnF1b3Q7MjAxIENyZWF0ZWQmcXVvdDsgc3RhdHVzLWxpbmUg aXMgcmV0dXJuZWQuJm5ic3A7IElmIGFuIGV4aXN0aW5nIHJlc291cmNlIGlzPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNw OyZuYnNwOyBtb2RpZmllZCwgYSAmcXVvdDsyMDQgTm8gQ29udGVudCZxdW90OyBzdGF0dXMtbGlu ZSBpcyByZXR1cm5lZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPlNvLCBQVVQgd2lsbCB3b3JrLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiI+SW4gZHJhZnQtaWV0Zi1kb3RzLWRhdGEtY2hhbm5lbC0xNSwgdGhlcmUg YXJlIG5vIHNlY3Rpb25zIG9uIGRlc2NyaWJpbmcgaG93IEFsaWFzZXMgLyBBQ0xTIGFyZSB0byBi ZSByZWZyZXNoZWQgb3RoZXIgdGhhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7Jm5ic3A7IEEg RE9UUyBzZXJ2ZXIgTVVTVCBtYWludGFpbiBhIFtmaWx0ZXJpbmcgcnVsZXxhbGlhc10gZm9yIGF0 IGxlYXN0IDEwMDgwPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOyZuYnNwOyBtaW51dGVzICgxIHdlZWspLiZuYnNwOyBJ ZiBubyByZWZyZXNoIHJlcXVlc3QgaXMgc2VlbiBmcm9tIHRoZSBET1RTPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOyZu YnNwOyBjbGllbnQsIHRoZSBET1RTIHNlcnZlciByZW1vdmVzIGV4cGlyZWQgZW50cmllcy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiPkkgYXNzdW1lIHRoYXQgYSBQVVQgcmVmcmVzaCByZXF1ZXN0IG11c3Qg YmUgYW4gZXhhY3QgbWF0Y2ggZm9yIHRoZSBpbml0aWFsIHJlcXVlc3QgKG9yIGFuIGVjaG8gYmFj ayBvZiB0aGUgR0VUIHJlc3BvbnNlIHdpdGggc29tZSBmaWVsZHMgc3RyaXBwZWQgb3V0IHRoYXQg YXJlIHJvKS4mbmJzcDsgQ29ycmVjdD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPltUUl0gWWVzLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiI+LVRpcnU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPlJlZ2FyZHM8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiPkpvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_787AE7BB302AE849A7480A190F8B93302DF11542OPEXCLILMA3corp_--