Subject: Re: [6tisch] [6tisch-security] minutes of the 2014-11-04 6TiSCH call

From: Thomas Watteyne <[email-masked]>
Date: Thu, 20 Nov 2014 22:51:47 -0800

Michael,

[adding 6TiSCH ML]

I have archived those minutes at
https://bitbucket.org/6tisch/meetings/wiki/141104_webex_security for
completeness.

In the process, I made the changes below, please let me know if that
doesn't work for you:

OLD:
 - Thomas
 - Michael
 - Jonathan
 - Kris
 - Pascal
NEW:
 - Thomas Watteyne
 - Michael Richardson
 - Jonathan Simon
 - Kris Pister
 - Pascal Thubert

OLD:
Just prior to the 6tisch meeting,
NEW:
Just prior to the 6tisch WG meeting at IETF91,

Thomas

On Thu, Nov 20, 2014 at 2:30 PM, Michael Richardson <[email-masked]>
wrote:

>
> Attending:
>  - Thomas
>  - Michael
>  - Jonathan
>  - Kris
>  - Pascal
>
> In this call we returned to getting section 3 ready for proposing
> as part of the 6tisch architecture.  This resulted in the post at:
>    http://www.ietf.org/mail-archive/web/6tisch/current/msg02690.html
>
> These minutes describe how we got to this text.
>
> We returned to the question:
>   * how do we get communication between the joining node and the JCE?
>     * IP-IP tunnel between join assistant and JCE
>     * use pre-existing DODAG, DAO sent up to parent and DODAG root,
> informing existence
>     * second DODAG. non-storing
>     * (not exclusive) 6TiSCH track for join traffic
>
> We discussed the last item for awhile in the context of Deterministic
> Ethernet and other 6tisch track allocations.   We discussed how we could
> use
> the track and QoS features to either protect the network from DDoS from
> joining nodes, or alternatively, lower the time for a network to form by
> allocating more bandwidth.
>
> We came back to the question:
>    "does the JCE have connectivity to joining node?" (and how)
>
> After much discussion we came to the conclusion in the 2014-11-04
> discussion
> that we would use the existinng DODAG, even if it was a storing DODAG.
>
>   * MR: part of goal is to prevent DoS. If we agree that in general in a
>       6TiSCH network, we can replace networks with 6TiSCH tracks, that's a
>       possibilty. We can add QoS on those tracks. Maybe we don't need to
> think
>       too hard about option 4.
>
> Near the end of the discussion a new option was proposed, which is to not
> have the joining node join the DODAG (the Join Assistant would send a DAO
> on
> behalf of the joining node), but rather for the JCE to use loose source
> routing to reach the Joining Node.  The JCE would send via the Join
> Assistant, and it would get that address from the DAR message that the 6LBR
> would share.
>
> At the end of this meeting, mcr took the action to update the document,
> which
> was included in the text pointed to above.
>
> Just prior to the 6tisch meeting, it was pointed out that the we couldn't,
> according to specification, put link local addresses into the RH2, because
> their link scope would be unclear.  We are investigating what other options
> we have, because the resulting system has very little state per joining
> node.
>
> ====
>
>
>
> --
> Michael Richardson <[email-masked]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
>
> _______________________________________________
> 6tisch-security mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch-security
>
>