[perpass] Source Routing [was Re: "Guide to intranet protection"?]

Eric Burger <eburger@standardstrack.com> Thu, 28 November 2013 11:59 UTC

Return-Path: <eburger@standardstrack.com>
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 5CE6F1AE061 for <perpass@ietfa.amsl.com>; Thu, 28 Nov 2013 03:59:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.278
X-Spam-Level:
X-Spam-Status: No, score=0.278 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779] autolearn=no
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 0vUegDwCALKX for <perpass@ietfa.amsl.com>; Thu, 28 Nov 2013 03:59:53 -0800 (PST)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8401AE016 for <perpass@ietf.org>; Thu, 28 Nov 2013 03:59:53 -0800 (PST)
Received: from ip68-100-74-215.dc.dc.cox.net ([68.100.74.215]:58330 helo=[192.168.15.104]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from <eburger@standardstrack.com>) id 1Vm0G3-0005am-16 for perpass@ietf.org; Thu, 28 Nov 2013 03:59:51 -0800
From: Eric Burger <eburger@standardstrack.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_1C0365F1-DFF5-4F79-8FE3-F03DE72C5283"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Message-Id: <D702BDC3-45C7-4076-9929-262E6C03729B@standardstrack.com>
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Date: Thu, 28 Nov 2013 06:59:44 -0500
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> <5297142D.6010101@cs.tcd.ie> <F1E81972-34D8-419A-95D7-61060CD3C3CD@cs.georgetown.edu> <20131128124718.357ee20f@quill>
To: perpass <perpass@ietf.org>
In-Reply-To: <20131128124718.357ee20f@quill>
X-Mailer: Apple Mail (2.1822)
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed
X-Source:
X-Source-Args:
X-Source-Dir:
Subject: [perpass] Source Routing [was Re: "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 11:59:54 -0000

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

On Nov 28, 2013, at 6:47 AM, Norbert Bollow <nb@bollow.ch> wrote:

> Eric Burger <eburger@cs.georgetown.edu> 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
> _______________________________________________
> perpass mailing list
> perpass@ietf.org
> https://www.ietf.org/mailman/listinfo/perpass