Subject: [perpass] "Guide to intranet protection"?

From: Dave Crocker <[email-masked]>
Date: Wed, 27 Nov 2013 06:06:07 -0800

Morning mid-coffee question:

      There have been some recent news articles about various major ISPs 
taking steps to encrypt their (internal) traffic.  These prompt me to 
wonder whether it would be practical and useful for the IETF to produce 
a basic draft that gives guidance to other ISP and enterprise operators 
about the steps they should take to protect their traffic.

      I'm assuming that providing meaningful protection takes a 
statement beyond "encrypt all your links".  Perhaps it doesn't, but I 
thought I'd ask...

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 27 Nov 2013 14:12:56 +0000

On 11/27/2013 02:06 PM, Dave Crocker wrote:
>      I'm assuming that providing meaningful protection takes a statement
> beyond "encrypt all your links".  Perhaps it doesn't, but I thought I'd
> ask...

I'd say that'd be a fine thing if we could get someone who'd
done that job to help write it.

S.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 27 Nov 2013 09:53:22 -0500

+1 But I don't have time to help write it.

This proposal is similar to what we did in the CA industry after the
Iranian attack against Comodo. We had a series of information sharing
sessions. One important consequence for me personally was that
Symantec/VeriSign gave a presentation on how the root key management system
works which means that I now feel free to talk about that. Although I later
discovered that the entire system that I and others considered a highly
proprietary trade secret is actually described in detail in the CPS and CP.

The big change in mindset was that we recognized that an attack on one of
us is an attack on all and that security is not a competitive
differentiator. DigiNotar damaged the entire industry.

One other point, this is not just one government or even governments. There
is a group of ex-NSA staff semi-openly touting 'cyber-defense' operations
that include an 'offshore' component. The only reason I can think of to
have the operations offshore and boast about them is to perform acts that
would be criminal in the US.

The individuals behind the company concerned were very senior in a previous
administration and quite possibly believe that they can get away with
criminal behavior because the establishment will cover up for them.

Lawlessness begets lawlessness. People who are accustomed to ignore the
laws while working for the government are inclined to continue to ignore
them.

I expect that in the immediate aftermath of Snowdonia there will be
something of an exodus from Fort Meade. And many of those people will take
their knowledge with them in their head and have no compunction about
putting that knowledge to 'commercial' use.

It is all going to end in a very ugly scandal but the perpetrators can do a
lot of damage between now and their day of reckoning. People need to put
down strong defenses.

On Wed, Nov 27, 2013 at 9:06 AM, Dave Crocker <[email-masked]> wrote:

> wonder whether it would be practical and useful for the IETF to produce a
> basic draft that gives guidance to other ISP and enterprise operators about
> the steps they should take to protect their traffic.
>
> _______________________________________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perpass
>

-- 
Website: http://hallambaker.com/

---

From: Randy Bush <[email-masked]>
Date: Thu, 28 Nov 2013 11:43:35 +0800

>> beyond "encrypt all your links".  Perhaps it doesn't, but I thought
>> I'd ask...
> I'd say that'd be a fine thing if we could get someone who'd done that
> job to help write it.

may not work out as well as we might wish, as folk who have done it may
not want to disclose details.  but i am sure there are folk who have not
done it who will be happy to tell others how they should run their
networks :)

randy

---

From: Dave Crocker <[email-masked]>
Date: Wed, 27 Nov 2013 20:38:36 -0800

> done it who will be happy to tell others how they should run their

with such a warm and inviting tone being offered at this stage of the 
topic, i'm sure everyone will feel quite comfortable testing their 
suggestions and comments, to produce a frank and open exchange that will 
vet the contents of the draft document.

d/

---

From: "Christian Huitema" <[email-masked]>
Date: Wed, 27 Nov 2013 21:15:21 -0800

-----Original Message-----
From: perpass [mailto:[email-masked]] On Behalf Of Dave Crocker
Sent: Wednesday, November 27, 2013 6:06 AM
To: perpass
Subject: [perpass] "Guide to intranet protection"?

d/

---

From: Dave Crocker <[email-masked]>
Date: Wed, 27 Nov 2013 21:23:18 -0800

> done that job to help write it.

So let's move to the meta-question:  what's the benefit that such 
experts (or their organizations) will accrue from participating?

One possible point is that intra-network security probably gets better, 
the more neighbors there are with equally good security.  Fewer sources 
of badness, and all that...

