4 ms·

TLV (http://en.wikipedia.org/wiki/Type-length-value http://en.wikipedia.org/wiki/Type-length-value) isn't recognisable as a protocol. It is something you'd have

TLV (http://en.wikipedia.org/wiki/Type-length-value http://en.wikipedia.org/wiki/Type-length-value) isn't recognisable as a protocol. It is something you'd have to hand-roll, i.e. serialize to. The resulting byte array would be encrypted using anything you like (I'm using RSACryptoServiceProvider), so it'd be unrecognisable to DPI. Not being familiar with specific DPI implementations I would imagine if such filtering was white list -based then anything unrecognisable would be blocked?

colanderman 15y ago
The obvious workaround is to uuencode your TLV data and then wrap it in <HTML><PRE></PRE></HTML>. If it's properly formatted HTML, and the body isn't recognizable as, say, a ZIP file, DPI will pass it. Granted, someone could do entropy detection, and e.g. pass only things that look statistically like valid English/Persian/etc. text. But that needs more compute power, and can be worked around as well using statistical methods similar to Huffman coding.
- Spearchucker 15y ago
  It'd be awesome to hear from someone with product experience. My experience of DPI is limited to Tenix diodes (which are white-list based, and are more focused around stripping malicious code by converting known objects to another format, eg .jpg to .png and back, or Word to PDF and back), or McAfee's Secure Web (used to be Web Washer), which does URL filtering, SSL scanning, etc. Also white list based.
  - colanderman 15y ago
    The DPI in the product I work on is blacklist- and standards-based. i.e. it involves actually parsing most common formats, making sure that they are valid documents with no out-of-bounds values that could cause e.g. buffer overflows, and blacklisting known attacks. FWIW our product can do this very quickly (we sell a 1U which can inspect 8 Gb/s).

4 ms·

TLV (http://en.wikipedia.org/wiki/Type-length-value http://en.wikipedia.org/wiki/Type-length-value) isn't recognisable as a protocol. It is something you'd have

by Spearchucker 15y ago

colanderman 15y ago
The obvious workaround is to uuencode your TLV data and then wrap it in <HTML><PRE></PRE></HTML>. If it's properly formatted HTML, and the body isn't recognizable as, say, a ZIP file, DPI will pass it. Granted, someone could do entropy detection, and e.g. pass only things that look statistically like valid English/Persian/etc. text. But that needs more compute power, and can be worked around as well using statistical methods similar to Huffman coding.
- Spearchucker 15y ago
  It'd be awesome to hear from someone with product experience. My experience of DPI is limited to Tenix diodes (which are white-list based, and are more focused around stripping malicious code by converting known objects to another format, eg .jpg to .png and back, or Word to PDF and back), or McAfee's Secure Web (used to be Web Washer), which does URL filtering, SSL scanning, etc. Also white list based.
  - colanderman 15y ago
    The DPI in the product I work on is blacklist- and standards-based. i.e. it involves actually parsing most common formats, making sure that they are valid documents with no out-of-bounds values that could cause e.g. buffer overflows, and blacklisting known attacks. FWIW our product can do this very quickly (we sell a 1U which can inspect 8 Gb/s).