Re: [solace] Notes from the SOLACE ad-hoc at IETF85

Carsten Bormann <cabo@tzi.org> Mon, 05 November 2012 16:19 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: solace@ietfa.amsl.com
Delivered-To: solace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 415B021F87E0 for <solace@ietfa.amsl.com>; Mon, 5 Nov 2012 08:19:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.249
X-Spam-Level:
X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXsQLvbWfgkl for <solace@ietfa.amsl.com>; Mon, 5 Nov 2012 08:19:30 -0800 (PST)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 17ED021F87CF for <solace@ietf.org>; Mon, 5 Nov 2012 08:19:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id qA5GJNul015930; Mon, 5 Nov 2012 17:19:23 +0100 (CET)
Received: from dhcp-9336.meeting.ietf.org (dhcp-9336.meeting.ietf.org [130.129.11.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 15F27275; Mon, 5 Nov 2012 17:19:22 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <24237.1352128659@sandelman.ca>
Date: Mon, 5 Nov 2012 11:19:19 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <E94A5096-2F85-4859-A1FC-D454A3961199@tzi.org>
References: <105963F3-4106-43D4-8F63-5478B617BE36@tzi.org> <24237.1352128659@sandelman.ca>
To: Michael Richardson <mcr@sandelman.ca>
X-Mailer: Apple Mail (2.1499)
Cc: "solace@ietf.org" <solace@ietf.org>
Subject: Re: [solace] Notes from the SOLACE ad-hoc at IETF85
X-BeenThere: solace@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "\"Smart Object Lifecycle Architecture for Constrained Environments\" discussion list" <solace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/solace>, <mailto:solace-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/solace>
List-Post: <mailto:solace@ietf.org>
List-Help: <mailto:solace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/solace>, <mailto:solace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Nov 2012 16:19:31 -0000

On Nov 5, 2012, at 10:17, Michael Richardson <mcr@sandelman.ca>; wrote:

> 
> Carsten Bormann <cabo@tzi.org>; wrote:
> 
>    CB> -- Is there anything done to secure group communications
>    CB> (multicast/broadcast)?  
> 
> I think that any specific session keying is out of scope.

Good thing we don't have a scope yet :-)
Good point, though.
But I have a slightly different view of how we should be running this first phase.

> This is about building trust between objects and network controllers.

(I don't know what a network controller is (we still need to define this kind of term) -- that would be one probably of the "roles" that we find out more about.)

I see the objective of soliciting the contributions as follows: to understand the lifecycle management in a number of solutions for specific scenarios down to a level of technical detail that we can learn from that and start to draw technical conclusions about them.

For the soutions, it is certainly interesting to hear whether they can manage trust relationships that make use of groups, and, if yes, how they do that.
So I would encourage the submitter to highlight this in their contributions.
Indeed, I would like to know how the solutions do the session keying, and/or how flexible they are with respect to the protocols they use for that.

Now I agree that the specific ways to do session keying are likely to be out of scope for any architecture we develop out of these contributions, but without an existence proof I would feel uneasy about any solution that claims to be able to manage lifecycles involving groups.

Grüße, Carsten