Re: [obscurity-interest] GNU Free Call

Christian Huitema <huitema@microsoft.com> Tue, 22 March 2011 19:13 UTC

Return-Path: <huitema@microsoft.com>
X-Original-To: obscurity-interest@core3.amsl.com
Delivered-To: obscurity-interest@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A32F53A67D3 for <obscurity-interest@core3.amsl.com>; Tue, 22 Mar 2011 12:13:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.577
X-Spam-Level:
X-Spam-Status: No, score=-10.577 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M+y9BWAslGoB for <obscurity-interest@core3.amsl.com>; Tue, 22 Mar 2011 12:13:11 -0700 (PDT)
Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 4851D3A676A for <obscurity-interest@ietf.org>; Tue, 22 Mar 2011 12:13:11 -0700 (PDT)
Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 22 Mar 2011 12:14:44 -0700
Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.1.270.2; Tue, 22 Mar 2011 12:14:43 -0700
Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.185]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.01.0270.002; Tue, 22 Mar 2011 12:14:43 -0700
From: Christian Huitema <huitema@microsoft.com>
To: Dean Willis <dean.willis@softarmor.com>, Marc Petit-Huguenin <petithug@acm.org>
Thread-Topic: [obscurity-interest] GNU Free Call
Thread-Index: AQHL6E8+UwSik3q5QUeollajyEFtb5Q41QKggAEwkACAABV+gP//nUww
Date: Tue, 22 Mar 2011 19:14:43 +0000
Message-ID: <22F6318E46E26B498ABC828879B08D4F0E331B@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com>
References: <4C32EC9B-E2F6-4352-BE65-29E7D5CEEEA3@softarmor.com> <22F6318E46E26B498ABC828879B08D4F0E2BF3@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> <4D88D1F2.1050909@acm.org> <09677888-DF8F-4E55-91AC-BFDA47B0B6BF@softarmor.com>
In-Reply-To: <09677888-DF8F-4E55-91AC-BFDA47B0B6BF@softarmor.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.90]
Content-Type: multipart/alternative; boundary="_000_22F6318E46E26B498ABC828879B08D4F0E331BTK5EX14MBXW653win_"
MIME-Version: 1.0
Cc: "obscurity-interest@ietf.org" <obscurity-interest@ietf.org>
Subject: Re: [obscurity-interest] GNU Free Call
X-BeenThere: obscurity-interest@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Discussion of communications obscurity and real-time communications." <obscurity-interest.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/obscurity-interest>, <mailto:obscurity-interest-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/obscurity-interest>
List-Post: <mailto:obscurity-interest@ietf.org>
List-Help: <mailto:obscurity-interest-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/obscurity-interest>, <mailto:obscurity-interest-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Mar 2011 19:13:15 -0000

> With  a P2P communications architecture it might be possible to discover that people in the local broadcast domain want to hook up. Or to discover that they are injured and require emergency assistance, or that they are fellow emergency responders trying to organize a response.
P2P technologies have an ambiguous relation with privacy. On one hand, P2P avoids reliance on a server that can be compromised or spied upon. On the other hand, it is fairly easy to hack into a P2P cloud and mount attacks such as spoofing, denial of service or spying. Hence my remark about "local" P2P service. If the communication channel can be established without sending packets outside the "local area," then it becomes somewhat immune to attacks emanating from outside that area.

Thinks to check for, and avoid, include reliance on specific "bootstrap" servers, or reliance on the DNS. I am also skeptical about using too much multicast, even on a local network, as multicast by nature is not very discrete. Thinks to seek, on the other hand, include usage of different channels for bootstrap, e.g. BlueTooth, NSP, or local Wi-Fi, and P2P cloud structures that limit connections to approved parties.

-- Christian Huitema