Reading Time: 4 minutes
In IT and IT Security there is a constant complaint about the risks of shadow IT, and the adoption of consumer collaboration and sharing tools. Over the last couple of years we also saw the emergence of novel exfiltration techniques including the persistent ultrasonic technique, where the infected devices communicates with other compromised hosts via high frequency; or the Twitter based technique, where malware sends out data 140 characters at a time for anyone to read; and the more recent Video technique, encrypting data in video files and putting corporate secrets onto video sites or later retrieval.
Reading Time: 1 minutes
It’s official, after an eight (8) month stint in the back of house looking after new business for the delivery arm of the big T I’m moving back into a technical role.
Whilst I’ve learnt many things and worked with some great people, I really am looking forward to getting back into the thick of it, rather than watching from the sidelines. So this time next month I’ll have taken over the reigns of the Lead Security Architect for Telstra Enterprise and Government.
I have some pretty HUGE shoes to fill but I’m really looking forward to the challenge.
Reading Time: 3 minutes
I got a question late last night about the applicability of Baby Giants and Jumbo frames in an environment; the use of Ethernet frames above 1600 bytes and up to 9000 bytes. This had me reaching into the deep dark corners of my memory to respond. So I thought that I’d put it up here for posterity.
What are they:
Lets start with the basic Ethernet Frame. In short, and Ethernet frame is made up of a source address, a destination address, a type field, some data (the payload) and a checksum.
As you can see in the diagram below, you have 18 bytes of header and checksum with a variable payload component that can range from 46-1500 bytes; giving you a total frame size of 1518 bytes.
image source Wikipedia
Ethernet has had this frame format and payload size from about 1980 (please check the history if you want exact details) .
With the creation of Gigabit Ethernet came the ability to have bigger frames (well not really that simple, see previous link). A Baby Giant frame is any frame greater than 1600 bytes and a Jumbo frame is any Ethernet frame up to 9216 (plus header and checksum).
So why are we limited to ~9000 bytes? Part of the issue is that Ethernet uses a 32 bit CRC that loses its effectiveness above about 12000 bytes, see “32-Bit Cyclic Redundancy Codes for Internet Applications and 9000 is large enough to carry an 8 KB application datagram (e.g. NFS) plus frame header and CRC overhead.
Reading Time: 1 minutes
This is a half baked post today, but it is an attempt to get back into the swing of things.
One of the things on the “lists of posts to finish” is one on the emerging Data Centre technologies and the benefits that they they offer, or could offer, to the network Architect and Engineer. There have been some great articles written lately covering off NIV, FCoE and the odd article, and I do mean odd, about the wonders of RDMA over Converged Ethernet. One of the things I wanted to write about was TRILL. In a nutshell, TRILL is a L2 path selection algorithm (link state) designed to replace our good friend spanning tree.
Rather then bore you with my version of how it works and the benefits of TRILL to today’s design issues, have a look at the awesome write up done by @bradhedlund over at Cisco.
I’m still trying to find some time to get the back log of posts out of my head an onto paper/or here.