Hi Fernando,
At 05:49 01-04-2013, Fernando Gont wrote:
Please re-read the above paragraph -- you missed the part that says
"...the same security policies".
I saw that. :-) I commented on Section 6 first as it's only when I
reached that part of the document that I saw the trade-off between
blocking IPv6 traffic and security.
Those issues are not present when your network employs v4-only.
What's missing is some text in the Introduction section explaining
that the draft is discussing about IPv4 networks (what is mentioned above).
A network were none of the devices connected to it implement v6.
If that is the case some of the attacks would not be possible. The
scenario the draft discusses about is when there are devices which
have IPv6 support. The draft could have an explanation about IPv4
networks (see previous comment) and then follow it with the first
sentence of Section 1. It can then go into a discussion of the
threats and how to mitigate them.
From Section 1:
"filtering IPv6 traffic (whether native or transition/co-existence)
to mitigate IPv6 security implications on IPv4 networks should
(generally) only be considered as a temporary measure until IPv6
is deployed."
It's not a temporary measure in the sense that there is an assumption
that the network should be IPv4 only. If the network is to support
IPv4 and IPv6, filtering of IPv6 traffic is not recommended then.
The reference is meant to illustrate that that even if you think your
network only employs IPv4 (and hence forget about the v6 support), you
could be hit by that.
Ok.
For attacks that employ link-local connectivity, it bolds down to packet
filtering (either by a personal firewall at the host, or by filtering v6
at layer-2) -- this is discussed in the I-D.
I don't see anything about that in the draft. There is a mention of
filtering at Layer 2 and Layer 3.
Happy Eyeballs has to do with what you do when you drop packets. If you
silently drop them, the host may have rely on timeouts rather than
having a positive indication that a packet has been dropped.
This is a browser issue. I'll comment further in another message.
Could you please elaborate?
The text about DNS (Section 4) is about DNS replies. What I meant
was that the draft recommends changing the answer for a (DNS) AAAA
query in an attempt to stop IPv6 traffic. It's ok to block IPv6
traffic as it's an IPv4-only network. I don't think that it is ok to
tamper with DNS replies (in this case you are covered by local policy
and you can do that).
Please see the quotes when we say "'IPv4-only' networks" -- in practice,
there's no such a thing, and you should think v6 security even if you
think/want to run an IPv4-only network.
It might help to reword the Abstract and the Introduction Section so
that the purpose of the document is clear. I agree that it is good
to think IPv6 security even if I want an IPv4-only network.
This one I cannot do much about. :-)
:-)
Regards,
-sm