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
>
> 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 <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