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

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Mon, 6 Aug 2012 08:42:53 +0000

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)

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Tue, 7 Aug 2012 14:25:09 +0000

I received a note that Eric Vyncke volunteered to review this draft.

A 3rd candidate is still looked for.

Kind Regards,
G/

From: [email-masked] [mailto:[email-masked]] On Behalf Of Gunter Van de Velde (gvandeve)
Sent: 06 August 2012 10:43
To: [email-masked]; v6ops v6ops WG ([email-masked])
Subject: [OPSEC] 3 Volunteers wanted - Draft: draft-gont-opsec-ipv6-implications-on-ipv4-nets

Dear all,

Many thanks in advance,

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

---

From: "Smith, Donald" <[email-masked]>
Date: Mon, 6 Aug 2012 17:48:33 +0000

I will volunteer. With the understanding that my review would be technical not a "IETF nit" review.

When packets collide the controllers cease transmission AND wait a random time before retransmission (mostly)!
[email-masked] 

> -----Original Message-----
> Sent: Monday, August 06, 2012 2:43 AM
> 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.
> 
> 
>

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 13 Aug 2012 16:11:28 +0000

Count me in

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

Dear all,

Many thanks in advance,

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

---

From: Fernando Gont <[email-masked]>
Date: Mon, 13 Aug 2012 16:57:39 -0300

> Count me in

Great! -- Thanks so much for volunteering..

I look forward to your feedback!

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

---

From: "Smith, Donald" <[email-masked]>
Date: Mon, 13 Aug 2012 20:57:34 +0000

In 3.1 Grammer nit this:
As discussed in Section 3, all IPv6-in-IPv4 traffic, including 6to4,
   could be easily blocked by filtering IPv4 that contain their Protocol
   field set to 41.  This is the most effective way of filtering such
   traffic.
Should be this:
As discussed in Section 3, all IPv6-in-IPv4 traffic, including 6to4,
   could be easily blocked by filtering IPv4 that has the Protocol
   field set to 41.  This is the most effective way of filtering such
   traffic.

in 3.1 you state:
Filter incoming IPv4 packets that have their Source Address set to
      an address that belongs to the prefix 192.88.99.0/24.
         It has been suggested that 6to4 relays send their packets with
         their IPv4 Source Address set to 192.88.99.1.

So should the blocking recommendation be 192.88.99.0/24 or the .1/32?

Other than that this looks pretty good.
Thanks.

(coffee != sleep) & (!coffee == sleep)
 [email-masked]

________________________________________
From: [email-masked] [[email-masked]] on behalf of Fernando Gont [[email-masked]]
Sent: Monday, August 13, 2012 1:57 PM
To: Eric Vyncke (evyncke)
Cc: [email-masked]; v6ops v6ops WG ([email-masked])
Subject: Re: [OPSEC] [v6ops] 3 Volunteers wanted - Draft:       draft-gont-opsec-ipv6-implications-on-ipv4-nets

Cheers,

_______________________________________________
OPSEC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsec

---

From: Fernando Gont <[email-masked]>
Date: Mon, 13 Aug 2012 19:00:27 -0300

Hi, Donald,

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

>    field set to 41.  This is the most effective way of filtering such

How about:

    As discussed in Section 3, all IPv6-in-IPv4 traffic, including 6to4,
    could be easily blocked by filtering IPv4 packets that have their
    Protocol field set to 41.  This is the most effective way of
    filtering such traffic.

? :-)

> So should the blocking recommendation be 192.88.99.0/24 or the .1/32?

Well, at least in theory, any of such addresses could be used for the
same purpose -- one could do the experiment of using, say, 192.168.99.40
and see if 6to4 still works.

That said, and in retrospective, I think that the filtering rules that
consider the Src/Dst Addr should be collapsed with those mentioned as
"Apply these rules if you want to filter 6to4 while still allowing other
ip-proto 41 tunnels" (specified later in the same section). After all,
if you don't have the requirement of filtering 6to4 while allowing other
ip-proto 41 tunnels, you'd simply filter 6to4 based on the ip-proto
value, without even examining the IPv4 Src/Dst addresses.

Thoughts?

> Other than that this looks pretty good.

Thanks so much!

Best regards,

---

From: "Smith, Donald" <[email-masked]>
Date: Mon, 13 Aug 2012 22:16:54 +0000

