IPv6/IPv6 threat Comparison Paper available for review
Hello all, Sean Convery and I have done a paper comparing IPv6 and IPv4 security threats. We will be presenting an overview of the paper at the NANOG meeting at the end of the month. We wrote this paper from and enterprise edge perspective, but are looking to potentially expand it's scope to service provider networks as well. In advance of that meeting Sean and I wanted to provide the URL for the paper and ask for comments on the paper and also potential areas of expansion. Thanks. http://www.cisco.com/security_services/ciag/documents/v6-v4-threats.pdf P.S. - It should be noted that this paper was completed in January and needs to be updated with some information from the latest IPv6 developments (site local deprecated, etc.) Darrin Miller Cisco Systems, Inc. dmiller@cisco.com (614) 718-2708
On 11-mei-04, at 3:13, Darrin Miller wrote:
http://www.cisco.com/security_services/ciag/documents/v6-v4-threats.pdf
Ok, some comments: - style: Font too small / lines too long: 15 words or more per line doesn't make for the easiest reading. There is way too much in the way of "This section outlines...". Guess what, that's why they invented headings. As they say in Hollywood: cut to the chase. Six level deep heading numbering is also not good. - ICMP: The whole bit on ICMP meanders between being just strict and being too strict. I don't see any convincing reason to filter ICMP. But given that some people want this, give them the right information. Stuff like echo / echo reply I can live without, but I really need my PMTUD in IPv4 as well as IPv6. Yes, fragmentation is possible in IPv4 in theory, but in practice the DF bit is set on most packets. In reasonable ICMP filtering you should also allow more unreachables, such as port unreachables, or be prepared to sit through lengthy timeouts. - On-link/off-link Many things that are mentioned, such as the potential for multicast mischief, or the additional uses for ICMP, really only apply on the local link, and are irrelevant elsewhere on the net. The assumption that there is a firewall on local links is bizarre. If you want to protect systems against on-link misbehavior, it makes sense to put them behind a router. IPv6 hosts are much more vulnerable to abuse from on-link attackers: these can spoof neighbor/router discovery, they can easily find addresses and even hosts without global IPv6 addresses are potentially vulnerable, especially as many filters only look at IPv4 and not IPv6. (In FreeBSD turning off IPv6 in the configuration doesn't actually turn it off so the host remains potentially vulnerable.) - Fragmentation You can't drop non-last fragments that are smaller than 1280 bytes as a host may fragment a packet into equal size parts rather than a big and a small part. Testing if you can get away with it makes no sense as new implementations come on the market all the time. If you want to do this you can probably do it at around ~600 bytes for non-last fragments as there is no legitimate need to fragment packets that are already 1280 bytes or smaller, so if this is done anyway it's probably for reasons you don't like. - Smurf I don't think you mention that in IPv6, there are no mechanisms that allow an incoming unicast packet to be turned into a broadcast or multicast packet, and as such, smurf-like attacks are impossible. - Tunneling Why only filter outbound tunneling? - Use of multiple addresses You say that RFC 3041 helps against scanning. It doesn't, as hosts also keep their EUI-64 derived addresses. In IPv6 it is required to support having multiple addresses on an interface.
Iljitsch van Beijnum wrote:
On 11-mei-04, at 3:13, Darrin Miller wrote:
http://www.cisco.com/security_services/ciag/documents/v6-v4-threats.pdf
Ok, some comments: ... - Fragmentation
You can't drop non-last fragments that are smaller than 1280 bytes as a host may fragment a packet into equal size parts rather than a big and a small part. Testing if you can get away with it makes no sense as new implementations come on the market all the time. If you want to do this you can probably do it at around ~600 bytes for non-last fragments as there is no legitimate need to fragment packets that are already 1280 bytes or smaller, so if this is done anyway it's probably for reasons you don't like.
Technically you are correct, but if the firewalls are deployed first those later systems will have to conform to what the network allows.
- Smurf
I don't think you mention that in IPv6, there are no mechanisms that allow an incoming unicast packet to be turned into a broadcast or multicast packet, and as such, smurf-like attacks are impossible.
It can be done on-link by a zombie, but that is not the strict definition of a remote smurf attack.
- Tunneling
Why only filter outbound tunneling?
- Use of multiple addresses
You say that RFC 3041 helps against scanning. It doesn't, as hosts also keep their EUI-64 derived addresses. In IPv6 it is required to support having multiple addresses on an interface.
There is no requirement for an end system to use the EUI-64 suffix with a global prefix. It is a perfectly reasonable scenario for the system to have a policy that says only use 3041 with global prefixes, and EUI-64 for the FE80:: & FC00:: prefixes. The only real issue is how the end system derives a consistent value for anything it registers in DDNS. Even then it can be based on an apparently random set of bits as long as they don't change and create churn in DNS. Tony
participants (3)
-
Darrin Miller -
Iljitsch van Beijnum -
Tony Hain