Wednesday, October 13, 2010

IPv6 Addresses - SLAAC

IPv6 has two methods that an interface can use to be assigned an address.  The first is the SLAAC, (StateLess Address AutoConfiguration) method, and the second is DHCPv6 (another post).

IPv6 addresses, besides being obviously longer than IPv4 addresses, are not terribly different from IPv4.  In most unicast addresses, the high order 64-bits are for the subnet mask (also called the prefix length) definition and the lower order 64-bits are for host addresses just as the IPv4 address can be broken into subnet and host values.  It is these addresses we will focus on address assignment with.  If you want more on specifics on IPv6 addresses types, go read Wikipedia.

SLAAC uses the aforementioned Router Advertisements to get the network configuration that the address will need for the higher order bits.  This will define how the subnet masks and gateways should be set.

The low order bits are then picked usually using one of two methods, EUI-64 or Privacy Extensions.  EUI-64 takes the MAC address of the interface, splits the 12 high and low order bytes in half and sticks 'FF:FE' between them.  When concatenated to the high order bits, we should now have an IPv6 address that should be completely unique.  Unfortunately it also means that the IP address is completely trackable globally, and this is a bad thing from a privacy perspective.

So, someone came up with Privacy Extensions.  Privacy Extensions adds some randomness to the IPv6 address creation function, which changes under a variety of scenarios.  This solves the problem of privacy, but can often make the IPv6 addresses difficult to track... an issue I will go into length about later.

Network configuration was a different thing back in 1998.  Nowadays IPv4 addresses are tightly controlled tracked and managed.  A device deciding on its own address is completely unheard of.  If your policies depend on that level of management, we've hit upon your first and possibly biggest hitch in managing IPv6 address space because DHCP, a common solution to IP address management problems, has a similar service available called DHCPv6.  But as we will see, it works very differently.

Wednesday, September 22, 2010

Neighbor Discovery Protocol: Part 3 - To Find Routers

NDP has one last really interesting feature.  NDP is responsible for announcing routers.  This is the first really new-to-us feature we've come across.

