Re: Last Call: <draft-ietf-opsec-ipv6-implications-on-ipv4-nets-03.txt> (Security Implications of IPv6 on IPv4 Networks) to Informational RFC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]