Slashdot Mirror

Encrypted data cannot be meaningfully differentiated from compressed data

It doesn't really need to be. If you use the method like Shane Alcock uses in protoident, check the first four bits against a vector of known L7 protocols, you can usually determine the L7 protocol. You have to completely tunnel over HTTPS to keep the L7 protocol indistinguishable. Of course looking for information in the body of the packet trace_get_payload_from_* for an SSL handshake works too; but, it takes a lot more code and slows down your sensor. ie. regex'ing and sorting and chomping until you get what you want on every packet that doesn't have the SYN, FIN, or RST flag set.

visualising traffic on your internet connection. I wanted to do this at one place but boss said no :(

Friends of mine at Waikato University have produced "BSOD", a network visualizer which shows packets flowing between your subnet and the Internet. It's great on a big TV.

or SPAN port. Just great: http://research.wand.net.nz/software/visualisation.php

You just need a tap or SPAN port on your main Internet connection, plus a separate workstation with a reasonably good graphics card to run the visualisation.

I thought this would be just the thing for our reception area, but sadly my boss vetoed it. (I thought management were meant to like shiny.)

One of the major things to consider is that TCP's performance is also bound by the recieve window size[2]. Since TCP can only send more data as it's ACK'd due to this window, RTT plays a factor.

So also consider the "bandwidth delay product"[1] to where you're connecting to and compare this to your recieve window size. Consider checkking to make sure increasing your recieve window size won't get you better performance. This needs to be done at the end of the connection that's recieving the data, which for a checkin is likely to be in the UK...

Another thing is that TCP slows down whenever it sees loss as it considers loss to be due to congestion. The amount of time it takes to recover from this is based on round trips (ie latency again). This has a far more complicated formula to work out, see my webpage http://www.wand.net.nz/~perry/max_download.php for a simple calculator to work it out for you.

Since you're in India I suspect that the delay to your UK collegues is probably going to end up going the "wrong" way around the world and will therefore due to the speed of light in fibre your latency is going to be high.

[1]: Easily calculated by the obvious formula bandwidth*delay=recieve_window_size. Perhaps a more useful version of this is rwin/delay = maximum_tcp_bandwidth.
[2]: Not to be confused with the congestion window which is a different concept.

Road block.
Need to install another Hard Drive.
My 3Gb of 9 year old SCSI technology is full.

Not to the fault of a 190k BSOD, but because I need g++ version > 2.95.
And to install that version of g++ I need more space.

From the INSTALL file:

The bsod server requires:

* libtrace (http://research.wand.net.nz/software/)
* g++-3.0 or greater (known to work with 3.0, fails with 2.95)

In the famous words of Arnold: "I'll be back"

Try this http://research.wand.net.nz/software/visualisation .php

I work for a network research group ("WAND") at Waikato University in New Zealand. We have a similar visualisation which you can see various stages of evolution here, there are also some animations.

The universities internal network IP range is mapped onto the left hand face of the cube, the rest of the world is mapped onto the right face. They are mapped so similar addresses are clustered together and addresses further apart are uh, further apart. A box represents one packet, the volume of the particle is proportional to the size of the packet, and the colour is based on port number.

Also we "light" each end of the connection for a bit after the packet has been sent. So machines appear to be glowing in the colour of the traffic they are sending.

We use it to show off "networks" to people who think we just sit at computers and type into stuff, however it has been very useful to detect attacks and broken machines since they provde distinctive patterns. Portscans are a series of "sparkly" packets. Network scans are a row of marching lines. Virii infected machines appear as a cone centered on the infected machine.

I work for a network research group ("WAND") at Waikato University in New Zealand. We have a similar visualisation which you can see various stages of evolution here, there are also some animations.

The universities internal network IP range is mapped onto the left hand face of the cube, the rest of the world is mapped onto the right face. They are mapped so similar addresses are clustered together and addresses further apart are uh, further apart. A box represents one packet, the volume of the particle is proportional to the size of the packet, and the colour is based on port number.

Also we "light" each end of the connection for a bit after the packet has been sent. So machines appear to be glowing in the colour of the traffic they are sending.

We use it to show off "networks" to people who think we just sit at computers and type into stuff, however it has been very useful to detect attacks and broken machines since they provde distinctive patterns. Portscans are a series of "sparkly" packets. Network scans are a row of marching lines. Virii infected machines appear as a cone centered on the infected machine.