Subject: [v6ops] Fwd: NIST IPv6 document

From: Joel Jaeggli <[email-masked]>
Date: Tue, 04 Jan 2011 20:49:22 -0800

-------- Original Message --------
Subject: NIST IPv6 document
Date: Tue, 04 Jan 2011 20:35:48 -0800
From: Kevin Oberman <[email-masked]>
To: [email-masked]

NIST has released SP800-119, "Guidelines for the Secure Deployment of
IPv6". While I don't agree with everything in it, it is an excellent
overview of IPv6, differences from IPv4, and security advice. While the
title sounds like a security document, the security implications are
only a part of it.

I've not finished reading it, but my first reaction is that this is a
good source of information. Well written, fairly detailed (at 188 pages)
with lots of references.

The PDF is available at:
http://csrc.nist.gov/publications/nistpubs/800-119/sp800-119.pdf
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: [email-masked]			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 06 Jan 2011 08:58:36 +1300

Hmm. This is the document of which I wrote a few months ago
on another list:

> Except that this is truly obnoxious and paranoid:
> 
>> > Organizations that are not yet deploying IPv6 should implement the following recommendations:
>> > 
>> > * Block all IPv6 traffic, native and tunneled, at the organization's firewall. Both incoming and outgoing traffic should be blocked. 

Regards
   Brian

---

From: Michael Newbery <[email-masked]>
Date: Mon, 10 Jan 2011 14:32:30 +1300

>>>> * Block all IPv6 traffic, native and tunneled, at the organization's firewall. Both incoming and outgoing traffic should be blocked. 

Leading to further fulfillment of Robb's Dictum: "It's the firewall" [An observation on the most likely source of network breakage and poor performance]

---

From: Fernando Gont <[email-masked]>
Date: Mon, 10 Jan 2011 14:11:42 -0300

On 05/01/2011 04:58 p.m., Brian E Carpenter wrote:

> Hmm. This is the document of which I wrote a few months ago on
> another list:
> 
>>>> * Block all IPv6 traffic, native and tunneled, at the
>>>> organization's firewall. Both incoming and outgoing traffic
>>>> should be blocked.

Well, if the firewall is meant to allow only traffic that is deemed as
necessary, and the organization has not decided to deploy v6... why
should it be allowed? And.. what would be the point of firewalling v4
when you could bypass the firewall with v6?

(Note: there's stuff in the NIST document with which I don't agree. But
this particular recommendation is, IMO, as paranoid as it *needs* to be)

Thanks!

Best regards,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Mark Townsley <[email-masked]>
Date: Mon, 10 Jan 2011 21:42:13 +0100

On 1/10/11 6:11 PM, Fernando Gont wrote:

> should it be allowed? 

Classic "traffic blocking" measures for v6 can affect v4. For example,
there is a recommendation to block IPv6 over IPv4 tunneling in the NIST
profile as well. That of course can be done, but one must understand
that this could cause noticeable timeouts and such for users with
operating systems which automatically try and establish such tunnels.
So, the enterprise needs to either have the ability to actively turn off
IPv6 on the hosts, or perhaps filter out all AAAAs at the border and be
sure to control the DNS configured in all hosts, etc. in order to avoid
these kinds of problems (or deal with annoyed users and lost
productivity, or hope that happy-eyeballs appears RSN, ...).

> And.. what would be the point of firewalling v4

Modern Macs and PCs come with firewalls enabled by default that are
regularly updated by the manufacturer. They also happen to be the ones
with IPv6 capability.

Pre XP-SP2, win 95, etc. devices shipped without a local firewall on by
default and themselves were not developed well enough to exist on the
open Internet without a network-based firewall. Good thing they don't
run IPv6 without special intervention.

Not to say for a moment that there no conceivable ways to breech
security of an IPv6 enabled host for which a firewall might otherwise
provide protection, but I do think there is a difference between setting
up a firewall in front of hosts which already have their own firewalls
vs. those that do not.

- Mark

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Jan 2011 11:01:29 +1300

Hi Fernando,

> necessary, and the organization has not decided to deploy v6... why

Because it blocks experiment and innovation by people within the
organization. In general, that's a bad thing for any organization
that wishes to develop and grow. The precautionary approach is
the enemy of progress.

Enough philosophy... for the rest, see Mark Townsley's reply.

    Brian

---

From: Fernando Gont <[email-masked]>
Date: Mon, 10 Jan 2011 20:43:55 -0300

On 10/01/2011 05:42 p.m., Mark Townsley wrote:

> profile as well. 

Good for them. (this is okay unless the admin really wanted transition
traffic in his network)

> That of course can be done, but one must understand

If transition traffic is properly blocked, those host would never be
able to configure such tunnels (e.g., Teredo)