d/

---

From: "Christian Huitema" <[email-masked]>
Date: Wed, 27 Nov 2013 21:37:04 -0800

> vet the contents of the draft document.

Randy is quite right. The attacks reported in the news article were against
the private optical fibers linking the geographically distributed data
centers of large companies like Google or Yahoo. A discussion about that
should start with the folks in charge of securing these data centers at
Google, Yahoo, Facebook, Microsoft, et cetera. I can see some difficulties,
because a fair bit of the data centers architectures is probably treated as
trade secret. And I am really not sure that the IETF is the best place to
conduct such discussions.

-- Christian Huitema

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 28 Nov 2013 00:44:18 -0500

Dave,

This is not really an intranet issue, this is a backbone issue. The two are
completely different where security is concerned.

There is already a body of literature on setting up corporate VPNs to
secure an Intranet. That is all happening at the IP layer and IPSEC is a
good tool.

What is going on at Google and Yahoo is that they have got to be so large
that they are deploying routers that are designed for supporting backbone
traffic and they are essentially backbone providers. And the body of work
that exists on IPSEC is just not relevant to that part of their problem.

It is not a unique problem though. AT&T, Comcast and the backbone providers
have the same sort of issues. They are problems that arise from carrying
traffic that is coming from someone else who may have a different idea
about how confidential it is to the carrier.

A group of large enterprises like ICI faced a similar problem a while back
and formed the Jericho forum to tell manufacturers what sort of IT security
they needed. It might be useful for a group of like minded companies that
buy the biggest of the big iron to come together and hammer out security
requirements to hand off to the vendors.

Might not wok though. Jericho forum closed recently but I can't see any
sign of the data level security they were talking about. There is this
place in Fort Meade that it seems could use some of that rather badly and
they are not the only ones.

---

From: Randy Bush <[email-masked]>
Date: Thu, 28 Nov 2013 14:08:37 +0800

> Randy is quite right.

has to happen occasionally

> The attacks reported in the news article were against the private
> optical fibers linking the geographically distributed data centers of
> large companies like Google or Yahoo. A discussion about that should
> start with the folks in charge of securing these data centers at
> Google, Yahoo, Facebook, Microsoft, et cetera. I can see some
> difficulties, because a fair bit of the data centers architectures is
> probably treated as trade secret. And I am really not sure that the
> IETF is the best place to conduct such discussions.

we had/have the same oroblem with datacenter* wgs.  the folk who really
do it think of it as secret sauce.  so it becomes the vendors trying to
sell solutions to problems they don't understand.  hell, i don't even
know iij datacentr technology to any depth.

randy

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 28 Nov 2013 10:29:01 +0100

Am 28.11.13 06:15, schrieb Christian Huitema:
> taking steps to encrypt their (internal) traffic.

I have not seen those articles (unless you refer to the data centers of 
Google & co).

Do you hae some pointers?

Ciao
Hannes

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 28 Nov 2013 10:00:13 +0000

> has to happen occasionally

:-)

> do it think of it as secret sauce.  

Yep, that's the problem all right. However, we do sometimes
get folks who are willing to document stuff like that that
they've done, so if there are any out there then they should
know that we'd love to see that draft, could get them some
help with writing it if that's needed and with moving it
through the process-maze.

And as Dave said, there is a potential benefit if more
organisations secure their internal networks since a lot of
them are inter-dependent one way or another via cloudy-foo
stuff.

Cheers,
S.

---

From: Eric Burger <[email-masked]>
Date: Thu, 28 Nov 2013 06:36:29 -0500

I would offer the problem is not securing links (VPN) or backbones (links), but to remind people of this (seemingly obsolete) IETF principle called ‘end-to-end.’ In the context of security, it is that one cannot presume security because you happen to own the network. Bad things happen within a single, private network for a whole host of reasons. So, lock down stuff at the endpoints.

Put eight pages of boilerplate on the above and I just wrote the entire ID Dave suggested.

---

From: Norbert Bollow <[email-masked]>
Date: Thu, 28 Nov 2013 12:47:18 +0100

Eric Burger <[email-masked]> wrote:

> I would offer the problem is not securing links (VPN) or backbones
> (links), but to remind people of this (seemingly obsolete) IETF
> principle called ‘end-to-end.’ In the context of security, it is that
> one cannot presume security because you happen to own the network.
> Bad things happen within a single, private network for a whole host
> of reasons. So, lock down stuff at the endpoints.

