Re: draft on sampling techniques

[Nick Duffield <duffield@research.att.com>]

Cristian,

sorry for the late reply on this message:, see below:
Cristian Estan wrote:

[...]
> >>
> >> 3) I believe this document should also contain the safeguards we need
> >> to put in to avoid floods of sampled packets due to misconfiguration
> >> or attacks on the measurement infrastructure. The simplest thing that
> >> comes to my mind is defining a leaky bucket regulator that would
> >> limit the rate and the burst size for the samples being sent to the
> >> collection station.
> >
> >
> >
> > Maybe we can add this proposal to the security considerations ? Could
> > you maybe write a few sentences that can be included in the next
> > version of the draft ?
> 
> Below. Feel free to modify it wherever you think it's necessary.
> 
> The amount of measurement result data produced by devices implementing
> packet sampling is a security concern. Large volumes of data can result
> because of attacks on the measurement infrastructure, misconfigurations,
> bugs in the implementation of the sampling function or the randomness of
> the sampling function. The traffic measurement modules performing the
> sampling of packets should protect against such floods of sampled
> packets. This protection is enforced through safe defaults for the
> sampling parameters and explicit safeguards.
> 
> If the sole consumer of sampled packets is a metering process local to
> the device that implements the sampling function, the manufacturer may
> choose not to implement safeguards and not to use safe defaults. If
> there is at least one consumer of traffic reports containing the sampled
> packets outside the device implementing the sampling function and the
> sampling function ensures that the number of sampled packets is no
> larger than a fixed fraction of the packets, the sampling function must
> implement safe defaults but may not implement explicit safeguards. Such
> sampling functions include systematic sampling and n-out-of-N sampling.
> 
> The default values of the sampling parameters should be safe. They
> should ensure that the number of sampled packets is no more than 0.01%
> of the packets carried by the link observed or that they do not add up
> to more than 0.01% of the link capacity. These constraints should hold
> over any 30 second time interval. A configuration of the sampling
> function that samples no packets at all is safe.
> 
> Explicit safeguards have to limit the average rate at which samples are
> generated (in sampled packets/second) and the maximum burst size (in
> sampled packets). The average rate and the maximum burst size are
> parameters of the safeguard. The default values for these parameters
> must be such that they ensure limits on the number of samples at least
> as strong as the safe defaults above. The implementation can allow the
> operator to change these parameters. The implementation may refuse
> parameters for the safeguard it considers too aggressive. The
> implementation must ensure that the sampling parameters are such that
> under normal operation, the number of sampled packets is within the
> limits of the safeguard. When the safeguard mechanism removes sampled
> packets because they go beyond the allowed limits, it should indicate
> this. The counter for sampled packets we include with each of them
> should be incremented for the sampled packets discarded by the
> safeguard. To implement the safeguard one could use a leaky bucket
> descriptor as in [Cruz87]. Another acceptable implementation of the
> safeguard which does not require timers is given below.
> 
> The device implementing the sampling function could use a safeguard
> counter initialized to the maximum burst size. Whenever a packet is
> sampled by the sampling function, if the safeguard counter is above
> zero, it is decremented and the sampled packet is processed further.
> Otherwise, the counter for sampled packets is incremented but the
> sampled packet is not processed. Once in every N packets, the safeguard
> counter is incremented unless it is at the maximum burst size, in which
> case it is not. The parameter N limits the average rate of the sampled
> packets to a fraction of 1/N of the transmitted packets. If the sampling
> function is probabilistic sampling with a fixed sampling probability, it
> should be strictly smaller than 1/N. Leaky buckets operate in a similar
> fashion, except they use timers instead of packets to increment the
> safeguard counter and therefore limit the average rate of the sampled
> packets to a fraction of the link capacity.
> 
> [Cruz87] Rene L. Cruz, A calculus for Network Delay and a Note on
> Topologies of Interconnection Networks, Ph.D. Thesis, University of
> Illinois, issued as Report UiLU-ENG-87-2246, July 1987
> 
> Cheers,
> 
> Cristian

I agree we need to guard against flooding the network. In the framework
doc
the way to do this is to have the export rate be controlled by the
collector, in response to detection of congestion. We need to avoid
flooding any link
on the export path, not just the router interface, so the collector is
well
positioned to determine the correct rate. What you call the default
values
for the export rate would then be the initial values for the export 
rate.

However, I see the rate control as operating at export, so this topic
belongs
better in the future export document, rather than the sampling document. 

Nick

> 
> --
> to unsubscribe send a message to psamp-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/psamp/>

--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/psamp/>