This is totally off-topic, but I saw this and it made me really angry. I used to love skateboarding when I was a kid, and the thought of grown adults shoulder-charging young kids off skateboards is just disgusting.
Today At Vic Park from NZskate.com on Vimeo.
In other news, I've been playing with the source code to BIRD to see if I can put in some hooks to make it work with NOX. It has a set of OS-specific "kernel" modules which install routes into the OS routing tables, so it shouldn't be hard to make a NOX version of this.
Another option would be to monitor the MRT dump file, or point it at a named pipe - then get NOX to use that to pick up updates.
One thing that Nick Buraglio pointed out was that BIRD is in need of an IS-IS implementation. IPv6 has been a good excuse to move from OSPF to IS-IS because it all runs in one instance - not requiring OSPFv2 and v3 instances for IPv4 and IPv6. Time will tell if there's still a place for decentralised IGP's in an OpenFlow world, but if we're going to see an influx of software routers, then IS-IS will definitely be added in the next year or two. (edit - somebody's beaten me to add this to quagga http://code.google.com/p/google-quagga/)
More details once I get BIRD talking to NOX though!
Showing posts with label ipv6. Show all posts
Showing posts with label ipv6. Show all posts
Monday, March 26, 2012
Saturday, March 17, 2012
Multicasts and Broadcasts and Flows, oh my!
Background
If you've set up pyswitch and NOX with Open vSwitch then you'll notice that any packets that don't match a flow get sent to the Openflow controller. If you set no flows, the controller receives every packet, until either you or the controller adds flows. Pyswitch will set flows for unicast traffic, but what happens when you start getting a substantial amount of background multicast/broadcast traffic?
A standard NOX setup can handle 10 flows per second. This means it can set up flows to handle 10 new hosts, or 10 different protocols, or it can simply return 10 packets to the switch and tell it to flood them.
Can you see the potential problem here? Any medium-to -large sized network will have all sorts of background multicast/unicast traffic, here are some of the things that will generate broadcast/multicast traffic on your network:
Just right-click on the IG bit, then go Apply as Filter -> Selected, and from now on, you'll only see multicast/broadcast packets. Here are some examples of what you might see on your network
If you've set up pyswitch and NOX with Open vSwitch then you'll notice that any packets that don't match a flow get sent to the Openflow controller. If you set no flows, the controller receives every packet, until either you or the controller adds flows. Pyswitch will set flows for unicast traffic, but what happens when you start getting a substantial amount of background multicast/broadcast traffic?
A standard NOX setup can handle 10 flows per second. This means it can set up flows to handle 10 new hosts, or 10 different protocols, or it can simply return 10 packets to the switch and tell it to flood them.
Can you see the potential problem here? Any medium-to -large sized network will have all sorts of background multicast/unicast traffic, here are some of the things that will generate broadcast/multicast traffic on your network:
- ARP requests
- DHCP requests
- SSDP messages (from any UPnP-enabled device)
- SMB/NetBIOS (windows machines)
- Bonjour/mDNS (Apple / anything with iTunes)
- IGP routing protocols
- Spanning tree
- IPv6 router-advertisement messages
Taking a closer look
If you fire up wireshark you can filter on these messages
What's worse is that if you sit and watch, you'll see groups of packets show up in large groups at a time - SSDP, mDNS and NBNS all send 5-10 packets at a time, and with a standard Openflow controller-switch setup, these 10 packets will pause your network for a whole second.
The solution
With Open vSwitch, you have a few options - you could add all your flows manually, or you can delegate that to an Openflow controller. For something like this however, you can add a flow that makes your switch automatically flood any multicast/broadcast traffic, leaving your Openflow controller to focus on unicast traffic.
The ovs-ofctl documentation gives us an easy answer - set a flow that masks the group address bit as follows:
ovs-ofctl add-flow br0 priority=65500,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00,actions=flood
That was easy! If you want to do IGMP or MLD snooping, you can add flows with higher priorities - but first have a look at how much IP multicast traffic is on your network already - remember, 10 flows per second is probably your limit.
ovs-ofctl add-flow br0 priority=65500,dl_dst=01:00:5e:00:00:16,actions=controller
ovs-ofctl add-flow br0 priority=65500,dl_dst=33:33:00:00:00:16,actions=controller
The first flow will match IGMP traffic, and the second will match MLDv2 (IPv6 version of IGMPv3) traffic, but both versions of MLD unfortunately need more complicated flows, MLDv1 uses the all-local-nodes address, and even though MLDv2 has its own address, the MAC address 33:33:00:00:00:16 is valid for any IPv6 multicast address that ends in :0:16.
Has anyone done IGMP/MLD snooping on an Openflow controller yet? It's probably outside the scope of my current project, but it should be easy enough to build into Pyswitch if someone had the time. Let me know if you've done this, my twitter is @samrussellnz
Friday, October 22, 2010
IPv6 WEP cracking
Those of you with interests in security will no doubt know how trivial it is to break WEP keys using a known-plaintext attack to recover the first 16 bytes of keystream for each packet, and then executes the PTW attack once there are about 20,000-80,000 packets captured. The original known-plaintext attack for IPv4 relied on the predictability of the first 16 bytes of ARP packets, the first 8 being the LLC header (always the same) and the first 8 bytes of the ARP header (the same except for the last byte, but this is predictable based on the MAC addresses - ARP requests are broadcast, ARP replies are unicast). Gathering ARP packets was made even easier due to the ARP replay attack - where a captured ARP request is replayed to quickly generate large numbers of ARP replies, each encrypted with a different IV.
The PTW attack with its ability to determine non-consecutive key bytes made a passive attack more feasible too - normal IP packets can be used, and the two bytes which are assumed to be random (the identification field) can be bruteforced.
Unfortunately, WEP was more or less left untouched after 2007, with a few extensions to the PTW attack, and reapplication of KoreK's correlations, but there doesn't appear to be an IPv6 version of this yet (EDIT: aircrack actually decrypted the dump of my ipv6 test). IPv6 requires that we find ways of implementing both a replay attack, and a passive attack, however it appears that they have a lot more in common on IPv6 than they did under IPv4.
Because IPv6 uses ICMPv6 instead of ARP for its neighbour discovery (RFC 4861), only an attack on the IPv6 header is required, which makes life easier. So assuming the LLC header stays the same (will confirm later), let's have a look at the first 8 bytes:
Byte 0.5: Version (6) - this is trivial if we know the network is running IPv6 (can infer this from IPv6 multicast MAC addresses)
Bytes 1-4: Traffic class and Flowlabel - 0 if no QoS/MPLS is implemented
Bytes 5-6: Payload length (can be deduced from packet length)
Byte 7: Next header (is probably going to be TCP, UDP or ICMP)
Byte 8: Hop limit (I've seen 255 and 1 for local packets, 128 for leaving packets, and various numbers for packets received from outside the LAN).
As we can see, quite a bit of this can be easily guessed. If we're simply intercepting LAN traffic, then it's unlikely that the traffic class and flow label fields are giong to be used, making our first 4 bytes 0, the payload byte is guessable (total 6 predictable bytes so far). The next header field is in practise only going to be one of 3 values (and if the length matches can be assumed to be ICMP, or if it is too long can be assumed to be TCP/UDP), which leaves us with the hop limit field, which can easily be bruteforced (as the current IPv4 attack shows that bruteforcing 2 bytes is feasible).
For a replay attack, an ICMPv6 Neighbour solicitation packet is required. Unfortunately for us, there is no obvious way to distinguish between solicitation and advertisement packets, so it is somewhat trial and error, at least when unicast solicitations happen. From what I've seen in my (incredibly limited) tests, these happen more frequently than ARP exchanges on IPv4, which should make it easier to capture neighbour solicitations.
Neighbour solicitation/advertisement packets are always 64/72 bytes long (only counting the IPv6 and ICMP headers + payload), so packets of this length can be assumed (possibly incorrectly) to be neighbour solicitation/advertisements, which gives us a 50/50 chance of getting a solicitation packet. But what if we have an advertisement, and want to convert it into a solicitation, what do we need to do?
Firstly, the type needs to be changed from 136 to 135. Secondly, the field that was used for flags is reserved in the solicitation packet, so this should be zeroed (trial and error on the 3 currently used bits, or just assume the recipient is going to ignore this field). Thirdly, if the option is set (dest link-layer address) this needs to be changed, which can easily be done by xoring the MAC addresses from the unencrypted link layer header. This leaves us with one final problem - swapping the source and destination IP addresses from the IP header. To do this would require inside knowledge, and it is probably easier to break the WEP key passively than try and guess these, but what would we need to do if we could figure them out? The checksum used here isn't cryptographically secure, and can be updated in the same way as the WEP ICV because we know which bits have been altered, so the packet can then be used for replaying... but this isn't realistic.
In summary:
References:
The PTW attack with its ability to determine non-consecutive key bytes made a passive attack more feasible too - normal IP packets can be used, and the two bytes which are assumed to be random (the identification field) can be bruteforced.
Unfortunately, WEP was more or less left untouched after 2007, with a few extensions to the PTW attack, and reapplication of KoreK's correlations, but there doesn't appear to be an IPv6 version of this yet (EDIT: aircrack actually decrypted the dump of my ipv6 test). IPv6 requires that we find ways of implementing both a replay attack, and a passive attack, however it appears that they have a lot more in common on IPv6 than they did under IPv4.
Because IPv6 uses ICMPv6 instead of ARP for its neighbour discovery (RFC 4861), only an attack on the IPv6 header is required, which makes life easier. So assuming the LLC header stays the same (will confirm later), let's have a look at the first 8 bytes:
Byte 0.5: Version (6) - this is trivial if we know the network is running IPv6 (can infer this from IPv6 multicast MAC addresses)
Bytes 1-4: Traffic class and Flowlabel - 0 if no QoS/MPLS is implemented
Bytes 5-6: Payload length (can be deduced from packet length)
Byte 7: Next header (is probably going to be TCP, UDP or ICMP)
Byte 8: Hop limit (I've seen 255 and 1 for local packets, 128 for leaving packets, and various numbers for packets received from outside the LAN).
As we can see, quite a bit of this can be easily guessed. If we're simply intercepting LAN traffic, then it's unlikely that the traffic class and flow label fields are giong to be used, making our first 4 bytes 0, the payload byte is guessable (total 6 predictable bytes so far). The next header field is in practise only going to be one of 3 values (and if the length matches can be assumed to be ICMP, or if it is too long can be assumed to be TCP/UDP), which leaves us with the hop limit field, which can easily be bruteforced (as the current IPv4 attack shows that bruteforcing 2 bytes is feasible).
For a replay attack, an ICMPv6 Neighbour solicitation packet is required. Unfortunately for us, there is no obvious way to distinguish between solicitation and advertisement packets, so it is somewhat trial and error, at least when unicast solicitations happen. From what I've seen in my (incredibly limited) tests, these happen more frequently than ARP exchanges on IPv4, which should make it easier to capture neighbour solicitations.
Neighbour solicitation/advertisement packets are always 64/72 bytes long (only counting the IPv6 and ICMP headers + payload), so packets of this length can be assumed (possibly incorrectly) to be neighbour solicitation/advertisements, which gives us a 50/50 chance of getting a solicitation packet. But what if we have an advertisement, and want to convert it into a solicitation, what do we need to do?
Firstly, the type needs to be changed from 136 to 135. Secondly, the field that was used for flags is reserved in the solicitation packet, so this should be zeroed (trial and error on the 3 currently used bits, or just assume the recipient is going to ignore this field). Thirdly, if the option is set (dest link-layer address) this needs to be changed, which can easily be done by xoring the MAC addresses from the unencrypted link layer header. This leaves us with one final problem - swapping the source and destination IP addresses from the IP header. To do this would require inside knowledge, and it is probably easier to break the WEP key passively than try and guess these, but what would we need to do if we could figure them out? The checksum used here isn't cryptographically secure, and can be updated in the same way as the WEP ICV because we know which bits have been altered, so the packet can then be used for replaying... but this isn't realistic.
In summary:
- WEP is still a stupid idea
- If QoS and MPLS aren't being used, the passive attack is easier than under IPv4
- The new "ARP" replay attack should work just as well as the old one
References:
- Breaking 104 bit WEP in less than 60 seconds
- http://tools.ietf.org/html/rfc4861
- http://tools.ietf.org/html/rfc4443
Friday, October 15, 2010
IPv6: The final frontier
My lecturer Andy Linton was going into detail about IPv6 the other day and suggested I sign up to sixxs.net and get my home network running IPv6, so I did just that.
They use a system where you get given a certain amount of credits when you sign up, spend them to make changes to your account (adding/deleting tunnels and subnets etc) or when your connection times out, and slowly accumulate them for keeping your tunnel open for a long period of time. There are three different types of tunnel - static IP with straight 6-in-4, dynamic IP with the heartbeat protocol to notify of any IP changes which also uses straight 6-in-4, and a system called AYIYA (anything in anything) which encapsulates IPv6 in UDP.
Thinking that my brand new router would be able to route IPv6 without any issues (or at least 6-in-4) I mistakenly signed up for a heartbeat tunnel, only to find out that short of explicit routing I would need to have a DMZ server set up... so I settled on the AYIYA protocol in the end.
I got their AICCU client set up, it has a package in the debian repository which made everything really easy, and the only moderately hard bit was making sure I removed all the autoconf IPv6 addresses from eth1 (long story why I don't have eth0 but it's a testament to my unsuitability as a system admin) before adding new ones, only to find that all the original addresses were fe80::/64 anyway so the whole exercise was almost a total waste of time.
After configuring my addresses on my windows 7 box (todo: install DHCPv6 server) and rebooting bind, everything was pinging fine, but none of my browsers would go to IPv6 websites. I assume it's to do with not having a global subnet yet, so that'll have to wait until after my subnet request gets approved.
Todo:
Choose a firewall (ufw? modify my old iptables script?)
Firewall server (because a global IPv6 address is going to take me back to dialup days where no password = free access to SMB shares, but that's another story for another day)
Install DHCPv6 (I've ALWAYS wanted to have a DHCP server that hands out global IP addresses)
Configure DNS (I'm thinking I'll keep my dummy 10.1.1.* records for my domains that are hosted locally, but add some reverse DNS entries once I get that delegated)
They use a system where you get given a certain amount of credits when you sign up, spend them to make changes to your account (adding/deleting tunnels and subnets etc) or when your connection times out, and slowly accumulate them for keeping your tunnel open for a long period of time. There are three different types of tunnel - static IP with straight 6-in-4, dynamic IP with the heartbeat protocol to notify of any IP changes which also uses straight 6-in-4, and a system called AYIYA (anything in anything) which encapsulates IPv6 in UDP.
Thinking that my brand new router would be able to route IPv6 without any issues (or at least 6-in-4) I mistakenly signed up for a heartbeat tunnel, only to find out that short of explicit routing I would need to have a DMZ server set up... so I settled on the AYIYA protocol in the end.
I got their AICCU client set up, it has a package in the debian repository which made everything really easy, and the only moderately hard bit was making sure I removed all the autoconf IPv6 addresses from eth1 (long story why I don't have eth0 but it's a testament to my unsuitability as a system admin) before adding new ones, only to find that all the original addresses were fe80::/64 anyway so the whole exercise was almost a total waste of time.
After configuring my addresses on my windows 7 box (todo: install DHCPv6 server) and rebooting bind, everything was pinging fine, but none of my browsers would go to IPv6 websites. I assume it's to do with not having a global subnet yet, so that'll have to wait until after my subnet request gets approved.
Todo:
Choose a firewall (ufw? modify my old iptables script?)
Firewall server (because a global IPv6 address is going to take me back to dialup days where no password = free access to SMB shares, but that's another story for another day)
Install DHCPv6 (I've ALWAYS wanted to have a DHCP server that hands out global IP addresses)
Configure DNS (I'm thinking I'll keep my dummy 10.1.1.* records for my domains that are hosted locally, but add some reverse DNS entries once I get that delegated)
Subscribe to:
Posts (Atom)