Subject: [lmap] Is suppression just for Active Measurement Tasks

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 17 Feb 2014 15:09:40 +0000

Hi Phil,
Sorry, I just can't ignore. :) But I did change the subject line of the email thread.

[phil] should suppression by default impact all Tasks or just Active ones? The argument for the former is that it's simpler - it avoids having to classify Tasks as active or passive - and for the MA having to remember this info. It avoids getting into discussion about whether the passive tasks are generating a lot of Reports (should they be suppressed), what to do if an active task has been mis-classified as a passive task, what happens if the operator wants to suppress tasks for reasons other than a network overload (perhaps some privacy attack), can we treat an active task that only generates 1 or 2 packets as (almost) passive.

I have sympathy with your viewpoint (in fact, it was my viewpoint earlier). At the moment, given suppression is only a rare thing, I've been persuaded it's better to go for simplicity and make suppression affect all Tasks by default. (of course, one can use the suppression option to list specific Tasks that are suppressed.)

<bhs> I'm currently working on formulating a coherent argument as to why I think suppression should only apply to active measurements. I'm not done thinking this through, but I'll pass along some of where I'm at with this thinking.

1.       We've talked about the possibility of MAs being in home routers, set-top-boxes, and various network elements (DSLAM, BNG, etc) and such. In other words, as a function inside a device/element with a whole lot of other functions and not dedicated to measurements. I'm not sure if people suggesting suppression apply to passive measurements are fully aware of the extent of passive measurement that goes on in these device/elements today. It's huge. And, yes, the firewall log is generated through passive measurement. Firewall logging is the main required element of any ICSA-compliant firewall. Shutting all of this down is not a good idea, and is completely unnecessary.

2.       The idea for suppression was initially put forward as a means to protect the network during times of congestion, or to protect certain "MPs" or "MAs that can 'respond' to measurement tasks" when those MPs and MAs are having issues. Passive measurements have no impact on these.

3.       If suppression is seen as "don't generate IP packets / Ethernet frames related to any Measurement Task (or related to just this specific list of Tasks/Methods/Schedules)", then there is no need for classification of passive vs. active and passive measurements are automatically exempt. This is pretty simple -- even I could figure out how to code this.

BTW, I don't see reports as being a component of suppression either. Suppression shouldn't brick a device/element or shut down all its functions. Just don't generate any traffic associated with performing measurement tasks.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 17 Feb 2014 16:19:54 +0100

> 1.       We've talked about the possibility of MAs being in home routers, set-top-boxes, and various network elements (DSLAM, BNG, etc) and such. In other words, as a function inside a device/eleme…

