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

["Carlos M. martinez" <[e-mail]>]

Is a third volunteer still needed ?

~Carlos

On 8/14/12 9:20 PM, Fernando Gont wrote:
> 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,
>