Re: [OPSEC] 3 Volunteers wanted - Draft: draft-gont-opsec-ipv6-implications-on-ipv4-nets

[Fernando Gont <[e-mail]>]

Hi, Eric,

Thanks so much for your feedback! -- Please find my comments in-line...


On 08/14/2012 05:42 AM, Eric Vyncke (evyncke) wrote:
[...]
> Let’s start with generic:
> 
> -       It should not be a BCP but rather informational

Just curious: what's the rationale for your preference?



> -       I also wonder whether it is worth an IETF RFC because it is well
> known topics in the security area (as you probably know)

I disagree with both points, for a number of reasons:

* An IETF RFC means IETF consensus on a topic. That doesn't necessarily
mean that the information is new, but rather than that's how the IETF
thinks about the problem.

* There has been quite some talk about the implications of transition
technologies, and recommendations to "block them"... but concrete advice
on how to filter each of these technologies is not always readily
available. Try Google.

* I generally disagree about "well known topics in the security area"
(unless you clearly define what you mean by "known" and what you mean by
"security area"). Most of the time I've seen any topic deemed as
"well-known" in the security community, it really wasn't. And when it
comes to IPv6 security in particular. there has been so much crap around
it that I'd probably deem "well known IPv6 security topic" as an
oxymoron. :-)


> -       Missing point: awareness of IPV6 by CISO is the key problem,

I don't necessarily disagree, but that kind of aspect seems to be out of
the scope of this particular document.


> should also add that IPv6 is not dangerous per se, and enabling IPv6 in
> intranet is a good way to bypass all automatic tunnels

The focus of this document is how IPv6 affects your "IPv4-only" network.

If you explicitly enable IPv6, then this document does not apply to your
network. -- Not to mention that lots of devices are not IPv6-capable,
which means that it shouldn't come up as a surprise if an admin cannot
enforce enforce on v6 the same policies he enforces on v4.



> -       Intro / title should specify ‘end-user network’ (to avoid
> confusion for ISP)

Do we really need/want to make a difference, here? -- The generic issues
being discussed in this document apply to any network that has "dormant
IPv6 connectivity".



> -       IP flow (netflow), firewall log, DNS request log could also be
> monitored to detect tunnels establishments

Could you please elaborate a bit?



> -       Using NAPT (and not NAT as previously commented) usually blocks
> ‘magically’ IP protocol 41 and most tunnels

Agreed. I will add a note about this.



> -       If the security policy is to force all traffic through
> application proxies (done by all major organizations) then tunnels are
> not a threat

Should I add any comments about this? If so, where?



> Let’s continue with the details:
> 
> -       1.0 please avoid all discussion about NAPT being
> ‘minimal/simple’ security, the days of scanning are over and have been
> replaced by malware download/email propagated

... yet we still use firewalls. Clearly, a NAT-PT blocks some attack
vectors, and reduces host exposure. And technologies such as Teredo
essentially eliminate any sort of protection that could be achieved by
such NAT-PT. And they do block some attacks -- not "all" or "most", but
they do block some.



> -       2.0 congruent security policy indeed with the exception of RFC
> 4890 (ICMPv6)

I'd argue that the policy is still the same -- it's just that there are
additional message types in v6 /which are not present in v4).

It's quite unfortunate to hear in v6 circles things like "in v6, you
cannot filter all ICMP as you do in v4" -- because even in v4 you
couldn't do this without braking PMTUD.



> -       2.1 filtering the IPv6 ethertype is TOO dangerous (= could break
> too many things) to be recommended in an IETF document

Filtering EtherType 0x86DD does what it is meant to do: block native
IPv6 traffic. Note that we are not recommending that people do it, and
even less to have products ship with that filter "on by default" -- we
just note that if you want to prevent block native IPv6 traffic, that's
one possible way to do so.



> -       3.1 should refer to the RFC

Done!



> -       3.3 AFAIK there is no by default implementation of 6RD in
> generic OS and it requires either manual configuration or DHCPv4 option
> => remove this section

I'd probably argue that we should argue the comment on DHCPv4 possibly
enabling 6rd, rather than removing the whole section -- for instance, an
attacker could exploit such vector.

That aside, removing the entire section would likely trigger feedback of
the form "hey guys, you forgot to describe 6rd!".


> -       3.5 leave ISATAP (automatic config through DNS) but specify that
> blocking 41 also blocks it

The current text already notes that.



> -       3.6 as noted, Teredo default port can be changed. The good
> recommendation anyway for enterprises is to block outbound UDP traffic
> (except some pin holes for DNS of course), even my employer network
> blocks them since 1997 ;-). 

This is going beyond the type of advice this document is meant to
provide. We want to provide advice on how to block Teredo... rather than
recommend to filter all UDP.


> Also, Microsoft implementation disables
> Teredo when personal firewall is disabled or when the host is in an
> Active Directory network

That still leaves Windows systems with a firewall and no Active
Directory network with Teredo "on by default".


> -       Other tunnels TSP (but also Sixxs, ...) all require explicit
> installation and configuration by end-users. They are no more a thread
> than any other covert channel (being IP over DNS or over ICMP or ...), I
> would remove this section

TSP could allow incoming connections to the local network, which is
something quite different from an internal node being able to "send
stuff out on top of DNS or ICMP".

Thoughts?

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492