Month: September 2013

IPv6 First-Hop Security

All methods to mitigate IPv6 security issues
Real life security intro

In the process of configuring our corporate network test segment for IPv6, there was a direct demand to pay particular attention to security. It was my role to go trough all materials I could get to learn more about IPv6 security.

It was my role to go trough all materials I could get to learn more about IPv6 security. In that process, first stop was my favourite packetpushers podcast. They published more that 200 podcast till now and one of them was about IPv6 security that I needed. In that security show from last year

They published more that 200 podcast till now and one of them was about IPv6 security that I needed. In that security show from last year Healthy Paranoia Show 4:IPv6 Security Smackdown! Mrs. Y with bunch of great hosts discussed IPv6 security. They speak about almost all stuff that exists today in securing IPv6 enabled networks. One of the guests was Mr. Eric Vyncke, Cisco Distinguished Consulting Engineer who wrote IPv6 Security book for CiscoPress. Later, I did see that this book was everything you need to learn IPv6 security.  Of course, it’s easy to get edge router to run IPv6 on

One of the guests was Mr. Eric Vyncke, Cisco Distinguished Consulting Engineer who wrote IPv6 Security book for CiscoPress. Later, I did see that this book was everything you need to learn IPv6 security.  Of course, it’s easy to get edge router to run IPv6 on

Later, I did see that this book was everything you need to learn IPv6 security.  Of course, it’s easy to get edge router to run IPv6 on Internet-facing interface, but my goal is to get IPv6 inside our LAN environment and that part is still tricky if you include all the stuff needed to be done (especially on firewall part of the story).

I searched for additional information and some examples on how to configure Cisco gear for IPv6. Specially helpful were IPv6 webinars from long followed Networking/Cisco genius Ivan Pepelnjak at his great site ipspace.net (one of my homepage tabs). Here the guest is again Eric Vyncke.

After I gathered the knowledge out of those resources, I was ready to deploy IPv6 on my test segments and make it secure. Here are just a few rows about every one of IPv6 first-hop security features that are available on Cisco equipment. Just for the info, not all the equipment has all the features. Some of them came out

Here are just a few rows about every one of IPv6 first-hop security features that are available on Cisco equipment. Just for the info, not all the equipment has all the features. Some of them came out

Just for the info, not all the equipment has all the features. Some of them came out a few months ago so older switches and routers may not have all of these implemented. Sometimes you will be limited by the license to. I need to mention that other vendor’s equipment also supports most features mentioned below. For

I need to mention that other vendor’s equipment also supports most features mentioned below. For now it seems that Cisco invested the most effort and gathered the best team of engineers to add all possible features for IPv6 first-hop security inside IOS.

Let’s go with the list:

IPv6 RA Guard – RA messages are important part of IPv6 architecture. They are the only way to get default gateway info to host in the network segment (beside static configuration). DHCPv6 does not carry this information in his messages unlike DHCPv4. RA messages are Router Advertisement messages send from main router that is default gateway for that specific network segment. Having that in mind it’s clear that, only port on the switch that needs to receive RA messages inbound, is the port connecting the router. All other switch ports for hosts are only forwarding RA messages to host devices but there is no need for host to send RA messages back to switch. Even better, it is wrong if some host sends RA messages because he is then practically trying to take the role of default gateway away from router. Configuring RA Guard on all switch ports except port that heads towards the router is preventing rouge RA advertisements on that segment.

MPTCP – Multipath TCP

Intro

Multipath TCP is an extension of TCP that will soon be standardized by IETF. It is a succesful attempt to resolve major TCP shortcomings emerged from the change in the way we use our devices to communicate. There’s particularly the change in the way our new devices like iPhones and laptops are talking across network. All the devices like the networks are becoming multipath. Networks redundancy and devices multiple 3G and wireless connections made that possible.

Almost all today’s web applications are using TCP to communicate. This is due to TCP virtue of reliable packet delivery and ability to adapt to variable network throughput conditions. Multipath TCP is created so that it is backwards compatible with standard TCP. In that way it’s possible for today’s applications to use Multipath TCP without any changes. They think that they are using normal TCP.

MPTCP Protocol Stack from rfc6897

Basics

We know that TCP is single path. It means that there can be only one path between two devices that have TCP session open. That path is sealed as a communication session defined by source and destination IP address of communicating end devices. If some device wants to switch the communication from 3G to wireless as it happens on smartphones when they come in range of known WiFi connection, TCP session is disconnected and new one is created over WiFi. Using multiple paths/subsessions inside one TCP communication MPTCP will enable that new WiFi connection makes new subsession inside established MPTCP connection without braking TCP that’s already in place across 3G. Basically more different paths that are available will be represented by more subsessions inside one MPTCP connection. Device connected to 3G will expand the connection to WiFi and then will use algorithm to decide if it will use 3G and WiFi in the same time or it will stop using 3G and put all the traffic to cheaper and faster WiFi.

TCP single path property is TCP’s fundamental problem

In datacenter environment there is a tricky situation where two servers are talking to each other using TCP to communicate and that TCP session is created across random path between servers and switches in the datacenter. If there are more paths of course. If there are (and there are!) another two servers talking in the same time, it will possibly happen that this second TCP session will be established using partially the same path as the first TCP session. In that situation there will be a collision that will reduce the throughput for both sessions. There is actually no way to control this phenomenon in TCP world. As in our datacenter example the same thing works for every multipath environment so it it true for example for the Internet.

Answer is MPTCP!

Multipath TCP – MPTCP is better as TCP in that enables the use of multiple paths inside a single transport connection. It meets the goal to work well at any place where “normal” TCP would work.