[c-nsp] Sampled netflow & compliance issues

Phil Mayers p.mayers at imperial.ac.uk
Thu Feb 9 05:17:54 EST 2012


On 02/09/2012 10:00 AM, Gert Doering wrote:

>>
>> "Do you know for certain that IP x emitted packets Y?"
>> "Well, we have an X% confidence bound that..."
>> "Then I'll see you in court."
>
> Well, it would be sort of silly to deny that the miscreant did something
> if the ISP even saw it *with sampling*.
>
> It's not like sampling would invent new packets, instead overlook some
> of the miscreant activity - so the argument "you can't prove that I did
> it because you might have not seen all of it!" is... interesting.

Ok, bad example.

I'm specifically thinking about p2p downloads. At (say) 512:1 sampling, 
they can simply deny they downloaded a 5Gb file, and claim it was a 10Mb 
file. Obviously this is ludicrously unlikely to be true, but, in theory, 
possible.

I guess this is related to your next point...

> Billing using sampled netflow is more where I see problems arising,
> because you know your numbers will not be accurate, but you don't know
> how big the error is, and in which direction you err.  With unsampled

Is that true? As indicated, my stats are rusty, but I would have thought 
it possible to calculate an error bar.

> netflow, you know that what you bill is never *more* than what the
> customer actually used (if you overflow your TCAM or drop records,
> you err on the side of the customer, which is OK) - but if you sample,
> and then apply a correction factor, you could bill them too much, and
> that's problematic.

Indeed. We face a similar (non-monetary) issue locally, that I won't go 
into. But suffice to say that sampled netflow would make our lives hard 
in that area on the basis of arguing cases, not technology.

> Of course you don't want to bill based on any sort of IP accounting data,
> but that cannot always be avoided either :-)

Well, as I understand it a quantity-based billing model is not uncommon. 
And it's not like SNMP counters are awesomely reliable on some platforms 
either:

"We upgraded IOS and now the counters are all in octal, port-channels 
count backwards, and jumbo frames are counted as IPX..."

...allright, slight exaggeration!

And of course, counters can't do SCU/DCU :o(


More information about the cisco-nsp mailing list