________________________________________
From: Fernando Gont [[email-masked]]
Sent: Monday, August 13, 2012 4:00 PM
To: Smith, Donald
Cc: Eric Vyncke (evyncke); [email-masked]; v6ops v6ops WG ([email-masked])
Subject: Re: [OPSEC] [v6ops] 3 Volunteers wanted - Draft: draft-gont-opsec-ipv6-implications-on-ipv4-nets

Actually you use this in the 6to4 discussion.
6in4 tunnels can be blocked by blocking IPv4 packets with a Protocol
   field of 41.

That seems better as "their" is seen as possive in english and tends to "humanize" things not human :)

>Thoughts?
I saw the other comments and this makes sense. I can revisit it once you have that done.
It is certainly easier to block based on the protocol field in most systems.

Thanks so much!

Best regards,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 13 Aug 2012 19:23:45 -0300

On 08/13/2012 07:16 PM, Smith, Donald wrote:
[....]
> That seems better as "their" is seen as possive in english and tends to "humanize" things not human :)

Oh, sorry... I missed that one -- must admit that I should now go back
to study a bit of English grammar, since I use this kind of
"construction" a lot...

Will fix this. :-)

Thanks!

Best regards,

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 14 Aug 2012 08:42:42 +0000

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 also wonder whether it is worth an IETF RFC because it is well known topics in the security area (as you probably know)

-       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

-       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

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

-       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

-éric

Dear all,

Many thanks in advance,

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

---

From: "Smith, Donald" <[email-masked]>
Date: Tue, 14 Aug 2012 15:52:34 +0000

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

>       Let’s start with generic:
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 tun…
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)
>       -       Using NAPT (and not NAT as previously commented) usually blocks ‘magically’ IP protocol 41 and most tunnels
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:)

Dear all,

Many thanks in advance,

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

---

From: "Lee Howard" <[email-masked]>
Date: Tue, 14 Aug 2012 14:58:37 -0400

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Eric Vyncke (evyncke)
Sent: Tuesday, August 14, 2012 4:43 AM
To: Gunter Van de Velde (gvandeve); [email-masked]; v6ops v6ops WG
([email-masked])
Cc: Fernando Gont
Subject: Re: [v6ops] [OPSEC] 3 Volunteers wanted - Draft:
draft-gont-opsec-ipv6-implications-on-ipv4-nets

-       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

This is demonstrably false, and I can send you logs of scanning attempts
foiled by NAPT.  NAT is crap security, but it's not zero security.  

Lee

---

From: Fernando Gont <[email-masked]>
Date: Tue, 14 Aug 2012 21:20:36 -0300

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:
[...]
> -       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

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?

> -       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

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!".

> 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,

---

From: Warren Kumari <[email-masked]>
Date: Thu, 16 Aug 2012 15:40:15 -0400

On Aug 14, 2012, at 2:58 PM, Lee Howard wrote:

>  
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric Vyncke (evyncke)
> Subject: Re: [v6ops] [OPSEC] 3 Volunteers wanted - Draft: draft-gont-opsec-ipv6-implications-on-ipv4-nets
>  
> This is demonstrably false, and I can send you logs of scanning attempts foiled by NAPT.  NAT is crap security, but it’s not zero security. 
> 

Heretic!

Actually, I'd go so far as to drop the "crap" from the above -- while it isn't "real" security (whatever that means) it has become cool to simply beat on the NAT. 

Yes, it's not awesome, but it *does* help prevent the secretary's desktop from getting owned quite as often. Yes, he should have it patched, yes it should be capable of protecting itself, yes, there should be a "real" security widget in front of it, but, well… 

W

-- 
With Feudalism, it's your Count that votes.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 17 Aug 2012 10:11:16 +1000

In message <[email-masked]>, Warren Kumari writes:
> > -       1.0 please avoid all discussion about NAPT being =91minimal/simpl
> e=92 security, the days of scanning are over and have been replaced by malw
> are download/email propagated
> 
> foiled by NAPT.  NAT is crap security, but it=92s not zero security.
> 
> Heretic!
> 
> Actually, I'd go so far as to drop the "crap" from the above -- while it is
> n't "real" security (whatever that means) it has become cool to simply beat
>  on the NAT.
> 
> 
> Yes, it's not awesome, but it *does* help prevent the secretary's desktop f
> rom getting owned quite as often. Yes, he should have it patched, yes it sh
> ould be capable of protecting itself, yes, there should be a "real" securit
> y widget in front of it, but, well=85
> 
> 
> W

