RE: IPv6/IPv6 threat Comparison Paper available for review

["Tony Hain" <alh-ietf () tndh net>]

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