Re: Feedback 3

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

Cristian, comments inline, Nick

Cristian Estan wrote:
> 
> This email addresses topic 3 stuff I'd like to see in this draft. Or at
> least I'd like the framework to not preclude any of it. 

I see the application you Desiree below as a customer for PSAMP
measurements, rather than part of PSAMP itself. 

> These are
> mostly things I've been working on lately. The examples I give are
> mostly related to security and not in the sense of providing forensic
> evidence of network activity like the "Hash-Based IP Traceback" but in
> the sense of triggering alarms when the traffic looks fishy. Bits and
> pieces will surely apply to other problems too.
> 
> Routers can detect ongoing DDoS attacks. The draft says that the
> router sees a lot of traffic going to the victim address. This can
> still lead to a lot of false positives (e.g. all busy web servers
> would look like they are attacked). We can refine it further by just
> reporting those destination that receive a lot of traffic from a lot
> of fake sources. How? Install some filters that let through only
> packets that come from some sparsely populated /8s and count the
> number of distinct source addresses we see (I'm working on a paper
> that shows that counting the number of distinct addresses can be done
> pretty accurately in tens of bytes).
> 
> How would this fit into the framework? We just define another
> measurement information flow with its own filters. Now instead of only
> keeping a packet and a byte count for each "flow" defined by
> destination addresses, the device also keeps another aggregate piece
> of information: the number of distinct sources. And we need to add a
> rule to the reporting part that says: report this kind of data only if
> you see a computer receiving more than 1Mbyte/s from these suspect /8s
> and the number of sources that send to it is at least 100,000.

The filtering is right in the PSAMP domain. Counting the number
of distinct sources and contingent reporting looks like not part of
PSAMP but rather a measurement-based application executing in the
router.
The application uses PSAMP selected packets as its input data, presented
to it by local export; see last paragraph of Section 3.3

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