Yes, end-to-end encryption is absolutely essential.

But protecting "who communicated with whom" data, which can also be
highly sensistive, requires further steps in addition to end-to-end
encryption.

Greetings,
Norbert

---

From: Eric Burger <[email-masked]>
Date: Thu, 28 Nov 2013 06:59:44 -0500

Agreed. That was not what Dave was asking for, however. He was looking for how an ISP can secure their customer network.

One could advocate for TOR or SilentCircle style solutions, where all traffic is forced to a particular node where one obfuscates next hops, add in dummy packets, make all packets the same size, and transmit a continuous train of packets.

The good news is that would make it orders of magnitude harder for someone monitoring the network to do traffic analysis.

The bad news is it would make it trivial for someone to monitor the network if they own the ingress node. This is in fact why a number of repressive regimes are demanding the IETF create such protocols, under the guise of “please make sure our packets do not flow to the US/UK/Iran/{favorite boogeyman of the moment}."

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 28 Nov 2013 15:19:46 +0100

I think the biggest problem is in the believe that there would be 
something as "inside" and "outside". Outside is supposed to be the 
Internet and inside is the secure enterprise network. There is just the 
perception that stuff inside is secure. Just per definition it is secure.

I have seen this many times.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 28 Nov 2013 06:28:50 -0800

> highly sensistive, requires further steps in addition to end-to-end

I've been skeptical about the avid focus on using TLS, because it isn't 
end-to-end.   Object-based mechanisms, like PGP or TLS, are what's 
needed for that.

Then it was pointed out exactly the above, namely that these mechanisms 
protect little or none of the meta-data, whereas TLS does protect it 
(except within transit nodes,  between TLS sessions, of course)

d/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 28 Nov 2013 09:41:25 -0500

> done it who will be happy to tell others how they should run their

That is less of an issue than you might imagine.

Absent an external threat, companies see each other as competitors. An
external attack changes minds very quickly.

I don't think anyone is going to be putting a network diagram of their
datacenter on the table but that isn't really the point. It is the
processes and controls that matter, not the instances. Microsoft and Google
cooperate here to write a specification but they don't usually share source
code. And even if they do as in Chromium, it does not make a great deal of
difference as competitors don't start from the same legacy.

The number of people who move companies in the valley is very large. The
chance that any of the details are really very secret is small. NDAs stop
people blabbing about it to likely attackers, but thats about all.

The business value in sharing the information is greater than the business
value in keeping it secret.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 28 Nov 2013 06:47:32 -0800

d/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 28 Nov 2013 09:49:59 -0500

> know iij datacentr technology to any depth.

Just to be clear, when I said they are more willing to share than you said
earlier, I was referring to a closed door sharing in some members only
forum. That model definitely works.

The IETF might play a role in brokering the setting up of such an
organization but any sharing is not going to take place in public and not
in the IETF and it is going to take place at a certain degree of
abstraction.

---

From: Albert Lunde <[email-masked]>
Date: Thu, 28 Nov 2013 09:25:47 -0600

Loosely on topic, there is this recent blog entry from Twitter on what 
they did to implement Forward Security:

https://blog.twitter.com/2013/forward-secrecy-at-twitter-0

The main point seems to be that they dynamically rotate through SSL 
session keys and try to avoid storing them anywhere long-term.

They in turn cite:

Imperial Violet "How to botch TLS forward secrecy"

https://www.imperialviolet.org/2013/06/27/botchingpfs.html

---

From: Eric Burger <[email-masked]>
Date: Sat, 30 Nov 2013 10:32:25 -0500

In the shameless self-promotion department, this IS my day job. See http://s2erc.georgetown.edu/projects/cyberISE/ for the theoretical work and http://gcsc.georgetown.edu/ if one needs an operational venue.

On Nov 28, 2013, at 9:49 AM, Phillip Hallam-Baker <[email-masked]> wrote:

> Just to be clear, when I said they are more willing to share than you said earlier, I was referring to a closed door sharing in some members only forum. That model definitely works.
> 
> The IETF might play a role in brokering the setting up of such an organization but any sharing is not going to take place in public and not in the IETF and it is going to take place at a certain degree of abstraction.
> 
>  
> 
> --