This week I got a bit frustrated over the security people that frequently write blogs saying “Be careful when implementing IPv6” or “IPv6 opens for new attacks” without discussing details, advicing you on what to do and pinting you in any useful direction. Seems like most of them simply wants you to become a customer. We need more practical documents, down to earth. And those are very hard to find. Let’s start the process. Spend 30 minutes on IPv6 every Friday!
IETF: Simple Security Capabilities
While discussing this on various social media flows, I got a lot of pointers to IETF documents. The engineers in IETF has really taken security seriously and have produced a large amount of documents for enterprises, homes and service providers to use as guidelines. If you ever enter a room with more than one network engineer working with security, you will notice that they are not always in agreement and this can be seen in parts of the IETF documentation as well. Do we still need NAT? Do we need a protocol to open ports in the firewall from the inside? Should we require support for new protocols like SCTP in the IPV6 products, since the software is newer than the old IPv4 platforms? This week, I will focus on one of the documents, the informational RFC that describes a set of security recommendations for CPEs.
RFC 6092 is an information RFC that describes 50 IPv6 security recommendations for a CPE-style device, a home or small office router. Here’s the introduction from the RFC:
Some IPv6 gateway devices that enable delivery of Internet services in residential and small-office settings may be augmented with “simple security” capabilities as described in “Local Network Protection for IPv6” [RFC4864]. In general, these capabilities cause packets to be discarded in an attempt to make local networks and the Internet more secure. However, it is worth noting that some packets sent by legitimate applications may also be discarded in this process, affecting reliability and ease of use for these applications.
There is a constructive tension between the desires of users for transparent end-to-end connectivity on the one hand, and the need for local-area network administrators to detect and prevent intrusion by unauthorized public Internet users on the other. This document is intended to highlight reasonable limitations on end-to-end transparency where security considerations are deemed important to promote local and Internet security.
Is this theory or does it really work in the tools we have today?
I think this document is a good platform for further discussion. If we assume that we want to follow this document, is it possible to implement in common firewalls? How? We need to produce scripts in IP-tables, PF and other firewall tools, like Firewall Builder. We need to document how-tos and make sure that vendors and open source project developers add functionality that is missing (if any).
Please spend a few minutes going through this presentation that simply lists all 50 recommendations. Then go read the full RFC that has a lot of background material and references to other documents. Join the flow on Twitter, Facebook or G+ and discuss how to proceed. Get a group of collegues and friends together to lab, test and go through this list.
Maybe Arin, ISOC Deploy 360 or Ripe can help collect and produce firewall rulesets based on this RFC?
That’s all for now. You have a lot of material to go through so I won’t disturb you more.
Have a great IPv6 Friday!
/Olle