But the problem is that people think they need "NAT" as opposed to
a "stateful firewall with default allow out all, block in all".
NAPT effectively establishes the latter + munges with addresses and
ports.  It's the state table not the address/port translation that
stops scans.

Stateless NAT44 or NAT66 doesn't stop scans.

As for the secretary's desktop how many of them would be owned
if LSR was being used to scan 192.168/16 though the NAT box?

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Carlos M. martinez" <[email-masked]>
Date: Fri, 17 Aug 2012 10:51:50 -0300

Is a third volunteer still needed ?

~Carlos

---

From: "Lee Howard" <[email-masked]>
Date: Fri, 17 Aug 2012 11:15:49 -0400

> > > -       1.0 please avoid all discussion about NAPT being
=91minimal/simpl
> > e=92 security, the days of scanning are over and have been replaced by
> > malw are download/email propagated
> >
> > Actually, I'd go so far as to drop the "crap" from the above -- while
> > it is n't "real" security (whatever that means) it has become cool to
> > simply beat  on the NAT.
>
> But the problem is that people think they need "NAT" as opposed to a
"stateful firewall with
> default allow out all, block in all".
> NAPT effectively establishes the latter + munges with addresses and ports.
It's the state table
> not the address/port translation that stops scans.

That is true, but is not a flaw in the document.  
The offending text is:
Finally,
   some transition/co-existence mechanisms (notably Teredo) are designed
   to traverse Network Address Translators (NATs), which in many
   deployments provide a minimum level of protection by only allowing
   those instances of communication that have been initiated from the
   internal network.  Thus, these mechanisms might cause an internal
   host with otherwise limited IPv4 connectivity to become globally
   reachable over IPv6, therefore resulting in increased (and possibly
   unexpected) host exposure.  That is, the aforementioned technologies
   might inadvertently allow incoming IPv6 connections from the Internet
   to hosts behind the organizational firewall.

Would you be happy if it said:
   to traverse Network Address Translators (NATs), which, by keeping a
  state table and only allowing inbound packets to hosts which have
  established outbound communication, provides a minimum level of
protection. . . 

I don't think a more thorough discussion of the different risk profiles of
full
cone versus symmetric NAT, etc., is warranted here.  I absolutely agree that

networks should have a stateful firewall.  Would you say that a stateful
firewall is *even more important* now (with IPv6 ramping up) than it ever
was before?   

> Stateless NAT44 or NAT66 doesn't stop scans.

True.  How is that relevant to a discussion of how unintentional IPv6 may
affect
IPv4 networks?
 
> As for the secretary's desktop how many of them would be owned if LSR was
being used to
> scan 192.168/16 though the NAT box?

Fewer than if it were even easier.  Again, not really the point of the
document.

Lee

---

From: Philipp Kern <[email-masked]>
Date: Fri, 17 Aug 2012 18:53:29 +0200

Lee,

>    to hosts behind the organizational firewall.

and how is that different from obtaining a global IPv4 through a VPN connection
to the outside? If you allow the UDP communication to the Teredo relays, you're
probably not stopping such VPNing neither. The lesson being that you need to
know what passes your organizational firewall and whitelist if you care about
that. But then I guess your point is that such tunnels are automatic and not
necessarily user-initiated. But that's an implementation detail with one
vendor's implementation… \:

Kind regards
Philipp Kern

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 17 Aug 2012 18:58:14 +0200

>>    to traverse Network Address Translators (NATs), which in many
[..]
> vendor's implementation… \:

That one vendor you mean, being Microsoft, actually disables Teredo when
the host PC is inside an Active Directory/Windows domain, as such, this
covers most organizations. But even then, per default Teredo on Windows
is configured to not allow incoming connections when the standard
Windows Firewall is active.

And indeed, if you want to properly firewall, then you need to educate
your users and whitelist, anything else does not work as there are way
too many ways that one can get out and play...

Also note that the NAT there is obviously not a firewall, as it allows
any connection to be made and tunnels to be punched through it.

Greets,
 Jeroen

---

From: Warren Kumari <[email-masked]>
Date: Mon, 20 Aug 2012 04:11:45 -0400

>  established outbound communication, provides a minimum level of
<no-hats>

Personally I'm fine with either…. 

I was just mumbling, don't have any particularly strong feelings on this…

</no-hats>

-- 
"He who laughs last, thinks slowest." 
    -- Anonymous