As long as your firewall is not a measurement task (which I think it
isn't because it is a system function), LMAP will not affect it all. I
think we should not confuse system functions with measurement tasks.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Mon, 17 Feb 2014 10:50:39 -0500

________________________________________
From: lmap [[email-masked]] On Behalf Of Juergen Schoenwaelder [[email-masked]]
Sent: Monday, February 17, 2014 10:19 AM
To: STARK, BARBARA H
Cc: [email-masked]; [email-masked]
Subject: Re: [lmap] Is suppression just for Active Measurement Tasks

/js

[Al adds]
+1, Suppress can only affect LMAP tasks. Also, when reporting is considered
it may be more important to stop passive reporting when the task involves 
measurements on all user flows, or worse, on all packets (could easily produce
more network load than many active tests used today).

Al

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 17 Feb 2014 16:29:31 +0000

> As long as your firewall is not a measurement task (which I think it isn't
> because it is a system function), LMAP will not affect it all. I think we should
> not confuse system functions with measurement tasks.
> 
> /js
> 
> [Al adds]
> +1, Suppress can only affect LMAP tasks. Also, when reporting is
> +considered
> measurements on all user flows, or worse, on all packets (could easily
> produce more network load than many active tests used today).

I believe that reports should be disabled (when necessary) by disabling a report channel. If reports of passive measurements are the problem, and active measurements are not, then sending a suppression message targeted at the measurements that can be reported via a particular report channel is more complicated than just disabling the report channel. Also, if the same passive measurement is reported out 2 different channels and only one of those channels is distressed, then killing the passive measurement is not the right approach. 

I also consider it conceivable that having mass reporting of firewall logs (not as part of a regulatory use case, but perhaps as part of a service provider use case to determine how well the firewalls are working) could occur. So maybe now the firewall log is both an MA and system function and the way things are coded causes all firewall logging to stop when the suppression happens.

What I'm trying to do is avoid the Law of Unintended Consequences that generally takes hold when functions like this are too broadly defined. There is no need to define Suppression this broadly. It's just not that hard to have it apply only to active measurement traffic. If a passive measurement is causing internal-to-the-device issues, then stop that specific passive measurement. If a report channel has issues, disable the report channel. Don't try to use this suppression kill switch as a means of targeted disabling of specific activities. If there are specific activities you want to disable, then disable them via "regular" commands.
Barbara

---

From: Charles Cook <[email-masked]>
Date: Mon, 17 Feb 2014 10:03:59 -0700

Suppression of the Report Channel should be able to address concerns of
Passive Measurement Tasks creating a negative impact on the network.

Charles

On 2/17/2014 9:29 AM, STARK, BARBARA H wrote:
> _______________________________________________
> lmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lmap

-- 

Charles Cook 
Principal Architect
Network
5325 Zuni Street; Suite 224
Denver, CO  80221
Tel:  303.992.8952  Fax:  925.281.0662
[email-masked]

---

From: "Sharam Hakimi" <[email-masked]>
Date: Mon, 17 Feb 2014 13:21:22 -0500

I think it is fairly easy to have two TASK instructions for the MA, one
is the Active tests and the other is the Passive test. This is managed
by the user at the MC. Once a Suppression is issued, it would be
followed by the Passive TASK Instruction. This would keep the passive
tasks running after a suppression command. It is not perfect, but
stripping every test in a task is a much more difficult endeavor in my
opinion.

Sharam 

-----Original Message-----
From: lmap [mailto:[email-masked]] On Behalf Of Juergen
Schoenwaelder
Sent: Monday, February 17, 2014 10:20 AM
To: STARK, BARBARA H
Cc: [email-masked]; [email-masked]
Subject: Re: [lmap] Is suppression just for Active Measurement Tasks

On Mon, Feb 17, 2014 at 03:09:40PM +0000, STARK, BARBARA H wrote:
> [phil] should suppression by default impact all Tasks or just Active
ones? The argument for the former is that it's simpler - it avoids
having to classify Tasks as active or passive - and for the MA having to
remember this info. It avoids getting into discussion about whether the
passive tasks are generating a lot of Reports (should they be
suppressed), what to do if an active task has been mis-classified as a
passive task, what happens if the operator wants to suppress tasks for
reasons other than a network overload (perhaps some privacy attack), can
we treat an active task that only generates 1 or 2 packets as (almost)
passive.
> 
> I have sympathy with your viewpoint (in fact, it was my viewpoint
earlier). At the moment, given suppression is only a rare thing, I've
been persuaded it's better to go for simplicity and make suppression
affect all Tasks by default. (of course, one can use the suppression
option to list specific Tasks that are suppressed.)
> 
> <bhs> I'm currently working on formulating a coherent argument as to
why I think suppression should only apply to active measurements. I'm
not done thinking this through, but I'll pass along some of where I'm at
with this thinking.
> 
> 1.       We've talked about the possibility of MAs being in home
routers, set-top-boxes, and various network elements (DSLAM, BNG, etc)
and such. In other words, as a function inside a device/element with a
whole lot of other functions and not dedicated to measurements. I'm not
sure if people suggesting suppression apply to passive measurements are
fully aware of the extent of passive measurement that goes on in these
device/elements today. It's huge. And, yes, the firewall log is
generated through passive measurement. Firewall logging is the main
required element of any ICSA-compliant firewall. Shutting all of this
down is not a good idea, and is completely unnecessary.

/js

---

From: "Sharam Hakimi" <[email-masked]>
Date: Mon, 17 Feb 2014 13:32:57 -0500

Sorry, That was supposed to be STRIPING every test. Auto correct did me
an unwanted favor.

 Sharam

-----Original Message-----
From: lmap [mailto:[email-masked]] On Behalf Of Sharam Hakimi
Sent: Monday, February 17, 2014 1:21 PM
To: Juergen Schoenwaelder; STARK, BARBARA H
Cc: [email-masked]; [email-masked]
Subject: Re: [lmap] Is suppression just for Active Measurement Tasks

Sharam 

-----Original Message-----

/js