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

From: Carsten Bormann <[email-masked]>
Date: Sun, 4 Nov 2012 16:52:04 -0500

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

---

From: "Keoh, Sye Loong" <[email-masked]>
Date: Mon, 5 Nov 2012 13:53:22 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Carsten Bormann
Sent: zondag 4 november 2012 22:52
To: [email-masked]
Subject: [solace] Notes from the SOLACE ad-hoc at IETF85

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.

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.

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

We should try to obtain contributions at least from the following groups/for the following scenarios:

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.

Grüße, Carsten

_______________________________________________
solace mailing list
[email-masked]
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.

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 5 Nov 2012 08:58:27 -0500

> Looking forward to discussing further with you all this week.

So should we go forward with the lunch today?
Or should we try to find some other time?

Grüße, Carsten

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 5 Nov 2012 15:14:03 +0100

> Or should we try to find some other time?

My lunch slots are booked already for Mon-Wed.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Ulrich Herberg <[email-masked]>
Date: Mon, 5 Nov 2012 06:39:26 -0800

Lunch will be difficult for me today.

Ulrich

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 5 Nov 2012 09:41:49 -0500

> My lunch slots are booked already for Mon-Wed.

Given that so many people came yesterday, I was not expecting that everybody who was present would come today.
So this would be mainly for the benefit of the people who came in late yesterday.

We'll also have another sync point in the SAAG meeting.

Grüße, Carsten

---

From: "Keoh, Sye Loong" <[email-masked]>
Date: Mon, 5 Nov 2012 14:48:20 +0000

Hi Carsten,

Would be great if I can join you for lunch today to know more about the discussion yesterday.

Cheers

Sye Loong

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]]
Sent: maandag 5 november 2012 15:42
To: Juergen Schoenwaelder
Cc: Keoh, Sye Loong; [email-masked]
Subject: Re: [solace] Notes from the SOLACE ad-hoc at IETF85

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Mon, 05 Nov 2012 10:17:39 -0500

Carsten Bormann <[email-masked]> wrote:

    CB> -- Is there anything done to secure group communications
    CB> (multicast/broadcast)?  

I think that any specific session keying is out of scope.
This is about building trust between objects and network controllers.

-- 
Michael Richardson
-on the road-

---

From: "Eggert, Lars" <[email-masked]>
Date: Mon, 5 Nov 2012 15:25:27 +0000

Hi,

just for the record, I'd be very supportive of seeing this under the IRTF. But it's in the end obviously the call of the folks who will do the work.

Lars

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 5 Nov 2012 16:29:45 +0100

We have the OPS area directorate lunch on Monday.

Cheers, 
Mehmet 

> From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext
> Juergen Schoenwaelder
> Sent: Monday, November 05, 2012 3:14 PM
> To: Carsten Bormann

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 5 Nov 2012 10:35:27 -0500

> Would be great if I can join you for lunch today to know more about the discussion yesterday.

OK, let's meet up at the end of the apparea meeting (1 h from now) at the front.
Of course, everybody else who missed yesterday's discussion or just wants to continue the chat is welcome.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 5 Nov 2012 11:19:19 -0500

> 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

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 5 Nov 2012 14:34:47 -0500

> Of course, everybody else who missed yesterday's discussion or just wants to continue the chat is welcome.

So we had a ~ one-hour lunchtime discussion today, too.

Akbar Rahman
Carsten Bormann *)
Oscar Garcia-Morchon
Stephen	Chasko
Sye Loong Keoh
Yoshihiro Ohba *)
*) = were present yesterday, too

I din't take notes quite as diligently as yesterday.
We went through the work ahead as it seems to materialize for a phase 1:

-- come up with a call for contributions (which specifically lists the
   questions we ask) -> (November)
-- solicit the contributions (Internet-Drafts) -> (maybe till January)
-- sort and structure, define a common terminology
   (have a first Webex call maybe in January)
-- maybe get some of the contributions to rev based on the emerging terminology
-- summarize and define work for phase 2
   (Orlando IETF)

We also discussed that we want to de-emphasize greenfield
"architecture" work and make this more of a phenomenology of existing
and emerging solutions.  It is important that the solutions are
actually described in the contributions in sufficient detail that we
can do meaningful comparisons and derive architecture by detecting
patterns.

On the "how do we do this" side of things, I explained a bit how
previous IRTF RGs have worked and how different they were.  E.g., some
of these actually went so far to produce their own protocol
specifications.  This is very likely not something we want to do.

Next steps:
1) Go to the SAAG meeting on Thursday.
2) See list above.

Grüße, Carsten