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

["Smith, Donald" <[e-mail]>]

(coffee != sleep) & (!coffee == sleep)
 [e-mail]<mailto:[e-mail]>
________________________________
From: [e-mail] [[e-mail]] on behalf of Eric Vyncke (evyncke) [[e-mail]]
Sent: Tuesday, August 14, 2012 2:42 AM
To: Gunter Van de Velde (gvandeve); [e-mail]; v6ops v6ops WG ([e-mail])
Cc: Fernando Gont
Subject: Re: [OPSEC] 3 Volunteers wanted - Draft: draft-gont-opsec-ipv6-implications-on-ipv4-nets

>       Fernando and Gunter,
>
>       Sorry for belated comments... I agree with most comments from other reviewers of course (esp Panos).  I have two classes of comments: generic and details.
>
>       Let’s start with generic:
>       -       It should not be a BCP but rather informational
I support as informational.

>       -       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 think it helps to spell things like this out. So believe it is worthy of being an IETF RFC.

>       -       Missing point: awareness of IPV6 by CISO is the key problem, should also add that IPv6 is not dangerous per se, and enabling IPv6 in intranet is a good way to bypass all automatic tunnels
Enabling IPv6 in the intranet doesn't stop the tunnels. That is the systems that support tunnels can for the most part still do the tunneling even with IPv6 enabled.


>       -       Intro / title should specify ‘end-user network’ (to avoid confusion for ISP)
>       -       IP flow (netflow), firewall log, DNS request log could also be monitored to detect tunnels establishments
>       -       Using NAPT (and not NAT as previously commented) usually blocks ‘magically’ IP protocol 41 and most tunnels
>       -       If the security policy is to force all traffic through application proxies (done by all major organizations) then tunnels are not a threat
I don't know many major organization that forces ALL TRAFFIC through application proxies. Most have various proxies and force http and some other well known protocols through their proxies but nearly every network I have ever seen had various pinholes for non-proxied traffic.

>
>       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
Conficker is still one of the largest infections out there. It spread primarily via scanning for open ports. Check netflow today and 445 is still the most commonly seen ports in darknets and honey pots..
So scanning hasn't gone away. It is still very common. I would agree other methods have been adopted by some but "scan and spolit" worms continue to florish.
Take a look a public sites such as atlas.
http://atlas.arbor.net/

2nd most popular port is 445. 4th is 139 also attributable to worms (conficker included).

It also shows outbound teredo in the top attacks:)


>       -       2.0 congruent security policy indeed with the exception of RFC 4890 (ICMPv6)
>       -       2.1 filtering the IPv6 ethertype is TOO dangerous (= could break too many things) to be recommended in an IETF document
>       -       3.1 should refer to the RFC
>       -       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
>       -       3.5 leave ISATAP (automatic config through DNS) but specify that blocking 41 also blocks it
>       -       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 ;-). Also, Microsoft implementation disables Teredo when personal firewall is disabled or when the host is in an Active Directory network
>       -       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
>
>       Hope this helps
>

From: [e-mail] [mailto:[e-mail]] On Behalf Of Gunter Van de Velde (gvandeve)
Sent: lundi 6 août 2012 10:43
To: [e-mail]; v6ops v6ops WG ([e-mail])
Subject: [OPSEC] 3 Volunteers wanted - Draft: draft-gont-opsec-ipv6-implications-on-ipv4-nets

Dear all,

Can I request the WG members for 3 volunteers to read the draft draft-gont-opsec-ipv6-implications-on-ipv4-nets and provide feedback to the list?

This will help the OPSEC chairs to identify if the work is ready for WG adoption or not. The work targets are within charter of the WG, and seems to be interesting work for the community.

Questions we are looking answers for:


1)      Should it be targeted BCP or Informational?

2)      Is the work quality ok to be accepted as WG document?

3)      Is the topic inline with the OPSEC charter?

4)      Any missing or over-described points?

Many thanks in advance,

Kind Regards,
OPSEC Chairs,
(G/, KK, Warren)