North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: IPv6/IPv6 threat Comparison Paper available for review

  • From: Iljitsch van Beijnum
  • Date: Tue May 11 05:13:40 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.