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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 28 November 2013 10:00 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: perpass@ietfa.amsl.com
Delivered-To: perpass@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 702021AD957 for <perpass@ietfa.amsl.com>; Thu, 28 Nov 2013 02:00:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jO3IUHhKRB8h for <perpass@ietfa.amsl.com>; Thu, 28 Nov 2013 02:00:14 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 071111A1F58 for <perpass@ietf.org>; Thu, 28 Nov 2013 02:00:14 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 065FABE5C; Thu, 28 Nov 2013 10:00:13 +0000 (GMT)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jl-HZjX0fWuP; Thu, 28 Nov 2013 10:00:12 +0000 (GMT)
Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id CAA11BE59; Thu, 28 Nov 2013 10:00:12 +0000 (GMT)
Message-ID: <5297142D.6010101@cs.tcd.ie>
Date: Thu, 28 Nov 2013 10:00:13 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Randy Bush <randy@psg.com>, Christian Huitema <huitema@huitema.net>
References: <5295FC4F.7060309@dcrocker.net> <5295FDE8.5000402@cs.tcd.ie> <m2mwkpgpi0.wl%randy@psg.com> <5296C8CC.2060508@dcrocker.net> <027a01ceebfb$df99f290$9ecdd7b0$@huitema.net> <m2d2llgisa.wl%randy@psg.com>
In-Reply-To: <m2d2llgisa.wl%randy@psg.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: 'perpass' <perpass@ietf.org>, dcrocker@bbiw.net
Subject: Re: [perpass] "Guide to intranet protection"?
X-BeenThere: perpass@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " <perpass.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/perpass>, <mailto:perpass-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/perpass/>
List-Post: <mailto:perpass@ietf.org>
List-Help: <mailto:perpass-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/perpass>, <mailto:perpass-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Nov 2013 10:00:15 -0000

On 11/28/2013 06:08 AM, Randy Bush wrote:
>> 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.  

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.