Subject: [6tisch] ANIMA vs. Join process

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 22 May 2015 16:12:48 +0000

Dear all :

Following up after the interim today:

For the sake of proposing an item for the next charter, we need to specify how much we overlap with ANIMA and how we'll proceed to cover that overlap.
ANIMA will be the place where the autonomic bootstrap will be defined. They will have an eye to try and maintain applicability to IoT but that is not a constraint in the charter.
OTOH, everything specific to 6TiSCH (e.g. discussions that involve MAC message and operations) and that does not involve autonomic / certificate-based operation as ANIMA will focus on must also be handled at home.

Suggestions?

Pascal

---

From: Rene Struik <[email-masked]>
Date: Fri, 22 May 2015 12:55:04 -0400

I think 6tisch should continue its own security-related work and *not* 
shift this to someone else's plate. Obviously, this does not preclude 
taking advantage of intelligent ideas that may originate elsewhere and 
see whether these have some value for us. Please note that "elsewhere" 
is certainly not limited to Anima or IETF (there are lots of 
"intelligent life forms" outside IETF).

Rene

On 5/22/2015 12:12 PM, Pascal Thubert (pthubert) wrote:
> For the sake of proposing an item for the next charter, we need to 
> specify how much we overlap with ANIMA and how we’ll proceed to cover 
> that overlap.
>
> ANIMA will be the place where the autonomic bootstrap will be defined. 
> They will have an eye to try and maintain applicability to IoT but 
> that is not a constraint in the charter.
>
> OTOH, everything specific to 6TiSCH (e.g. discussions that involve MAC 
> message and operations) and that does not involve autonomic / 
> certificate-based operation as ANIMA will focus on must also be 
> handled at home.
>
> Suggestions?
>
> Pascal
>
>
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Tom Phinney <[email-masked]>
Date: Fri, 22 May 2015 10:03:34 -0700

I have to concur with René here. There is much advantage, and no
harm, in continuing the security discussions along the line of "What
does 6TiSCH need/require? What else would be useful?"

One need only observe the current extensive, fruitful discussion on
CoMI rehashing to see the benefits of running a parallel process "in
house" (so to speak), even if in the end the group determines that
some other effort such as ANIMA is providing all, or nearly all, of
what is required. If in the end such a determination is made (that
the work of another group is roughly suitable for 6TiSCH), then if
necessary either influence that other group (e.g., ANIMA) to make
whatever minor adaptations are required to make their work more
suitable for 6TiSCH, or build upon their work with a derivative
6TiSCH-specific variant.

-Tom

=====

On 2015.05.22 09:55, Rene Struik wrote:

I think 6tisch should continue its
own security-related work and *not* shift this to someone else's
plate. Obviously, this does not preclude taking advantage of
intelligent ideas that may originate elsewhere and see whether
these have some value for us. Please note that "elsewhere" is
certainly not limited to Anima or IETF (there are lots of
"intelligent life forms" outside IETF).

Rene

Dear all :

For the sake of proposing an item for the
next charter, we need to specify how much we overlap with
ANIMA and how we’ll proceed to cover that overlap.

ANIMA will be the place where the
autonomic bootstrap will be defined. They will have an eye
to try and maintain applicability to IoT but that is not a
constraint in the charter.

OTOH, everything specific to 6TiSCH (e.g.
discussions that involve MAC message and operations) and
that does not involve autonomic / certificate-based
operation as ANIMA will focus on must also be handled at
home.

Suggestions?

Pascal

---

From: Kris Pister <[email-masked]>
Date: Fri, 22 May 2015 10:13:01 -0700

+1

On 5/22/2015 9:55 AM, Rene Struik wrote:
>> ANIMA will be the place where the autonomic bootstrap will be 
>> defined. They will have an eye to try and maintain applicability to 
>> IoT but that is not a constraint in the charter.
>>
>> OTOH, everything specific to 6TiSCH (e.g. discussions that involve 
>> MAC message and operations) and that does not involve autonomic / 
> email:[email-masked]  | Skype: rstruik

---

From: Michael Richardson <[email-masked]>
Date: Fri, 22 May 2015 16:31:54 -0400

> specify how much we overlap with ANIMA and how we’ll proceed to cover

Agreed, and to pass the IESG, it be clear what the boundary is.

    > that is not a constraint in the charter.

ANIMA has two design teams at present:
      http://trac.tools.ietf.org/wg/anima/trac/wiki
      Signaling (approved) and Bootstrap (not yet approved).
      http://trac.tools.ietf.org/wg/anima/trac/wiki/Bootstrap

There are many interactions between signaling and bootstrap, the details
of which are not yet clear.   The bootstrap protocol "messages" needs to be
carried back to the Domain owner via the signaling protocol, and the
signaling protocol needs to be secured...  I am not convinced GDNP is the
right signaling protocol, and there are many other existing choices.
I don't think that the ANIMA signaling protocol will be suitable for 6tisch
industrial uses (and may unsuitable for other LLN uses too).

The bootstrap protocol is not identical to what I have proposed here,
but as one is based upon the other, the 10% discrepancy will go away.

What is unknown on the ANIMA side, and it became clear last year during
the 6tisch-security design team, is that while we might think we know
what we want from the protocol, we are not unanimous.

As such, a critical rechartering item is to produce a set of security
(protocol) requirements for 6tisch.

This includes answering questions like:
   - how is the ASN securely communicated to:
         - prospective joining nodes ("pledges" or "ducklings")
         - hung-over nodes (slept too long/clock drift/didn't write it to flash)
   - if the PANID used for joining is the same as that for production.
   - what 802.15.4(-2015) encryption and authentication modes will be used.
   - what kind of join DoS attacks are relevant to defend against
   - what "zero-touch" means

Some of this is "we need a solution that does X", and some of this is,
"we plan to use mode X, which imposes a constraint Y"

ps: I don't claim that we don't have answers to the above questions.
I claim that we haven't written it down in a document that the WG
has adopted.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Xavier Vilajosana <[email-masked]>
Date: Sun, 24 May 2015 06:34:07 +0200

Hi,

I support Tom's comment. I think our work during these years influenced
RestCONF to produce COMI. I think that as long as we have the skills we
should keep exploring the security aspects of 6tisch and influence (if
needed) other groups when things can be aligned.

regards,
Xavi

2015-05-22 19:13 GMT+02:00 Kris Pister <[email-masked]>:

> taking advantage of intelligent ideas that may originate elsewhere and see
> whether these have some value for us. Please note that "elsewhere" is
> certainly not limited to Anima or IETF (there are lots of "intelligent life
> forms" outside IETF).
>
> Rene
>
> For the sake of proposing an item for the next charter, we need to specify
> how much we overlap with ANIMA and how we’ll proceed to cover that overlap.
>
> They will have an eye to try and maintain applicability to IoT but that is
> not a constraint in the charter.
>
> certificate-based operation as ANIMA will focus on must also be handled at
> home.
>
>
>
> Suggestions?
>
>
>
> Pascal
>
>
> 6tisch mailing [email-masked]://www.ietf.org/mailman/listinfo/6tisch
>
>
>
> --
> 6tisch mailing [email-masked]://www.ietf.org/mailman/listinfo/6tisch
>
>
>