[pcap-ng-format] Proposal for EPB Hash Option (1 of 4)

[Hadriel Kaplan]

On Tue, Sep 1, 2015 at 3:48 PM, Michael Haney <michael-haney at utulsa.edu> wrote:
> The use case (broadly anyway) is for information sharing and preserving
> privacy. That is, sharing enough but not too much. Think of a
> telecommunications company or ISP or public hotspot provider sharing data
> with a law enforcement agency and only sharing the flows of interest to an
> investigation, not the entire capture. Access to full packet capture data of
> the suspect needs to be carved out to keep from sharing all of the customer,
> client, or employee data. So the 'raw' capture file needs to be manipulated
> somehow. Many suggest 'anonymization' techniques which I would argue don't
> work. So how does one show that the data captured at the time and place
> captured hasn't been tampered with? The SHB and IDB are still required parts
> of the new file, and the epb_hash provides assurance that goes back to the
> original capture.

But you can have that assurance (or lack thereof) even without the
hash - the contents of the packets are there to see. The epb_hash was
not a true HMAC - it had no authentication property, because it didn't
use a secret of any kind. It was just a hash of the packet, and could
have just as easily been ROT13. :)

So anyone could change the packet contents, recalc+replace the hash
result. The only thing preventing that from succeeding would be either
changing it to be an HMAC, or protecting it with something else that
detects changes to it. But that "something else" would also be
protecting the actual packet contents from manipulation, in which case
you don't need the epb_hash either in that case.


> Also, if not for data integrity, what then is an individual block hash good
> for? There are plenty of better (more efficient) ways to de-dupe packets
> during the analysis phase.

Yup, and the other use-case for it was to detect transfer errors. But
it appears neither of those use-cases are really practical, so the
option hasn't been used (as far as I know).


> It's not perfect. If packets are omitted, there's no indication with this
> option alone. If packets are modified, a malicious user can regenerate the
> hash. It needs to be protected with a keyed hash or HMAC and encrypted, and
> key management is a big issue. Hence, DUKPT and the other pieces.

Right, but at that point you don't need an epb_hash of the packet -
you have the whole EPB already, and you can use a real HMAC or
whatever to protect the whole thing. I.e., create a HMAC option for
the "Encrypted Block", if you need an HMAC.


> But I don't think we should get too bent out of shape about it, given that
> it's optional. Wireshark and other tools don't appear to have trouble
> ignoring it. I could write it to be epb_alt_hash or something, give it a
> different code value, and leave the current option defined as it is. I
> think, though, that the current lack of specificity might be a reason the
> current option doesn't appear to be in wide use.

I really doubt it - my guess is it's not in wide use because it's a
waste of time, for its originally intended uses. Otherwise whomever
wanted to use it would have asked exactly how to encode it. Or maybe
they made an educated guess and do use it - I don't know. But anyway I
think it's safer to "deprecate" the old "epb_hash" number by reserving
the number but not describing how to use it in the draft document.
It's not like we're running out of option codes anytime soon anyway.
:)

-hadriel

p.s. I'm not trying to argue or get bent about it - it's hard to
convey emotion in email! - I'm just trying to understand your
proposal, and just think the legacy "epb_hash" option is useless.