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

["Keoh, Sye Loong" <[e-mail]>]

Dear all,

Sorry that I couldn't make it to the informal SOLACE meeting yesterday.

Carsten, I would also like to volunteer myself to work on a potential charter for a new group.

Regarding the potential scenarios where we can derive requirements, I think Building Automation System and BaCNET can be interesting for us too.

Looking forward to discussing further with you all this week.

Cheers
Sye Loong

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Carsten Bormann
Sent: zondag 4 november 2012 22:52
To: [e-mail]
Subject: [solace] Notes from the SOLACE ad-hoc at IETF85

Sunday 2012-11-04 15:10-16:10 Salon E

Attendance:
Behcet Sarikaya
Carsten Bormann
Jürgen Schönwälder
Kerry Lynn
Mehmet Ersue
Paul Chilton
Ulrich Herberg
Yoshihiro Ohba

This was an informal meeting that was intended to move forward our common understanding of what the SOLACE activity is going to be.

Carsten went quickly through the slides from the Vancouver IETF (http://www.ietf.org/proceedings/84/slides/slides-84-roll-11.pdf).
He stressed that the near term focus of SOLACE is soliciting contributions that provide a fleshed out view of the lifecycle, the players/roles and the security objectives of a specific scenario, together with the security protocols that can be used between specific roles to achieve these objectives.

We then mainly discussed two topics:


1) What is the best home for SOLACE?

One approach is to find a home in IRTF.
Several participants agreed:
-- this spans a couple of areas
-- IRTF can work in a relatively "sheltered" way
-- there may less of a need to go through an excruciating chartering
   process before we really understand the specific shape of the
   result that we can achieve

Other participants pointed out:
-- an IETF activity may be more focused on directly usable results
-- there are specific gaps such as the OLSRv2 security model that need
   input soon
-- there might even be a new M2M area in the IETF

Clearly, there wasn't consensus yet, but some more people leaned towards the IRTF approach.  This requires further discussion.
Ulrich, Yoshihiro, and Carsten volunteered for working on a potential charter for a new group.


2) What are the specific questions we want to ask for the contributions?

Questions that we would like to see covered in the contributions (in no particular order):

-- What are the specific roles in this scenario?
   Groups of nodes may differ in their trust relationships, in their
   role in running the lifecycle, in their security domain, in their
   constrainedness, ...  (e.g., in SEP2 a "meter" appears to be a very
   special role, having a trusted relationship to the backend, ...)
-- what is the topology between these roles?  (This may include both a
   security-focused point of view and a view based on physical,
   link-layer or network layer topology)
-- What is the trust model?
   Specifically, what is the chain of trust needed for the system to
   operate, how do the different roles relate to the trust model; are
   there classes of trust based on some specific property (such as
   "inside"/"outside" something)?
-- Is there anything done to secure group communications (multicast/broadcast)?
-- What are the elements of your lifecycle?  Do you handle events like
   an entire building changing hands?
-- How does your security really work, which security protocols are
   being used?
-- What gaps are there?  Where do we need additional specifications?
-- Constrainedness?  What are the resource requirements on the
   specific roles?  What groups of nodes are there?

We should try to obtain contributions at least from the following groups/for the following scenarios:
-- SEP2 (may need to be fleshed out wrt key management)
-- A simple home scenario that can be realized with PSKs
-- Cullen's Mothership scenario
-- ETSI M2M, maybe related to the EAP/PANA I-D and ETSI GBA
-- MANET scenarios such as that addressed by OLSRv2
-- AMI networking

Besides the I-Ds already identified, Kerry also has co-authored an interesting NIST paper that he will provide a reference to.


At the SAAG meeting Thu 1510-1710, we have a short presentation slot.
We should try to narrow down the set of choices so we can present something coherent to SAAG.  The intention is providing a heads-up of the activity, and make it clear that this activity is not trying to threaten any specific security area work but tries to benefit as much as possible from existing results.

Please send corrections and additions to these notes to the list.

Grüße, Carsten

_______________________________________________
solace mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/solace

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.