Subject: Re: [Dots] DATA Channel: Filtering Lifetime

From: <[email-masked]>
Date: Mon, 8 Jan 2018 08:44:08 +0000

Re-,

This change will appear in the next version of the draft. The lifetime will be defined at the acl level.

Given that the parameter is likely to include long values, using "minutes" instead of "seconds" seems more appropriate here.

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : jeudi 21 décembre 2017 17:16
À : BOUCADAIR Mohamed IMT/OLN; [email-masked]
Objet : RE: [Dots] DATA Channel: Filtering Lifetime

Hi Med,

Instead of doing this at the ace level (of which there could be many per filter definition), I would prefer this to be done at the dots-acl-order + acl-set level, or at the acl level.

I think the lifetime needs to be sufficiently long to prevent frequent refreshes, but not too long that stale entries never get flushed.  A day feels too small, a week feels about right and a month is too long.

Otherwise, this makes sense to me.

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 21 December 2017 09:48
To: [email-masked]<mailto:[email-masked]>
Subject: [Dots] DATA Channel: Filtering Lifetime

Hi all,

I suggest to add a lifetime attribute to the ACL entry so that we avoid stale rules be maintained by the server indefinitely. The change would look like:

  augment /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace:
    +--rw lifetime?   int32

Motivation:

This will be a first guard, for example, to soften maintaining stale entries when a network renumbers but forgot to update/delete old filtering rules.

ACLs are today enforced by an administrator (operator) for its own usages. He/she can modify them based on local criteria. Scripts are usually used to delete/add/etc. The game changes with DOTS as the rules are instructed by a third party. The mitigation provider may end with a long list if stale entries because DOTS clients didn't cleared...which is undesirable. Of course, a mitigation server provider may accept filtering rules with indefinite lifetime; this is deployment-specific.

Lifetime is an information to be maintained at the DOTS server level, not at the device level. Network devices do not require to support the lifetime. Clearing invalid entries will be managed through the DOTS server.

The text will indicate that a DOTS server MUST NOT clear an expired entry when an attack mitigation is ongoing.

Any objection to this change?

Opinions about the recommended value are also welcome.

Cheers,
Med

---

From: "Jon Shallow" <[email-masked]>
Date: Mon, 8 Jan 2018 09:22:54 -0000

Hi Med,

If we go for lifetime in minutes,  it needs to obviously be clear in the
surrounding documentation, but I think the variable ought to be named
‘lifetime-minutes’ for clarity.

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of
[email-masked]
Sent: 08 January 2018 08:44
To: Jon Shallow; [email-masked]
Subject: Re: [Dots] DATA Channel: Filtering Lifetime

Re-,

This change will appear in the next version of the draft. The lifetime will
be defined at the acl level. 

Given that the parameter is likely to include long values, using “minutes”
instead of “seconds” seems more appropriate here. 

Cheers,

Med

Hi Med,

Instead of doing this at the ace level (of which there could be many per
filter definition), I would prefer this to be done at the dots-acl-order +
acl-set level, or at the acl level.

I think the lifetime needs to be sufficiently long to prevent frequent
refreshes, but not too long that stale entries never get flushed.  A day
feels too small, a week feels about right and a month is too long.

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of
[email-masked]
Sent: 21 December 2017 09:48
To: [email-masked]
Subject: [Dots] DATA Channel: Filtering Lifetime

Hi all, 

I suggest to add a lifetime attribute to the ACL entry so that we avoid
stale rules be maintained by the server indefinitely. The change would look
like:

    +--rw lifetime?   int32

Motivation: 

This will be a first guard, for example, to soften maintaining stale entries
when a network renumbers but forgot to update/delete old filtering rules. 

ACLs are today enforced by an administrator (operator) for its own usages.
He/she can modify them based on local criteria. Scripts are usually used to
delete/add/etc. The game changes with DOTS as the rules are instructed by a
third party. The mitigation provider may end with a long list if stale
entries because DOTS clients didn’t cleared…which is undesirable. Of course,
a mitigation server provider may accept filtering rules with indefinite
lifetime; this is deployment-specific. 

Lifetime is an information to be maintained at the DOTS server level, not at
the device level. Network devices do not require to support the lifetime.
Clearing invalid entries will be managed through the DOTS server. 

The text will indicate that a DOTS server MUST NOT clear an expired entry
when an attack mitigation is ongoing. 

Cheers,

Med