[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