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

[SM <[e-mail]>]

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