Re: [Trust-router] Considering delaying BOF Request

Sam Hartman <hartmans@painless-security.com> Thu, 16 May 2013 15:17 UTC

Return-Path: <hartmans@painless-security.com>
X-Original-To: trust-router@ietfa.amsl.com
Delivered-To: trust-router@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 996A621F9227 for <trust-router@ietfa.amsl.com>; Thu, 16 May 2013 08:17:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bkv+YfZE5+hm for <trust-router@ietfa.amsl.com>; Thu, 16 May 2013 08:17:28 -0700 (PDT)
Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 6164E21F91D8 for <trust-router@ietf.org>; Thu, 16 May 2013 08:17:28 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 528D12057B; Thu, 16 May 2013 11:14:42 -0400 (EDT)
Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B46ItrHZUw6Q; Thu, 16 May 2013 11:14:41 -0400 (EDT)
Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Thu, 16 May 2013 11:14:41 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 0E3E2440A; Thu, 16 May 2013 11:17:26 -0400 (EDT)
From: Sam Hartman <hartmans@painless-security.com>
To: David Chadwick <d.w.chadwick@kent.ac.uk>
References: <CDBA7A25.23081%josh.howlett@ja.net> <5194F38F.2050906@kent.ac.uk>
Date: Thu, 16 May 2013 11:17:26 -0400
In-Reply-To: <5194F38F.2050906@kent.ac.uk> (David Chadwick's message of "Thu, 16 May 2013 15:56:15 +0100")
Message-ID: <tsltxm3c5tl.fsf@mit.edu>
User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: Josh Howlett <Josh.Howlett@ja.net>, "trust-router@ietf.org" <trust-router@ietf.org>
Subject: Re: [Trust-router] Considering delaying BOF Request
X-BeenThere: trust-router@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "ABFAB Trust Router discussion list." <trust-router.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trust-router>, <mailto:trust-router-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/trust-router>
List-Post: <mailto:trust-router@ietf.org>
List-Help: <mailto:trust-router-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trust-router>, <mailto:trust-router-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 May 2013 15:17:32 -0000

>>>>> "David" == David Chadwick <d.w.chadwick@kent.ac.uk> writes:

    David> These only talk about the protocol and model, but not about
    David> how actual implementations are initially configured. Maybe my
    David> questions are only ones that Sam and his team of implementors
    David> can answer

Well, this list is most a protocol list, so you'll get a
protocol-centered answer here.

The trust router protocol needs to support fairly robust  filtering. In
particular I think it needs to support the following:

1) A COI managed at a single point (plus redundancy).
That COI membership information is flooded throughout the
network. Filters prevent announcements related to that COI from being
made except along the path that the COI administrator's announcements
would take.

2) Multiple points of administration equally trusted.  As an example if
Eduroam used this model then each continent could inject routes. There
would not be filters between continents, but there would be filters
rejecting routes from lower levels.

3) A model where some subset of the namespace is permitted to be
injected  by people delegated to administer that.  For example  say that
some entity in  kent.ac.uk is permitted to add any realm ending in
kent.ac.uk to a particular COI. Filters permit this but would reject
other routes.

Other models may be required.

Our current implementation only implements the temporary identity
protocol and does not yet implement the trust router protocol or
flooding.  As a result, the trust router, which really ends up just
being a temporary identity proxy, must be given complete topology of the
entire world at startup.

We have had discussions of configuration and proposed filter types on
the moonshot-community list, but those are not implemented yet.
I don't know how much of that will  make its way into the internet
drafts.  We will probably need to specify minimum filter support that
implementations need to have in order to be able to have secure
topology.

--Sam