Subject: [OPSEC] 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: "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-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Gunter Van de Velde (gvandeve)
> Sent: Monday, August 06, 2012 2:43 AM
> To: [email-masked]; v6ops v6ops WG ([email-masked])
> 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.
> 
> 
>

---

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: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Thu, 9 Aug 2012 17:48:46 +0000

I can look at it unless you have 3 already.
Panos

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

Kind Regards,
G/

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Gunter Van de Velde (gvandeve)
Sent: 06 August 2012 10:43
To: [email-masked]<mailto:[email-masked]>; v6ops v6ops WG ([email-masked]<mailto:[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: "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 09:26:34 -0300

HI, Panos,

> I can look at it unless you have 3 already.

Please do.

Any comments will be really welcome.

Thanks!

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

---

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,

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Mon, 13 Aug 2012 20:52:51 +0000

Hi Fernando,

Useful I-D. Some initial thoughts: 

- I see that you are mentioning RA-Guard for SLAAC-based attacks. Is the ND-Shield worth mentioning for L2 attacks?
- For 6to4, maybe it would be worth to mention http://tools.ietf.org/html/rfc3964 
- In 6to4 subsection, a couple of protections state "(embedded in the IPv4 payload)". This is not our traditional ACL filtering. It requires equipment that can look and inspect the encapsulated packet, or match on specific fields of the packet payload, or actually understand 6 in 4 encapsulation in order to be able to filter. Maybe it would be worth the put a sentence to clarify that to prevent readers from think this is traditional ACL filtering.
- For Teredo, would it be worth mentioning that blocking UDP packets with embedded IPv6 addresses 2001::/32 on a device that can match/"understand"/inspect Teredo encapsulation is another mitigation option (as in 6to4 "(embedded in the IPv4 payload)")?
- ISATAP section suggests that it can be blocked as described in Section 3. Can you add blocking " isatap.<domain>.com" in DNS A record as in Teredo?
- Section "3.  Security Implications of tunneling Mechanisms". Would it be worth to break up the tunneling mechanisms to Client and ISP? The protections would then be employed in tACL and iACLs (For example, blocking 6rd should be done on me iACL). This is not a technical correction, but rather a suggestion for the semantics.
- Would it be worth to have a table in the end, as you had for the ICMP filtering I-D, that says 
"Teredo    	block this"
"ISATAP    	block that"
"6rd		block this"
It would be a good summary table.

Rgs,
Panos

-----Original Message-----
From: Fernando Gont [mailto:[email-masked]] 
Sent: Monday, August 13, 2012 8:27 AM
To: Panos Kampanakis (pkampana)
Cc: Gunter Van de Velde (gvandeve); [email-masked]
Subject: Re: [OPSEC] 3 Volunteers wanted - Draft: draft-gont-opsec-ipv6-implications-on-ipv4-nets

HI, Panos,

Please do.

Thanks!

Best regards,

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Mon, 13 Aug 2012 20:54:06 +0000

This are my thoughts on the questions for this I-D:

      My opinion is that it is Informational, since it is explaining the concerns and the protection options. If the protections in the doc are good practices or not depends on the network specifics, so I think Info is better than BCP.

      Yes, the doc is useful and detailed enough to be a WG doc.

      Yes, it doesn't describe new protocols, but it explains security implications and how to protect against them

      I sent thoughts to Fernando in a separate email in the WG alias titled "Re: Draft: draft-gont-opsec-ipv6-implications-on-ipv4-nets Review"

Thanks,

Panos

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Gunter Van de Velde (gvandeve)
Sent: Monday, August 06, 2012 4:43 AM
To: [email-masked]<mailto:[email-masked]>; v6ops v6ops WG ([email-masked]<mailto:[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, 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 18:32:33 -0300

Hi, Panos,

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

On 08/13/2012 05:52 PM, Panos Kampanakis (pkampana) wrote:
> - I see that you are mentioning RA-Guard for SLAAC-based attacks. Is
> the ND-Shield worth mentioning for L2 attacks?

Yes. I should also check what they are doing at the SAVI WG, since
apparently they have standardized something along the lines of ND-Shield....

> http://tools.ietf.org/html/rfc3964

Good point. Will do!

> - In 6to4 subsection, a couple of protections state "(embedded in the
> IPv4 payload)". This is not our traditional ACL filtering. It
> requires equipment that can look and inspect the encapsulated packet,
> or match on specific fields of the packet payload, or actually
> understand 6 in 4 encapsulation in order to be able to filter. Maybe
> it would be worth the put a sentence to clarify that to prevent
> readers from think this is traditional ACL filtering.

Agreed. Will do.

> - For Teredo,
> would it be worth mentioning that blocking UDP packets with embedded
> IPv6 addresses 2001::/32 on a device that can
> match/"understand"/inspect Teredo encapsulation is another mitigation
> option (as in 6to4 "(embedded in the IPv4 payload)")?

Good point. Will do!

> - ISATAP
> section suggests that it can be blocked as described in Section 3.
> Can you add blocking " isatap.<domain>.com" in DNS A record as in
> Teredo?

Makes sense. Will do. -- BTW, one should also add that some systems
(Windows :-) ) not only try to resolve these names with DNS, but
sometimes they also try things such as LLNMR... which means that you may
have to filter at layer-2 if you want to prevent a local atacker to
enable Teredo or ISATAP.

> - Section "3.  Security Implications of tunneling
> Mechanisms". Would it be worth to break up the tunneling mechanisms
> to Client and ISP? The protections would then be employed in tACL and
> iACLs (For example, blocking 6rd should be done on me iACL). This is
> not a technical correction, but rather a suggestion for the
> semantics. 

I don't have a strong opinion one way or another -- just wondering
whether making that differentiation would make things clearer, or not
(talk about whether people is used to that terminology).

> - Would it be worth to have a table in the end, as you had
> for the ICMP filtering I-D, that says "Teredo    	block this" "ISATAP
> block that" "6rd		block this" It would be a good summary table.

You mean a summary of the filtering rules (e.g., "block packets of type
X with ipproto Y, destined to UDP port X") or a summary of what
transition technologies you should probably block by default?

Thanks so much!

Best regards,

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Mon, 13 Aug 2012 21:36:00 +0000

Thanks Fernando, agreed.

> You mean a summary of the filtering rules (e.g., "block packets of type X with ipproto Y, destined to UDP port X") or a summary of what transition technologies you should probably block by default?

I meant the former. Just a summary of what to block if you want to disable each mechanism.

Panos

-----Original Message-----
From: Fernando Gont [mailto:[email-masked]] 
Sent: Monday, August 13, 2012 5:33 PM
To: Panos Kampanakis (pkampana)
Cc: [email-masked]
Subject: Re: [OPSEC] Draft: draft-gont-opsec-ipv6-implications-on-ipv4-nets Review

Hi, Panos,

> the ND-Shield worth mentioning for L2 attacks?

Yes. I should also check what they are doing at the SAVI WG, since apparently they have standardized something along the lines of ND-Shield....

Good point. Will do!

> IPv4 payload)". This is not our traditional ACL filtering. It requires 
> equipment that can look and inspect the encapsulated packet, or match 
> on specific fields of the packet payload, or actually understand 6 in 
> 4 encapsulation in order to be able to filter. Maybe it would be worth 
> the put a sentence to clarify that to prevent readers from think this 
> is traditional ACL filtering.

Agreed. Will do.

Good point. Will do!

> Can you add blocking " isatap.<domain>.com" in DNS A record as in 

Makes sense. Will do. -- BTW, one should also add that some systems (Windows :-) ) not only try to resolve these names with DNS, but sometimes they also try things such as LLNMR... which means that you may have to filter at layer-2 if you want to prevent a local atacker to enable Teredo or ISATAP.

> - Section "3.  Security Implications of tunneling Mechanisms". Would 
> it be worth to break up the tunneling mechanisms to Client and ISP? 
> The protections would then be employed in tACL and iACLs (For example, 
> blocking 6rd should be done on me iACL). This is not a technical 
> correction, but rather a suggestion for the semantics.

I don't have a strong opinion one way or another -- just wondering whether making that differentiation would make things clearer, or not (talk about whether people is used to that terminology).

> block that" "6rd		block this" It would be a good summary table.

You mean a summary of the filtering rules (e.g., "block packets of type X with ipproto Y, destined to UDP port X") or a summary of what transition technologies you should probably block by default?

Thanks so much!

Best regards,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 13 Aug 2012 18:38:01 -0300

On 08/13/2012 06:36 PM, Panos Kampanakis (pkampana) wrote:
> Thanks Fernando, agreed.
> 
>> You mean a summary of the filtering rules (e.g., "block packets of
>> type X with ipproto Y, destined to UDP port X") or a summary of
>> what transition technologies you should probably block by default?
> 

Yep, makes sense. -- Will do!

Thanks so much!

Best regards,

---

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?

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: Fernando Gont <[email-masked]>
Date: Tue, 14 Aug 2012 09:02:28 -0300

Hi, Panos,

While trying to address your feedback, I came up with additional
comments. Please do let me know what you think...

> the ND-Shield worth mentioning for L2 attacks?

I ended up referencing DHCPv6-Shield rather than ND-Shield, since the
goal here is to prevent attackers from enabling "global IPv6
connectivity" -- ND-Shield, on the other hand mitigates Neighbor Cache
sppofing attacks, which is not the subject of this section.

> readers from think this is traditional ACL filtering.

I've added a clarification about this. Additionally, I added a note
mentioning that an attacker might fragment its 6to4 packets into tiny
fragments such that the filtering device does not really have access to
the embedded IPv6 Addresses.

> - For Teredo, would it be worth mentioning that blocking UDP packets
> with embedded IPv6 addresses 2001::/32 on a device that can

The problem here is that, IIRC (and of the top of my head), no specific
UDP port numbers are used for the "data" packets, and hence you cannot
really tell to which UDP packets you should apply these filtering rules.

Does this make sense?

As a result, I have not yet added any text regarding filtering Teredo
packets based on the embedded IPv6 addresses. But please do let me know
if you feel otherwise.

Thanks!

Best regards,

---

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

Regarding the filtering of Teredo 'data' packets, several IPS are actually dropping all UDPv4 packets where 2001:0::/32 appears at the right place with also another IPv6 address as well as the IPv6 version indicator. So, this is one way to block Teredo

But, the most efficient (often used unknowingly) is to use only application proxies ;)

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Fernando Gont
> Sent: mardi 14 août 2012 14:02
> While trying to address your feedback, I came up with additional comments.
> Please do let me know what you think...
> 
> I ended up referencing DHCPv6-Shield rather than ND-Shield, since the goal
> here is to prevent attackers from enabling "global IPv6 connectivity" -- ND-
> Shield, on the other hand mitigates Neighbor Cache sppofing attacks, which
> is not the subject of this section.
> 
> 
> fragments such that the filtering device does not really have access to the
> embedded IPv6 Addresses.
> 
> 
> 
> The problem here is that, IIRC (and of the top of my head), no specific UDP
> port numbers are used for the "data" packets, and hence you cannot really
> tell to which UDP packets you should apply these filtering rules.
> 
> Does this make sense?
> 
> packets based on the embedded IPv6 addresses. But please do let me know if
> you feel otherwise.
> 
> Thanks!
> 
> Best regards,
> --
> Fernando Gont
> SI6 Networks

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Tue, 14 Aug 2012 13:16:37 +0000

Thank Fernando.

> I ended up referencing DHCPv6-Shield rather than ND-Shield, since the goal here is to prevent attackers from enabling "global IPv6 connectivity" -- ND-Shield, on the other hand mitigates Neighbor Cache sppofing attacks, which is not the subject of this section.

Agreed.

For Teredo, as also Eric Vyncke pointed out, I was thinking IPS or Pattern type matching in UDP payloads. Or even proxies that can understand and inspect the Teredo communication. These are not the traditional ACL filtering of course.

Rgs,
Panos

-----Original Message-----
From: Fernando Gont [mailto:[email-masked]] 
Sent: Tuesday, August 14, 2012 8:02 AM
To: Panos Kampanakis (pkampana)
Cc: [email-masked]
Subject: Re: [OPSEC] Draft: draft-gont-opsec-ipv6-implications-on-ipv4-nets Review

Hi, Panos,

While trying to address your feedback, I came up with additional comments. Please do let me know what you think...

> the ND-Shield worth mentioning for L2 attacks?

I ended up referencing DHCPv6-Shield rather than ND-Shield, since the goal here is to prevent attackers from enabling "global IPv6 connectivity" -- ND-Shield, on the other hand mitigates Neighbor Cache sppofing attacks, which is not the subject of this section.

> is traditional ACL filtering.

I've added a clarification about this. Additionally, I added a note mentioning that an attacker might fragment its 6to4 packets into tiny fragments such that the filtering device does not really have access to the embedded IPv6 Addresses.

> option (as in 6to4 "(embedded in the IPv4 payload)")?

The problem here is that, IIRC (and of the top of my head), no specific UDP port numbers are used for the "data" packets, and hence you cannot really tell to which UDP packets you should apply these filtering rules.

Does this make sense?

As a result, I have not yet added any text regarding filtering Teredo packets based on the embedded IPv6 addresses. But please do let me know if you feel otherwise.

Thanks!

Best regards,

---

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,

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