Re: [Dots] draft-ietf-dots-filter-control: acl updates

"Jon Shallow" <supjps-ietf@jpshallow.com> Wed, 15 May 2019 13:52 UTC

Return-Path: <supjps-ietf@jpshallow.com>
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 BFDF712024F for <dots@ietfa.amsl.com>; Wed, 15 May 2019 06:52:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level:
X-Spam-Status: No, score=-1.89 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] 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 OlouV9N7pcUu for <dots@ietfa.amsl.com>; Wed, 15 May 2019 06:52:19 -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 BD2681202FC for <dots@ietf.org>; Wed, 15 May 2019 06:52:18 -0700 (PDT)
Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.91) (envelope-from <jon.shallow@jpshallow.com>) id 1hQuKN-0005jn-6O; Wed, 15 May 2019 14:52:15 +0100
From: "Jon Shallow" <supjps-ietf@jpshallow.com>
To: <mohamed.boucadair@orange.com>, <dots@ietf.org>
References: <787AE7BB302AE849A7480A190F8B93302EA7DAAF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <BYAPR16MB279089B075158BFF8C8B2E5FEA090@BYAPR16MB2790.namprd16.prod.outlook.com> <787AE7BB302AE849A7480A190F8B93302EA7E01D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <7f1f7363-11d0-9acd-32a5-ba9fc92cf433@nttv6.jp> <787AE7BB302AE849A7480A190F8B93302EA7E072@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <00e801d50b04$54db4a90$fe91dfb0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302EA7E37B@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA7E37B@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Date: Wed, 15 May 2019 14:52:16 +0100
Message-ID: <018f01d50b25$682183a0$38648ae0$@jpshallow.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0190_01D50B2D.C9E99520"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQICWZNkR5uJrFVQhsKT4M681dMsdwDLeKj/AkMyvT4B7HN7vgIQGcjYAf+P1K8CzR/oVKWy1wZQ
Content-Language: en-gb
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/sLnmlTJXuW4cMWgeC9HqUWPCH9s>
Subject: Re: [Dots] draft-ietf-dots-filter-control: acl updates
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <dots.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dots>, <mailto:dots-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dots/>
List-Post: <mailto:dots@ietf.org>
List-Help: <mailto:dots-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dots>, <mailto:dots-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 May 2019 13:52:28 -0000

Hi Med,

 

I think that covers it.  Now I have access to my emails, it was the PUT that I was thinking about, not the GET.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com
Sent: 15 May 2019 12:22
To: Jon Shallow; dots@ietf.org
Subject: Re: [Dots] draft-ietf-dots-filter-control: acl updates

 

Re-, 

 

Noted. Thanks. 

 

With regards to your second point, we do have the following in the draft:

 

   If, during an active mitigation, the 'activation-type' is changed at

   the DOTS server (e.g., as a result of an external action) for an ACL

   bound to a DOTS client, the DOTS server notifies that DOTS client

   with the change by including the corresponding ACL parameters in an

   asynchronous notification (the DOTS client is observing the active

   mitigation) or in a response to a polling request (Section 4.4.2.2 of

   [I-D.ietf-dots-signal-channel]).

 

Do we need to say more? 

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] 
Envoyé : mercredi 15 mai 2019 11:56
À : BOUCADAIR Mohamed TGI/OLN; kaname nishizuka; Konda, Tirumaleswar Reddy; dots@ietf.org
Objet : RE: [Dots] draft-ietf-dots-filter-control: acl updates

 

Hi Guys,

 

I concur with (2).

 

I think that we have the ‘mid’ wrap properly covered (more likely to occur now with lots of ‘tweaks’ to the mitigation when trying out different acl-lists).

 

With (2) changing the activation-types, it is possible that some packets may not get through, and so an activation-type may be in an unexpected state.  I know  that we encourage regular monitor of the status of a mitigation (by signal channel observing), but  am unable to find as to whether acl-list etc. is returned on signal channel GET response (there are no GET signal channel response examples).  There was discussion about this on the mailing list, but it did not get a final resolution.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com
Sent: 15 May 2019 09:05
To: kaname nishizuka; Konda, Tirumaleswar Reddy; dots@ietf.org
Subject: Re: [Dots] draft-ietf-dots-filter-control: acl updates

 

Re-,

 

Thank you for sharing your thoughts.

 

-00 allows to use both a new or existing ‘mid’. With (2) taken into account, we need the following change:

 

OLD:

 

   A DOTS client may include acl-* attributes in a mitigation request

   having a new or an existing 'mid'.  When acl-* attributes are to be

   included in a mitigation request with an existing 'mid', the DOTS

   client MUST repeat all the other parameters as sent in the original

   mitigation request (i.e., having that 'mid') apart from a possible

   change to the lifetime parameter value.

 

