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