IPv6/IPv6 threat Comparison Paper available for review

Iljitsch van Beijnum iljitsch at muada.com
Tue May 11 09:11:03 UTC 2004


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.




More information about the NANOG mailing list