As anyone who has tried to manage a network knows, configuring the hosts on it can be difficult and tedious using static addressing.  DHCP is a necessary feature.  With the increase of address space, the lack of a true broadcast, etc, the thoughts of the designers was that the network could configure itself.  IPv6 can configure itself (we'll talk about how later), but one of the mechanisms it uses to pass data on network configuration to a host is via a 'Router Advertisement'. 

Router advertisements contain details of how network hosts should be configured and what the network looks like from the client's perspective.  It only contains IP addressing details and NOT DNS/NTP/WINS and other such features we expect from DHCP.  Oh, and router advertisements are ideally _only_ sent by routers.

In 1998, the term 'router' was very specific.  Routers were run by network administrators, and very few OSs (and even fewer deployed) that had the features to route traffic in any sort of robust fashion outside of a device specifically built to route packets.  NAT devices were not as widespread as they are now.  So in 1998, it was completely expected that only routers would want to advertise routes.  This is somewhat laughable in 2010, but this is how it works.  It is a non-negotiable function of the protocol.

A device which presents as a 'rogue router' works in much the same way as a 'rogue DHCP' server.  It would have the potential to knock a system offline.  There is a priority feature, so what happens to hosts depends on what a client's default behavior is, what the legitimate routers are doing, and what the particular circumstances of the rouge router is.  We're going to talk about some of the security issues around this later, but lets move on to what these route advertisements are used for.... configuring IPs.

Saturday, September 18, 2010

Neighbor Discovery Protocol: Part 2

When we last left NDP, we were talking about ARP, and why it won't do what we want it to do.

From RFC 4681:
IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers, and to maintain reach-ability information about the paths to active neighbors.
In other words, its more than ARP, its an Adventure!  Let's go through each one of these.

"To determine each other's presence, to determine each other's link layer addresses"
So, this is the original ARP protocol's functionality. ARP determines if an address within a subnet is contactable and determines what addresses are configured on specific hosts. A quick tcpdump of such a packet looks like this:

22:15:26.847304 IP6 fe80::a14a:be36:4596:890d > ff02::1:ff89:7f9d: ICMP6, neighbor solicitation, who has fe80::81a0:12e8:7e89:7f9d, length 32

This is an ICMPv6 packet (more on ICMPv6 later) which is called a 'neighbor solicitation' which queried a well known multicast address called the "all-nodes multicast address" (which sounds like a broadcast, and effectively is, but its not... just trust me on this for now).  In the same fashion as ARP, the machine with this address responds with a 'neighbor advertisement' via unicast (more on unicast vs. multicast later). 

This process happens completely in the IPv6 layer.  There are no MAC addresses being passed back and forth and we've eliminated broadcast traffic.  So in this one feature, we've completely replaced ARP already.

"to maintain reach-ability information about the paths to active neighbors" 
(Yes, we skipped one)

Because there is a looser coupling between MAC addresses and IPs, and because we want to reduce the need to broadcast things on the network (which still means less packets to the "all-nodes multicast address"), NDP includes a way to check on whether one node can still reach another node and sends the same 'neighbor solicitation' messages via unicast.  This only happens when traffic is actively being sent to the host to eliminate reliance on protocols further up the chain to do the right thing.

I think we'll talk about finding routers tomorrow.

Neighbor Discovery Protocol, Part 1: The History

IPv4 networks are interconnected with routing protocols to move data between networks of different institutions.  An institution's network might be subdivided into sub-networks or 'subnets' that also use routing protocols at the IP later, but inside a subnet IPv4 needs to interact with another protocol called ARP.  The Address Resolution Protocol is another old protocol used to help two PCs connect to each other by mapping Ethernet(MAC)addresses (Layer 2) to IPv4 addresses (Layer 3).  Computers keep track of these addresses in small tables and one can almost universally look at this table on a command line by typing 'arp -a', so give it a shot to see what I mean..

ARP uses Ethernet broadcasts to find machines who have a specific IPv4 address.  Essentially, one PC sends a particular 'request' packet out on the network to a specific Ethernet address which is heard by all devices on a subnet, and waits for responses which are directly sent to the requester from a station that knows.  Because of this behavior, ARP is sometimes considered a layer violation, although a necessary one.

There are several issues with this protocol which makes it unwelcome in the IPv6 space.
  • Its not a pure IP solution.  We don't like mixing our Ethernet and our IPv4, and we don't need to in IPv6 if we fix this right.
  • It relies on broadcasts, which we'd like to minimize if at all possible because IPv6 makes our subnets real big and we don't want network-wide broadcasts on real big networks.
  • There is a lot more that can be done with the idea of mapping IPs in a subnet, but ARP only maps IP addresses to physical MAC addresses.  Its a one trick pony. 
IPv6 addressed these problems with a new protocol, NDP,or the Neighbor Discovery Protocol. More in Part 2 tomorrow.

Thursday, September 16, 2010

IPv4 vs IPv6

Although the implied version increase that comes in the names of those two protocols might suggest something better in IPv6, I will once again reiterate that things are just different.

Much has been said about the physical differences in the packets and one can look them up if they want to see them.  I just want to focus on a few points.

Quality of Service in now deeply embedded in the packet in two fields, traffic class (sometimes called priority) and flow label.  This allows routers to more efficiently handle packets according to some sort of administrative schema.  There is no real need for routers to guess at how the packet should be handled.   This essentially replaces the ToS field of an IPv4 packet, which is currently used to provide QoS through Diffserv.
Pre-1998, this was very, very important to network connections which were often overwhelmed, even then, with the various types of real-time vs. best-effort data streams.  Today, you get bandwidth fire-hosed at you, so there is less and less of a need for this the closer you get to the network edge.  Its still terribly important for IP Phones, teleconferencing, and other applications where near perfect 'real-time' no-latency delivery is necessary, but I don't see much use beyond applications like that.

'Next Header' replaces anything resembling a protocol field.  It is used so that rather than track a protocol following a specific format and size, a packet can just contains what the next header is.  When a device needs that next layer, it just jumps down the packet.  More than one header might exist in the packet, and we'll talk about some of the ramifications of this later.

There are two other things one should notice.  Number one, the lack of an IP checksum in v6, which is almost a direct result of the stability of networks and the acknowledgment that layers above IPv6 often have checksumming routines in them.  Additionally, basic IPv6 packets, are a uniform size.  This drastically speeds up processing of packets in routers.   Designers realized networks are getting larger, both in bandwidth and in users, and making the protocols as fast as efficient as possible was a good idea.

The goal here was efficiency.  Routers were limited in CPU, memory, and bandwidth available.  It was critical to wring out as much in IPv6 as possible.  IPv6 packets are larger and routers need all they can get to push packets around.  This is as much true today as it was then, maybe even more so since large companies push several gigs a second, which is a far cry from 1998.

Please note, I didn't use the word 'security' once in that post.  I didn't need to, there is no more security there than in IPv4.

Wednesday, September 15, 2010

Before we get too far...

... Lets talk about where we've been.

IPv4 is an old protocol, devised when the world was young.  It is battle hardened and well tested.  Its design goals were to have a reasonably scalable network, connecting the only places on the planet that could support a computer network (which was believed to be a very finite number on the order of a few hundred, a thousand at most).  It was made to withstand a nuclear explosion due to its distributed nature.  It was made to ride the dozens of physical layer types that the average international connection might need to traverse.  There was no security, and everyone was connected to everyone else provided there was a path.  Networks were simple, subnets were large, and systems did relatively few things, mostly via the existing methodologies of the time like terminal traffic and the occasional file transfer.

Society has added to it over the years, bolting on more and more, changing methodologies as we go.  Now, there are so many computers we have to rigorously maintain our subnets using many administrative services and tools.  The market produces thousand of devices which monitor, block, augment, and transform data as it passes through it.  All the tools are well-documented, robust, and work within common expectations.  Almost everyone and everything is connected via Ethernet over copper or fiber.  When I choose to use a sniffer, I can be reasonably assured its going to detect all layers properly until I get to the layer I'm trying to debug.

IPv6 throws all those preconceptions out the window.

IPv6 is a completely separate protocol.  Put anything you know out of your head, it will be easier to deal with.  IPv6 has nothng to do with IPv4 except it has the letters 'I', 'P', and has some similar fields .  It was ratified in 1998 and was designed to better handle a number of scenarios, most notably the limited size of the addressable fields in IPv4.  In IPv6, networks can configure themselves, handle larger packets, configure themselves, and handle scenarios that were foreseeable in 1998.

I want to stress the fact this was ratified in 1998.  That puts its 'standardization' well before many of the mass-infection viruses in the early part of the last decade, well before the ubiquity of wireless, well before rapid, often mindless, deployment of security 'tools' and 'policies' of all kinds.  These are things IPv6 was not designed to solve.  IPv6 has some security mechanisms, but many are bolted on, just like IPv4.  If you are planning to deploy IPv6 and instantly get a security network, you are mistaken.

Despite IPv6's standardization over a decade ago, few have adopted it, even to this day.  This means it is likely the current assumptions you have for your network (That the protocol works, has no bugs, is handled consistently by all parties on your network, is supported by all the tools and software you have, and meets the needs of current policy and procedures, etc) are wrong.

Welcome to IPv6.

Wednesday, August 11, 2010

IPv6 Posts

I'd like to begin talking about IPv6 here and I will starting soon. For now, I will simply point at Teredont and go about my day.

UPDATE: I'm going to start by spending a lot of time talking about how IPv6 works and some of its major features first, and we'll get to the security features later once we have some context to build from.

Wednesday, July 21, 2010


So, I wrote a small program in 2000/2001 called Placid which was a web front-end for Snort. It was meant to address several problems in which was then the most popular package, ACID.

I used it for 9 months, and had a number of issues with it.
  • Requirements - This was PHP back in The Day. There was no easy way to do anything. There were plenty of libraries that needed to be configured Just So. Getting everything configured was tricky and somewhat buggy.
  • Multiple database hits per page load
  • Additional tables
  • Temporal data added into tables at page load time
  • PHP
Placid, 1.0, directly addressed most of these issues.
  • One Requirement, MySQLdb, a python-mysql connector
  • One database hit per page load
  • No additional tables
  • No temporal data (I begrudgingly added name resolution in a future version)
  • Python
As one might imagine, this significantly sped up the application and allowed the database to max out(at the time) to 15 million events on the same hardware that used to choke at 1 million. Modern systems get close to 60 million. There are still problems though, which I hope to address soon, mainly...

  • Fixed query engine results, there is no custom searches that can be performed
  • No PostgreSQL support, which is a problem for some places (and another blog post later)
  • Inefficiencies in programming and query generation has cropped up as features have been added over the years. Not to mention the improvements to Python in 10 years.
  • No graphing, probably the single-most missed feature.
  • No saving commonly used queries.
Enter Placid 3.0, once I start working on it...

Monday, June 28, 2010

Because you gotta have goals....

This blog is my attempt to create more, and share more, without waiting for everything to be perfect.

This blog is a learning tool, for me more than others. I'm sure I will say things here that are wrong. I will attempt to correct them. I will be as detail-driven as possible.

This blog will be a tool for me, to help communicate about the tools I create.

This blog will be about information security technology, security process, and other relevant things. Although I'm sure they will creep in, this blog will not be so much about news tidbits, opinions about The-State-Of-Things, my personal life, and other such nonsense.

Hello World.