NEW:

   During an attack time, DOTS clients may include 'acl-list', 'acl-

   name', and 'activation-type' attributes in a mitigation request.

   This request may be the initial mitigation request for a given

   mitigation scope or a new one overriding an existing request.  In

   both case, a new 'mid' MUST be used.

 

   As the attack evolves, DOTS clients can adjust the 'activation-type'

   of an ACL conveyed in a mitigation request or control other filters

   as necessary.  This can be achieved by sending a PUT request with a

   new 'mid' value.

 

Cheers,

Med

 

De : kaname nishizuka [mailto:kaname@nttv6.jp] 
Envoyé : mercredi 15 mai 2019 09:59
À : BOUCADAIR Mohamed TGI/OLN; Konda, Tirumaleswar Reddy; dots@ietf.org
Objet : Re: [Dots] draft-ietf-dots-filter-control: acl updates

 

Hi Tiru, Med,

I agree with Tiru.

> FWIW, the changes to implement (2) can be seen at:
>
> https://github.com/boucadair/filter-control/blob/master/wdiff%20draft-ietf-dots-signal-filter-control-00.txt%20draft-ietf-dots-signal-filter-control-01.pdf
>
Could you specify where it is?
(2) is taken account as the current version of the draft allows to include acl attributes in requests with new ‘mid’s.

regards,
Kaname

On 2019/05/15 16:28, mohamed.boucadair@orange.com wrote:

Hi Tiru, 

 

Agree. 

 

Looking forward to hear  more. 

 

FWIW, the changes to implement (2) can be seen at: 

 <https://github.com/boucadair/filter-control/blob/master/wdiff%20draft-ietf-dots-signal-filter-control-00.txt%20draft-ietf-dots-signal-filter-control-01.pdf> https://github.com/boucadair/filter-control/blob/master/wdiff%20draft-ietf-dots-signal-filter-control-00.txt%20draft-ietf-dots-signal-filter-control-01.pdf 

 

Cheers,

Med

 

De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] 
Envoyé : mercredi 15 mai 2019 09:11
À : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org
Objet : RE: draft-ietf-dots-filter-control: acl updates

 

I don’t think approach (1) is a good idea because of out of order delivery of packets. Further, the anti-relay detection technique in DTLS uses sliding windows procedure. An MITM can possibility cache and drop the packets from the client, and replay the cached packets that fall within the sliding window. For instance in the below example, the server could receive packets in the order T0, T4, T1, T2. 

 

Monotonically increasing ‘mid’ is the only defense against this mechanism, and I don’t think the signal channel draft needs any update.  

 

Cheers,

-Tiru

 

From: Dots  <mailto:dots-bounces@ietf.org> <dots-bounces@ietf.org> On Behalf Of mohamed.boucadair@orange.com
Sent: Tuesday, May 14, 2019 8:14 PM
To: dots@ietf.org
Subject: [Dots] draft-ietf-dots-filter-control: acl updates

 


CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.


  _____  


Hi all, 

 

The current version of the draft allows to include acl attributes in requests with new or existing ‘mid’s. By “existing mid’, we meant an existing request which does not include acl attributes when the request was initially created. For such requests, the activation-type of the same acl can be changed as the attack evolve or even control other ACLs. This is supposed to be covered by this text: 

 

   When acl-* attributes are to be

   included in a mitigation request with an existing 'mid', the DOTS

   client MUST repeat all the other parameters as sent in the original

   mitigation request (i.e., having that 'mid') apart from a possible

   change to the lifetime parameter value.

 

For example: 

T0: R(mid)

T1: R(mid, acl1, activation-type=value1)

T2: R(mid, acl2, activation-type=value2)

T3: R(mid, acl1, activation-type=value2)

T4: R(mid)

...

 

Now, if acl attributes are included in a request with a new mid, we need to specify how activation-type (and acl-list in general) can be updated. We do have two options:

 

1.	Update the draft with this NEW text:

 

   If 'acl-list', 'acl-name', and 'activation-type' attributes are
   included in the initial mitigation request (that is, a mitigation
   request with a new 'mid'), the DOTS client may update the
   'acl-list' as an active attack evolves.  To do so, the DOTS
   client MUST repeat all the other parameters as sent in the original
   mitigation request apart from a possible change to the 'acl-list’
   and the lifetime parameter values.

 

   And the signal channel spec as follows:

 

   For a mitigation request to continue beyond the initial negotiated
   lifetime, the DOTS client has to refresh the current mitigation
   request by sending a new PUT request..  This PUT request MUST use the
   same 'mid' value, and MUST repeat all the other parameters as sent in
   the original mitigation request apart from a possible change to the
   lifetime parameter value or other changes to attributes defined in future extensions.
                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^   

 

For example: 

T0: R(mid, acl1, activation-type=value1)

T1: R(mid, acl2, activation-type=value2)

T2: R(mid, acl1, activation-type=value2)

..

 

 

2.	Require a new mid each time a client has to insert acl attributes. 

 

For example: 

T0: R(mid0)

T1: R(mid1, acl1, activation-type=value1)

T2: R(mid2, acl2, activation-type=value2)

T3: R(mid3, acl1, activation-type=value2)

...

 

 

Thoughts?

 

Cheers,

Med

 

 

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