> productivity, or hope that happy-eyeballs appears RSN, ...).

Users will be usually already be annoyed when experiencing the
performance of some transition mechanisms...

>> when you could bypass the firewall with v6?
[....]
> up a firewall in front of hosts which already have their own firewalls

Yep: the admin is more likely to have control over the organizational
firewall rather than over the "personal firewall" on hosts.

Not to mention that a typical Windows user will use the Admin account to
surf the net, in which case the personal firewall could be trivially
disabled by malware.

Thanks,

---

From: Rémi Després <[email-masked]>
Date: Wed, 12 Jan 2011 11:44:26 +0100

Le 5 janv. 2011 à 05:49, Joel Jaeggli a écrit :
> ... my first reaction is that this is a

+1

I noted however an error in section 6.5.7 on Teredo:
"The 6to4 and 6rd protocols require public IPv4 addresses"

This isn't right for 6rd (RFCs 5569 and 5969) 

> ... The PDF is available at:

Regards,
RD

---

From: Fernando Gont <[email-masked]>
Date: Thu, 13 Jan 2011 17:08:36 -0300

> that wishes to develop and grow. The precautionary approach is

I think the flaw in this reasoning is that it assumes the raison detre
of most organizational networks is "innovation" and "experiment", when
it is not. Their raison detre is to help the organization in the process
of making profit. In practice, this means allowing some of their
employes doing email, surf the web, instant messaging and so on. If they
are able to do this, then their network has served its purpose.

And good security practice is "if you don't *need* to do it, then
*don't*". So if the org has decided not to deploy v6 for the time being
(the reason being irrelevant in this case), it's IMO perfectly
understandable that they block it.

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 14 Jan 2011 12:58:18 +1300

On 2011-01-14 09:08, Fernando Gont wrote:
> of making profit. 

In the long term, both profit and even survival of a company depend
on innovation. I think it's well established that exclusive pursuit
of the current quarter's profit is the best way to miss seeing both massive
opportunities and massive roadblocks. In our world, telcos missing the
Internet is a great example worth untold billions.

So philosophically, we disagree. In terms of standards recommendations,
whether from the IETF or from NIST, either extreme should be avoided.

  If you want to allow innovation, do this:...
  If you want to block innovation, do that:...

Enough said, I think.

   Brian

In practice, this means allowing some of their

---

From: Fernando Gont <[email-masked]>
Date: Fri, 14 Jan 2011 03:23:59 -0300

On 13/01/2011 08:58 p.m., Brian E Carpenter wrote:

> on innovation. 

Do you expect innovation to be pursued in e.g. commercial department
network or the like?

The NIST IPV6 document is not "guidelines for deploying v6 in the
engineering lab" or the like. It's about IPv6 deployment in general
networks. -- And most networks (an administrative office network,
marketing department network, whatever) do not pursue networking innovation.

That aside, in all fairness one could possibly argue that most
"innovation" (in terms of real impact on people's everyday life) has
mostly happened at the app layer rather than in the lower layers.

Thanks,

---

From: Josh Rambo <[email-masked]>
Date: Fri, 14 Jan 2011 11:47:47 -0500

> Internet is a great example worth untold billions.

Unless you can get your management team to buy into this pitch, it
doesn't matter what your personal philosophy of innovation is. The
fact is that companies exist to make money. If they think innovation
will help them do so, then great, but innovation for the sake of
innovation is not a pitch that would be accepted at my own place of
business, and I doubt I'm alone on that front.

>  If you want to block innovation, do that:...

You've entirely missed the point. I counterpoint with the following
alternate phrasing:

If you want to allow traffic that your internal infrastructure has not
been built to audit and filter, do this:
If you want to have a secure network, do that:

The NIST isn't advocating "blocking innovation", they're advocating
blocking tunneled IPv6 traffic. Blocking innovation is something that,
you feel, is a necessary side effect of that. But don't try to
construe it as NIST being the big bad guy who's trying to stop you
from being creative in your workplace.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 15 Jan 2011 10:20:42 +1300

On 2011-01-15 05:47, Josh Rambo wrote:
...
> If you want to have a secure network, do that:

Obviously, serious standards text from any SDO should not
be at either of these extremes. But it should present the
alternatives fairly, so that an individual network operator
can decide according to their own needs. The NIST text
doesn't do that, and the IETF can do better.

    Brian

---

From: Josh Rambo <[email-masked]>
Date: Fri, 14 Jan 2011 17:06:15 -0500

> doesn't do that, and the IETF can do better.

You are correct that both wordings are overly inflammatory, but my
real point is what followed the part you quoted, wherein I explained
NIST's motivations.
I agree with you that the IETF should spell out some alternative
deployment scenarios in matters such as these.