[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

tls                                                           R. Lucas
Internet Draft                              Cisco International Limited
Intended status: Standards Track                     September 13, 2017
Expires: March 17, 2018

                             DTLS Multicast
                  draft-lucas-dtls-multicast-00.txt
Abstract

  This proposal to provide a secure multicast 1-to-N or M-to-N device
  capability, with the same level of reliability as the underlying
  multicast network, also aims to be light-weight and supported
  by a very constrained device. Guaranteed reliability would be
  provided by an additional protocol working in co-operation with it.

  The aim is to support end to end secure communications in the edge
  device world of IoT where the transport methods will vary or at
  least change once the IP realm is left. Hence there is no
  dependence on Ipv6 or IP or CoAP and no restrictions that might be
  introduced if too specific an end node application was implied. It
  is network independent, it just must be possible to transmit and
  receive frames in multicast.

  This can be achieved with simply a minimal change to the DTLS
  behavior and using current DTLS libraries. DTLS headers are not
  changed, additional headers are used in the packets before the DTLS
  traffic.

  DTLS Multicast keeps the layer concept pure and independent, hence
  it can be used for routing something that is not CoAP.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on March 17, 2018.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors. All rights reserved.
Lucas                   Expires March 17, 2018                [Page 1]


Internet-Draft               DTLS Multicast              September 2017

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with
   respect to this document.

   Code Components extracted from this document must include Simplified
   BSD License text as described in Section 4.e of the Trust Legal
   Provisions and are provided without warranty as described in the
   Simplified BSD License.




Contents
1.  Introduction                                                     3
2.  Background                                                       4
3.  Restrictions / Assumptions                                       4
4.  Terminology                                                      4
5.  DTLS Multicast Proposal                                          5
6. Significant differences between DTLS Multicast and DTLS Unicast    7
7.  Logical Traffic Types become Channels                             7
7.1  CLIENT channel format                                           8
7.2  ELECTION channel format                                         8
7.3  CONTROL channel format                                          8
7.4  SUBGROUP channel format                                         9
7.5  SENDER channel format                                           9
8.  Message definitions                                              9
9.  How to use the DTLSMulticast structures                          12
9.1  DTLSMulticastRADIUS                                            12
9.2  DTLSMulticastJoin                                              13
   9.2.1  sender_channel                                            13
   9.2.2  max_subgroups                                             13
   9.2.3  Group controller election flags NE and EL                  14
   9.2.4  Member send ability flags TX and RX.                      14
9.3  DTLSMulticastAddSA                                             14
9.4  DTLSMulticastDropSA                                            15
9.5  DTLSMulticastReconnect                                         15
10.  Joining a DTLS multicast group                                  16
11.  Notes on cipher suites                                         17
12.  Receiving DTLS multicast data                                  17
13.  Sending DTLS multicast data                                    19

Lucas                   Expires March 17, 2018                [Page 2]


Internet-Draft               DTLS Multicast              September 2017
14.  Leaving a DTLS multicast group                                  20
15.  DTLS multicast group key rotation                               20
16.  Use of CONTROL, SUBGROUP and CLIENT channels for key rotation   21
17.  DTLS multicast controller failure detection and election protocol
                                                                    24
18.  Acknowledgements                                               26
19.  Security Considerations                                        26
20.  IANA Considerations                                            26
21.  References                                                     27
21.1  Normative References                                          27
21.2  Informative References                                        27
Author's Address                                                    27



1.  Introduction

  This proposal provides a secure multicast M-to-N device (or 1-to-N)
  capability with the same level of reliability as the underlying
  multicast network. This proposal does not provide guaranteed
  reliability by itself, this would be provided by an additional
  protocol working in co-operation with it.

  There is no assumption that the DTLS will be transported over IPv6
  or IPv4 or even IP at all. This allows the method to be used both
  inside and outside the IP realm making it very useful for end to end
  security in the world of IoT and edge field devices that may use
  other transport methods.

  Machines from the most powerful servers to very constrained edge
  devices may be connecting via several different indirect methods
  hence all communication must take place inside the multicast domain
  and a DTLS multicast group must handle additional messaging between
  the machines in that group. Importantly, to do this, the proposal
  maintains close compatibility with the existing DTLS protocol with
  the simple exception of using additional headers in the packets
  before the DTLS traffic.

  The header structures and message definitions are defined herein
  followed by descriptions of how to use them. (There is no actual
  implementation code.)

  This proposal provides solutions to assure the following and
  explains them in more detail in chapter five:-

  o  Establishment of a GSA (Group Security Association, see RFC 3740)
     where all group members use the same multicast data security

Lucas                   Expires March 17, 2018                [Page 3]


Internet-Draft               DTLS Multicast              September 2017
     ciphersuite.
  o  Forward security. Ex-members can no longer decrypt group messages
     nor send new encrypted messages
  o  Backward confidentiality. A new members cannot decrypt messages
     sent before it became a member.
  o  Support for both 1-to-N and M-to-N topologies.
  o  Group size is limited only by RAM constraints.
  o  Multicast data confidentiality.
  o  Multicast data replays are protected. Can be detected and
     ignored.
  o  Multicast data group authentication. Only guarantee data
     integrity if all members are trusted.

  Note that this proposal does not provide a solution for source
  authentication and data integrity. Authentication knows which group
  sent a message, not which member sent it.


2.  Background

  DTLS is currently a point-to-point communications protocol. In the
  past there have been draft proposals to expand this to be multicast
  and to deal with security. Notably, and listed under informative
  references, keoh-tls-multicast-security and
  keoh-dice-multicast-security which have both expired. They are in
  the author's opinion interesting proposals but they assume DTLS over
  IPv6 (see keoh-dice-multicast-security-08 sec 4.4) which may not
  always be true. DTLS cannot be assumed to be transported over IPv6
  (or even IP for that matter). KEOH-DICE also breaks compatibility
  with the existing DTLS header.

  This DTLS-Multicast draft proposal seeks to be network independent
  and to use existing headers.

3.  Restrictions / Assumptions

   Any machine may be connecting to a DTLS multicast group via a
   gateway (NAT, firewall or even protocol translator) so all
   communication must take place within the multicast domain only.

   A DTLS multicast group must therefore handle any additional
   messaging to allow for the agreement of any keys, configuration data
   and behaviours between the machines in the group.

4.  Terminology

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  document are to be interpreted as described in RFC 2119 [RFC2119].

  In this document, these words will appear with that interpretation
Lucas                   Expires March 17, 2018                [Page 4]


Internet-Draft               DTLS Multicast              September 2017
  only when in ALL CAPS. Lower case uses of these words are not to be
  interpreted as carrying significance described in RFC 2119.

  In this document, the characters ">>" preceding an indented line(s)
  indicates a statement using the key words listed above. This
  convention aids reviewers in quickly identifying or finding the
  portions of this RFC covered by these keywords.

This specification also uses the following terminology:

   o  Group Controller (or just Controller): The entity that is
      responsible for creating a multicast group, establishing security
      associations among authorized group members and renewing/updating
      the security associations.
      Note that a controller (or member capable of being a controller)
      must also be a sender.

   o  Sender: The Sender is an entity that sends data to the multicast
      group. In a 1-to-N multicast group only a single sender transmits
      data to the group.  In an M-to-N multicast group (where M <= N),
      M group members are senders.  All senders must also be listeners.

   o  Listener: A Listener is an entity that receives multicast
      messages from a multicast group. All listeners must be Members.

   o  Member: An entity that has joined the group.

   o  (SA) Security Association: A set of policy and cryptographic
      keys that provide security services to network traffic that
      matches that policy.
      Note that different types of traffic in the multicast group may
      be protected by different security associations.

   o  Group Security Association (GSA): A set of Security Associations
      (SAs) that together define how a group communicates securely
      [RFC3740].

   O  Keying material: Data that is specified as part of the SA which
      is needed to establish and maintain a cryptographic security
      association, such as keys, key pairs, and IVs [RFC4949].


5.  DTLS Multicast Proposal

  This proposal provides a secure multicast M-to-N device capability
  with the same level of reliability as the underlying multicast
  network.

  This proposal does not provide guaranteed reliability by itself,
  this would be provided by an additional protocol working in
  co-operation with it.
Lucas                   Expires March 17, 2018                [Page 5]


Internet-Draft               DTLS Multicast              September 2017

  This proposal aims to be as light-weight as possible so that it can
  be supported (in its minimal form) by a very constrained device.

  This proposal maintains compatibility with the existing DTLS
  protocol with the exception of additional headers in the packets
  before the DTLS traffic.

   This proposal provides a solution for:

   a.   Establishment of a GSA: A secure mechanism to distribute
        keying materials, multicast security policies and security
        parameters to members of the multicast group.

   b.   Multicast data security ciphersuite: All group members use the
        same ciphersuite to protect the authenticity, integrity and
        confidentiality of multicast messages.  The ciphersuite is part
        of the GSA.

   c.   Forward security: Devices that leave the group will not have
        access to any future GSAs. This ensures that a past member
        device cannot continue to decrypt confidential data that is
        sent in the group.  It also ensures that this device cannot
        send encrypted and/or integrity protected data after it leaves
        the group.
        The GSA update mechanism is part of the key management scheme.
        Note that the controller can weaken this as part of the
        key management policy for performance reasons and/or to reduce
        network traffic overhead.

   d.   Backward confidentiality: A new device joining the group will
        not have access to any old GSAs. This ensures that a new member
        device cannot decrypt data sent before it joins the group. The
        key management scheme should ensure that the GSA is updated to
        ensure backward confidentiality.  Note that the controller can
        weaken this as part of the key management policy for
        performance reasons and/or to reduce network traffic overhead.

   e.   Multicast communication topology: Both 1-to-N (one sender with
        multiple listeners) and M-to-N (multiple senders with multiple
        listeners) communication topologies are supported

   f.   Multicast group size: The number of listeners is limited by the
        RAM on the group controller. The protocol allows for up to
        2^128 unique listeners.
        The number of senders is limited by the RAM on the listeners.
        The protocol allows for up to 2^31 unique senders.
        Note that all Senders must also be Listeners.

   g.   Multicast data confidentiality: Multicast messages can be
        encrypted according to the cipher suite selected by the
Lucas                   Expires March 17, 2018                [Page 6]


Internet-Draft               DTLS Multicast              September 2017
        controller.

   h.   Multicast data replay protection: Replayed messages can be
        detected and ignored.

   i.   Multicast data group authentication: Multicast messages can be
        authenticated according to the cipher suite selected by the
        Group Controller. The multicast group key (which is known to
        all group members) is used to provide authenticity to the
        multicast messages. It does not guarantee data integrity unless
        all group members are trusted.

  This proposal does not provide a solution for:

   a.   Source authentication and data integrity: Messages can be
        authenticated to have come from a member of the group, but
        cannot be tracked to a specific member within the group.


6. Significant differences between DTLS Multicast and DTLS Unicast

  Additional headers are added before the DTLS and other encrypted
  traffic to allow the traffic types to be identified.

  The existing DTLS (unicast) standard allows either party to trigger
  a key rotate and associated epoch change. DTLS Multicast allows this
  on the CLIENT channel but key rotation and epoch change on all other
  channels are managed by the group controller.

  Message acknowledgement and retry is not supported by any channel
  apart from the CLIENT channels. If the network is lossy then the
  listeners may not receive all the control or data messages. Any
  protocol using DTLS multicast must be designed to expect this and
  act appropriately.

7.  Logical Traffic Types become Channels

  To allow both control and data traffic to be carried on the same
  multicast group, this proposal inserts an additional header at the
  start of the data frame to allow the different logical traffic types
  to be separated into "channels".

  This header is defined as:

    struct {
        unit32 channel;
    } DTLSMulticast;

Channels are assigned as follows:
    Channel range       Name              Description
    0                   CLIENT            Client traffic channels
Lucas                   Expires March 17, 2018                [Page 7]


Internet-Draft               DTLS Multicast              September 2017
    1                   ELECTION          Controller election channel
    2                   CONTROL           Controller management channel
    3 .. 0xFFFF_FFFF    SUBGROUP/SENDER   Data channels

7.1  CLIENT channel format

  The CLIENT channel is used by members to connect to the multicast
  group and communicate with the group controller.

  Messages on the CLIENT channel start with a
  DTLSMulticastClientPrefix header to allow individual client's
  connections to be identified.
  This is defined as:

    struct {
        uint8  client[16];
    } DTLSMulticastClientPrefix;

  The "client" value should be chosen randomly each time an entity
  attempts to join the multicast group.

  Normal DTLS traffic follows the DTLSMulticastClientPrefix header.

  The encrypted data frames are DTLSMulticastClient messages.

  Apart from the additional DTLSMulticast and
  DTLSMulticastClientPrefix headers, the CLIENT channel is a normal
  DTLS connection.

7.2  ELECTION channel format

  The ELECTION channel is used to handle election of controllers when
  the Active controller fails and controller election has been
  permitted for the group.

  Messages on the ELECTION channel are sent as a DTLSCiphertext using
  The Election security association.  The election security
  association is provided to the member in a DTLSMulticastAddSA
  message over the CLIENT, CONTROL or SUBGROUP channels.

  The encrypted data frames are DTLSMulticastElection messages.

7.3  CONTROL channel format

  The CONTROL channel is used for key distribution and other
  Management actions by the controller.

  Messages on the CONTROL channel are sent as a DTLSCiphertext using
  the Group security association.  The group security association is
  initially provided to the member in a DTLSMulticastAddSA message
  over the CLIENT channel. The controller may update the group
Lucas                   Expires March 17, 2018                [Page 8]


Internet-Draft               DTLS Multicast              September 2017
  security association using a DTLSMulticastAddSA message over the
  CLIENT, CONTROL or SUBGROUP channels.

  The encrypted data frames are DTLSMulticastControl messages.

7.4  SUBGROUP channel format

  The SUBGROUP channels are used by the controller to restrict key
  distribution and other management actions to the members of the
  sub-group.

  Messages on the SUBGROUP channel are sent as a DTLSCiphertext using
  the Specific sub-group security association. The sub-group security
  association is initially provided to the member in a
  DTLSMulticastAddSA message over the CLIENT channel. The controller
  may update the group security association using a DTLSMulticastAddSA
  message over the CLIENT, CONTROL or SUBGROUP channels.

  The encrypted data frames are DTLSMulticastControl messages.

7.5  SENDER channel format

  The SENDER channels are used to carry the application data. A member
  with transmit privileges will only be allowed to transmit on a
  singleSENDER channel and will be the only member allowed to send on
  that channel.

  Messages on the SENDER channel are sent as a DTLSCiphertext using
  the group security association.  The group security association is
  initially provided to the member in a DTLSMulticastAddSA message
  over the CLIENT channel. The controller may update the group
  security association using a DTLSMulticastAddSA message over the
  CLIENT, CONTROL or SUBGROUP channels.

  Note: The encrypted data frames are application data - their format
  is NOT defined in this standard and varies according to the
  application.

8.  Message definitions

    enum {
        radius(0), joinReq(1), joinRsp(2), leave(3), acknack(4),
        addsa(5), dropsa(6), reconnect(7), heartbeatReq(8),
        heartbeatRsp(9), reqsa(10),
            (255)
    } DTLSMulticastType;

    struct {
        uint8  code;
        uint8  identifier;
        uint16 length;
Lucas                   Expires March 17, 2018                [Page 9]


Internet-Draft               DTLS Multicast              September 2017
        uint8  data[length - 4];
    } DTLSMulticastRADIUS;

    struct {
        uint32 sender_channel;  // Current sender channel (0 if
                                // listener only)
        uint32 max_subgroups;   // Maximum number of subgroups
                                // supported
        uint8  flags;           // Mode and capability flags
                                //   xxxx xxx0 "NE": Member cannot
                                //   take part in controller elections
                                //   xxxx xxx1 "EL": Member can take
                                //   part in controller elections
                                //   xxxx xx0x "RX": Member wishes to
                                //   listen only
                                //   xxxx xx1x "TX": Member wishes to
                                //   be a sender
                                //   0000 00xx "ZZ": For future
                                //   expansion
    } DTLSMulticastJoinReq;

    struct {
        uint32 firstSenderChannel;  // First sender channel (inclusive)
        uint32 lastSenderChannel;   // Last sender channel (inclusive)
    } DTLSMulticastJoinRsp;

    struct {
      // Empty structure
    } DTLSMulticastLeave;

    enum {
        noError (0),
        unknown (1),
        unauthorised (2),
        resourcesExceeded (3),
        notJoined (4),
        (255)
    } DTLSMulticastErrorCodes;

    struct {
        DTLSMulticastErrorCodes error;
        uint8 subcode;
    } DTLSMulticastAckNack;

    struct {
        uint16 epoch;           // DTLS multicast epoch for the key
        uint8  flags;           // Mode and capability flags
                                //   xxxx x000 "EL":  SA is for the
                                //   election channel
                                //   xxxx x001 "GP":  SA is the group
                                //   SA
Lucas                   Expires March 17, 2018                [Page 10]


Internet-Draft               DTLS Multicast              September 2017
                                //   xxxx x010 "SG":  SA is for a
                                //   subgroup channel
                                //   xxxx x011     :  Reserved for
                                //   future expansion
                                //        ...         ...
                                //   xxxx x111     :  Reserved for
                                //   future expansion
>>                              //   xxxx 0xxx "RX":  Member MUST NOT
                                //   send on the channel
>>                              //   xxxx 1xxx "TX":  Member MAY send
                                //   on the channel
                                //   0000 xxxx "ZZ":  For future
                                //   expansion, must be zero
        uint8  timeout;         // Channel timeout period (sec)
        uint32 channel;         // Channel number
        SecurityParameters key; // Encryption/MAC parameters, see
                                // RFC5246:A.6
    } DTLSMulticastAddSA;

    struct {
        uint32 channel;
    } DTLSMulticastDropSA;

    struct {
        uint32 controller_magic;
    } DTLSMulticastReconnect;

    struct {
      uint32 magic;                 // Random number to match Req/Rsp
    } DTLSMulticastHeartbeatReq;

    struct {
      uint32 magic;                 // Echo of
      DTLSMulticastHeartbeatReq.magic
    } DTLSMulticastHeartbeatRsp;

    struct {
      uint32 channel;
    } DTLSMulticastReqSA;


    //----------------------------------------------------------------

    enum {
        addsa, dropsa, reconnect, (255)
    } DTLSMulticastControlType;

    struct {
        DTLSMulticastControlType type;
        select (type) {
            case addsa:         DTLSMulticastAddSA;
Lucas                   Expires March 17, 2018                [Page 11]


Internet-Draft               DTLS Multicast              September 2017
            case dropsa:        DTLSMulticastDropSA;
            case reconnect:     DTLSMulticastReconnect;
        } content;
    } DTLSMulticastControl;

    //-----------------------------------------------------------------

    enum {
        radius, addsa, dropsa, join, leave, heartbeatReq, heartbeatRsp,
        acknack, reqsa, (255)
    } DTLSMulticastClientType;

    struct {
        DTLSMulticastClientType type;
        select (type) {
            case radius:        DTLSMulticastRADIUS;
            case addsa:         DTLSMulticastAddSA;
            case dropsa:        DTLSMulticastDropSA;
            case join:          DTLSMulticastJoin;
            case leave:         DTLSMulticastLeave;
            case heartbeatReq:  DTLSMulticastHeartbeatReq;
            case heartbeatRsp:  DTLSMulticastHeartbeatRsp;
            case acknack:       DTLSMulticastAckNack;
            case reqsa:         DTLSMulticastReqSA;
        } content;
    } DTLSMulticastClient;

    // ----------------------------------------------------------------

    struct {
        uint32  age;
        uint8   uuid[16];
    } DTLSMulticastElectionVote;

    enum {
        vote(0), (255)
    } MulticastElectionType;

    struct {
        MulticastElectionType type;
        select (type) {
            case vote:          DTLSMulticastElectionVote;
        } content;
    } DTLSMulticastElection;

9.  How to use the DTLSMulticast structures

9.1  DTLSMulticastRADIUS

>> The multicast group MAY choose to authenticate clients before they
  are authorised to become members of the multicast group.  If this is
Lucas                   Expires March 17, 2018                [Page 12]


Internet-Draft               DTLS Multicast              September 2017
  required, the RADIUS protocol may be used with encapsulation in
  DTLSMulticastRADIUS messages. Once the RADIUS handshake has
  completed and the client has been authorised to join the group, the
  client proceeds with a DTLSMulticastJoin message.

>> If the group requires authorisation of clients, the controller MUST
  respond to all messages apart from DTLSMulticastRADIUS messages with
  an "unauthorised" DTLSMulticastAckNack message until the client is
  authorised.

  If the group does not require authorisation of clients, the
>> controller MUST consider the client as authorised as soon as the
  DTLS CLIENT channel is established and the client can immediately
  send a DTLSMulticastJoin message.

  Note that the controller is not required to use RADIUS to
  authenticate the client. The controller may instead use any
  information from the client DTLS connection to authenticate the
  client using some other protocol. Alternatively, the controller may
  simply allow all clients to join the group.


9.2  DTLSMulticastJoin

  The DTLSMulticastJoin is sent by a client to the controller on
  CLIENT Channels to indicate a client's wish to become a member of
  the group. The controller must respond with a DTLSMulticastAckNack
  to indicate if the request was successful.

>> The controller MUST respond to all messages apart from
  DTLSMulticastRADIUS and DTLSMulticastJoin messages with a
  "notJoined" DTLSMulticastAckNack message until the client has
  successfully joined the group.

  The parameters in the DTLSMulticastJoin message are described below.

9.2.1  sender_channel

  If the sender is sending a join message as a result of receiving a
  DTLSMulticastReconnect, it should indicate its previously assigned
  sender channel in this field so that the same channel can be
  reassigned by the new controller (as the new controller may not have
  the channel assignment list from the previous controller).

  This field should be set to 0 if the listener had no sender channel
  assigned.

9.2.2  max_subgroups

  This is used to indicate the capabilities of the member. Constrained
  devices may have limited memory and may only be able to support a
Lucas                   Expires March 17, 2018                [Page 13]


Internet-Draft               DTLS Multicast              September 2017
  small number of subgroups and possibly none at all. Devices with
  larger memory and processing capabilities may be able to support
  many sub-groups. A member should try to set this as large as
  possible so that the controller is not constrained in how it assigns
  and manages the subgroups.

9.2.3  Group controller election flags NE and EL

  A group may or may not support group controller elections. If a
  group does not support elections, the sysadmin must ensure that an
  alternative solution is in place to ensure the availability of a
  group controller. Alternative solutions are beyond the scope of this
  document.

  If any member wishes to take part in group controller elections, it
  should set the DTLSMulticastJoin.flags.EL otherwise it should set
  DTLSMulticastJoin.flags.NE.

9.2.4  Member send ability flags TX and RX.

  Some members may only be listeners to the group. These members do
  Not need to be able to send and do not need a SENDER channel
  assigned. Theyshould set the DTLSMulticastJoin.flags.RX flag.

  Some members may wish to take be able to send data to the group.
  They should set the DTLSMulticastJoin.flags.TX flag.
>> The group controller MUST track the assigned sender channels so that
  the same sender channel is never simultaneously assigned to multiple
  entities.

  The controller should respond to the "join" with an "ack" or "nack".
  If the controller requires the client to authenticate before it is
  allowed to join the group, the controller should return an
  "unauthorised" error. The client should then begin a RADIUS
  authentication using DTLSMulticastRADIUS messages (which simply
  encapsulate standard RADIUS frames). If the RADIUS authentication is
  successful then the client should re-send its DTLSMulticastJoin
  message to join the group.

  If the client join is successful, the controller will then send one
  or more DTLSMulticastAddSA messages to provide the appropriate
  security keys to the client.

9.3  DTLSMulticastAddSA

  This message is sent by a controller to provide a security
  association to one or more members. This allows access to a channel
  and allows new security associations to be provided for a channel
  (e.g. during epoch change).

  The group security association is sent with the GP flag set. The
Lucas                   Expires March 17, 2018                [Page 14]


Internet-Draft               DTLS Multicast              September 2017
  same security association is used for the CONTROL channel and all
  SENDER channels. If the member is only allowed to listen then the RX
  flag is set. If the member is allowed to send data then the TX flag
  is set and the assigned SENDER channel is indicated in the "param"
  field.

  The SUBGROUP channel security associations are sent with flags
  ZZ, RX and SG.

  The SUBGROUP channel is indicated in the "channel" field.  Only the
  active controller is allowed to send traffic on a SUBGROUP channel.

  The ELECTION channel security association is sent with flags ZZ, EL
  and TX.

>> The controller SHOULD set the "channel" field to the unix timestamp
>> when the member joined the group. The member MUST store this value
  and use it as the "age" field in later  ***JS

  The timeout field is used to indicate the timeout/repeat value in
  seconds for that channel.

  The DTLSMulticastAddSA message can be sent by the controller on a
  CLIENT channel, in which case it must be acknowledged with an "ack"
  Or Rejected with a "nack".

  The DTLSMulticastAddSA message can also be sent by the controller on
  A CONTROL or SUBGROUP channel, in which case it is not acknowledged.

9.4  DTLSMulticastDropSA

  This message is sent by a controller used to tell one or more
  listeners that a security association is no longer required. It
  should not be used as part of the group security because the
  controller has no guarantee that the listener has complied with the
  request. It is instead provided to allow the controller to help the
  listener maintain a minimal memory footprint.

  The message can be sent by the controller on a CLIENT channel, in
  which case it must be acknowledged with an "ack" or rejected with a
  "nack".

  The message can be sent by the controller on a CONTROL or SUBGROUP
  channel, in which case it is not acknowledged.

  9.5  DTLSMulticastReconnect

  This message is by a group controller used to tell listeners on the
  sub-channel to reconnect. This message is only sent by a new group
  controller after a group controller election has completed and is
  used to ensure that the listeners establish new CLIENT connections
Lucas                   Expires March 17, 2018                [Page 15]


Internet-Draft               DTLS Multicast              September 2017
  to the new group controller.

  Each time a controller wants clients to reconnect, it generates a
  new "controller_magic" value.  The controller then sends as many
  reconnect messages as necessary on the CONTROL or SUBGROUP channels
  until it is confident that all listeners have reconnected. If a
  listener receives multiple "reconnect" messages (e.g. due to
  retransmission on a single channel or received on multiple
  channels), the listener can use the "controller_magic" field to
  determine if this is a new reconnect request or simply a repeat of
  an earlier reconnect message.

  The message can be sent by the controller on the CONTROL or SUBGROUP
  channels and is not acknowledged.

  When a listener receives a reconnect message with a new
  "controller_magic" value, it should discard its CLIENT connection
  and repeat the JOIN process.

  The listener does not need to discard any other security association
  information so can continue to receive (and send) messages on the
  SENDER channels.  This ensures that the multicast group continues to
  operate normally during the controller election and recovery
  process.

10.  Joining a DTLS multicast group

  This takes place after the standard IGMP Multicast JOIN for IPv4
  and/or appropriate other actions for other protocols.

>> An entity MUST use the following sequence to join a DTLS multicast
  group and obtain the multicast key material.

  When an entity wishes to JOIN a DTLS multicast group, it generates a
  new random 16 byte client ID then connects to the group controller
  on the CLIENT channel as defined above. Note that the CLIENT channel
  has DTLSMulticast and DTLSMulticastClientPrefix headers before the
  DTLS traffic.

  The DTLS handshake takes place in the usual way and the CLIENT
  channel is established.

  The joining entity has now become a member of the group. It then
  sends a DTLSMulticastJoin message on the CLIENT channel. The
  controller will reply with an "ack" or "nack". If the controller
  responds with a "nack" then the client will not be given the
  decryption keys for the group's traffic and the controller will
  close the DTLS connection.

  If the controller responded with an "ack" then the controller
  follows up with one or more "addsa" messages on the CLIENT channel
Lucas                   Expires March 17, 2018                [Page 16]


Internet-Draft               DTLS Multicast              September 2017
  to allow the member to become a listener (and possibly a sender) on
  the appropriate channels.

11.  Notes on cipher suites

  Equivalent cipher suites must be used for all security associations
  including the CLIENT channels. Clients may need to authenticate to
  the group controller using different identity keys, but must use
  equivalent encryption and hash modes.

  For example, the following are considered equivalent cipher suites
  because all use AES-128 in CBC mode with a SHA-256 hash even though
  they use different identity keys.

      TLS_RSA_WITH_AES_128_CBC_SHA256          = {0x00,0x3C};
      TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256  = {0xC0,0x23};
      TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256   = {0xC0,0x25};
      TLS_PSK_WITH_AES_128_CBC_SHA256          = {0x00,0xAE};

  A cipher suite that used AES-256, a different mode (such as CTR or
  GCM) or a different hash (such as SHA-1 or SHA-384) would not be
  considered equivalent.

  All security associations apart from the CLIENT channel have
  explicitly shared security parameters and should indicate the
  equivalent TLS_PSK_xxx cipher suite.

12.  Receiving DTLS multicast data

  A listener should apply the following rules in the order below when
  deciding whether to accept a message:

>> The active group controller MUST listen to all messages on the
  CLIENT channel so that it can communicate with all the members and
  handle join requests from new entities.

>> All standby group controllers MUST listen to messages on the CLIENT
  channel to detect a failure of the active group controller to
  respond to new join requests.

  A listener
>>     MUST ignore all messages on the CLIENT channel apart from those
      identified with its own client ID.

>>     MUST ignore all messages on any SUBGROUP channels for which it
      does not have a security association.

>>-    MUST ignore all messages that are not on the last known good
      epoch for that channel, the "current" epoch or the "next" epoch.

>>     MUST ignore CONTROL, SUBGROUP and SENDER messages on the last
Lucas                   Expires March 17, 2018                [Page 17]


Internet-Draft               DTLS Multicast              September 2017
      known good epoch for that channel and with an earlier or equal
      sequence number to the last known good sequence number for that
      channel.

  A listener
>>     SHOULD accept all remaining messages.

>>     SHOULD attempt to decrypt and authenticate all accepted
      messages.
      If the message is valid, the client should update its values for
      last known good epoch and sequence number for that channel then
      process the message content.

  There is no retry mechanism for DTLS multicast traffic so the
  listener must take this into account when handling lost or
  fragmented packets. Fragmentation *is* supported for DTLS multicast
  but the listener must be able to discard incomplete fragmented
  packets.

  A client should only ever need to store a maximum of two security
  associations for a channel (remember that all SENDER channels share
  the same group security association).

  These are either:
      "last" + "current"
          This is the situation after a key rotation where not all
          senders have switched to the "current" epoch
  or
      "current" + "next"
          This is the situation during a key rotation when no senders
          have switched to the "next" epoch.

>> A client SHOULD track the following information for all channels
  that it is listening on:
      channel_id          4 bytes
      epoch               2 bytes
      sequence_number     6 bytes

  where "epoch" and "sequence_number" are the epoch and
  sequence_number from the last good packet received on that channel.

  If a key rotation takes place and the client is still tracking
  senders on the "last" epoch, the client can discard its security
  association for the "last" epoch.  Note that a client may choose to
  keep the "last" security association for a short period of time (a
  few seconds) to allow for any delayed packets on the "last" security
  association to be received and decrypted.

  When the listener receives a message on the "next" epoch security
  association but has no security association for that epoch, it
  should send a "reqsa" message to the controller to request the
Lucas                   Expires March 17, 2018                [Page 18]


Internet-Draft               DTLS Multicast              September 2017
  necessary security association data. The controller will respond
  with an "ack" or "nack". If the controller responds with an "ack",
  it will then send the listener an "addsa" message with the security
  association which the listener should "ack" in the usual way. If the
  controller responded with a "nack" then the the listener is not
  permitted to access data in the new epoch.

13.  Sending DTLS multicast data

>> A sender MUST NOT send messages on a channel unless it has been
  granted the right to transmit on that channel by the controller in
  the security association.

>> A sender MUST send messages in the normal DTLS manner with
  incrementing sequence numbers starting from zero.

  When sending encrypted packets, the sender MUST ensure that the
  packets do not have duplicate IV with any other packets sent with
  the same security association including packets sent by other
  devices. Two possible ways to ensure this are:
   1)  Ensure that the packet's IV is truly random, so a collision is
       not likely given the size of the IV compared to the maximum
       number of packets sent on that security association
   or
   2)  Use the channel ID for the top 32 bits of the IV and use any
       other suitable method to derive the remaining bits. For some
       cipher modes, this may allow a sequential number assignment
       (which is lower overhead than random number generation). For
       other cipher modes, a pseudo-random number with suitable
       entropy gathering may be sufficient.

>> A sender MUST use the security association of the "current"
  multicast epoch.

  If this would cause the sequence number would wrap, the sender MUST
  NOT send any more messages on its channel. The sender must instead
  LEAVE then JOIN the TLS multicast group indicating a sender_channel
  value of zero so that it obtains a new channel and can safely
  restart its sequence number from zero.

  Note that the group controller should have performed a key rotation
  on the channel before any sequence counters were due to wrap, so
  this scenario indicates either a fault in the group controller or a
  network with very high packet loss.

  All changes of epoch are co-ordinated by the group controller as
  part of the key rotation.

  When the sender receives a valid message on the "next" epoch
  security association, it should:

Lucas                   Expires March 17, 2018                [Page 19]


Internet-Draft               DTLS Multicast              September 2017
      discard the security association information for the "last"
      epoch

      copy the security association information from the "current"
      epoch to the "last" epoch

      copy the security association information from the "next" epoch
      to the "current" epoch

      clear the security association information for the "next" epoch

      set the "next" epoch to the "current" epoch + 1

      reset its sender sequence number for the "current" epoch to zero

14.  Leaving a DTLS multicast group

>> All members SHOULD indicate their wish to leave a DTLS multicast
  group

  The member sends a DTLSMulticastLeave message to the controller on
  its CLIENT channel. The controller will acknowledge this message.

  The listener has now left the group.

>> When a listener leaves the group, the controller SHOULD perform a
  key rotation on all channels that the listener had access to so that
  the listener can no longer send or receive messages on the multicast
  group.

  A controller can consider the listener as having left the group if
  its CLIENT channel connection is lost (e.g. explicit close or no
  response to heartbeats from the controller).

15.  DTLS multicast group key rotation

  The group controller must maintain the integrity and correct
  operation of the group.
  This requires the group controller to:

  o  Update the necessary security associations if listeners leave the
     group
  o  Update a security association before any sender's sequence number
     wraps

  The group controller may also choose to update security associations
  at other times depending on policy that is outside the scope of this
  document.

  Group key rotation takes place for a security association as
  follows:
Lucas                   Expires March 17, 2018                [Page 20]


Internet-Draft               DTLS Multicast              September 2017

  o  The controller generates a new random key
  o  The controller calculates the "next" epoch by adding 1 to the
     "current" epoch
  o  The controller sends DTLSMulticastSA messages containing the new
     security association to the appropriate listeners using the
     SUBGROUP and/or CLIENT channels
  o  The controller sends one or more an empty messages on the CONTROL
     channel using the new security association and a sequence number
     of zero.

  If no multicast messages are lost, all senders will see the empty
  message on the CONTROL channel and all subsequent messages will be
  sent using the "next" epoch.

  If multicast messages are unreliable, some senders may not see the
  empty message on the MASTER channel and may continue to send
  messages on what they think is the "current" epoch. As soon as they
  see a message on the "next" epoch from one of the other senders,
  however, they will switch to the "next" epoch.

  If a controller sees multiple messages from a sender on what the
  controller considers to be the "last" epoch (and what the sender
>> considers to be the "current" epoch), the controller MAY repeat one
  or more empty messages on the CONTROL channel so that the sender
  sees them and switches to the "next" epoch.

16.  Use of CONTROL, SUBGROUP and CLIENT channels for key rotation

  For groups with few members, it is feasible to use the CLIENT
  channels for key rotation as this is a reliable mechanism.  The
  group controller can simply update each listener's security
  association individually.

  The group controller can therefore easily ensure that:
      1)  The new security association is only delivered to the
          appropriate listeners
  and
      2)  The listener has received the new security association

  This is a simple approach, but does not scale well as the number of
  members of the group increases. Although the approach is still
  technically possible, the time required to provide the key to each
  listener is an O(N) problem and will therefore cause an increasingly
  large delay between when the key rotation starts and when the key is
  available for use by the group.  This approach also generates an
  O(N)amount of traffic on the network.

  To allow for faster key distribution, the controller may choose to
  distribute the key using the CONTROL or SUBGROUP channels. This is
  not a reliable distribution mechanism as these messages are not
Lucas                   Expires March 17, 2018                [Page 21]


Internet-Draft               DTLS Multicast              September 2017
  acknowledged, but it does take advantage of the multicast nature of
  the group. The controller may choose to send the same "addsa"
  message multiple times to reduce the impact of message loss before
  considering the key rotation complete.

  The CONTROL group uses the Group Security Association so all
  listeners can receive messages on this channel. If a listener
  "leaves" the group, if it does not discard its group security
  association information, it can continue to receive and decrypt
  messages on this channel. If the CONTROL channel is used to provide
  the new security association, such a listener could decrypt the
  information for the new security association and therefore continue
  to decrypt the messages on the channel.

  This does not provide "Forward security" so an alternative solution
  must be available for the controller to rotate keys after a listener
  has left without forcing the controller to update each remaining
  listener individually on its CLIENT channel.

  When the controller accepts a member into the group, the controller
>> MAY add the member to one or more SUBGROUP channels. Each SUBGROUP
  Channel has its their own security association so any traffic to a
  SUBGROUP cannot be decrypted by listeners that are not members of
  the sub-group.

  When a key rotation is required and a listener must be excluded from
  receiving the new security association, the controller can use the
  SUBGROUP channels to send the "addsa" messages to the sub-groups
  that the listener is *not* a member of.

  The controller may add listeners to multiple SUBGROUPs (e.g. using a
  binary tree) so that the number of messages required to update the
  security association can be significantly reduced.

  To see the advantage of the subgroup approach, consider the
  situation when a member leaves a group:

  For a group with 10 remaining listeners, a simple key rotation using
  the CLIENT channels would require a minimum of
  {listeners * (addsa + ack)} = 20 messages to distribute the new
  security association.

  For a larger group with 1,000 remaining listeners, the minimum
  number of messages required is now {listeners * (addsa + ack)}=
  2,000 messages to distribute the new security association over the
  CLIENT channels.

  If, however, the controller had organised the listeners into a
  binary tree and assigned a SUBGROUP channel to each branch, the
  original 1,000 listeners would require a binary tree with a depth of
  10. Each branch on the tree would be assigned a subgroup to allow
Lucas                   Expires March 17, 2018                [Page 22]


Internet-Draft               DTLS Multicast              September 2017
  multicast communication with all members below that branch.

  After a member leaves the group, the controller can update the group
  security association for all the other members by sending an "addsa"
  message to the SUBGROUP channels on the branches that do not include
  the member that has just left, recursing down the branch as
  necessary to ensure all remaining members have received the message.
  This would require 9 "addsa" messages to be sent to SUBGROUP
  channels and one "addsa" + "ack" handshake on the remaining
  listener, a total of 11 messages.

  The controller would also need to perform a key rotation on the
  subgroups that the departing member was part of so that future
  messages to that subgroup could not be eavesdropped. The member
  would have been part of 9 groups so following the same approach, the
  number of additional messages required would be:

      Group branch depth      # members       # messages
          1                       512             8 + 2
          2                       256             7 + 2
          3                       128             6 + 2
          4                        64             5 + 2
          5                        32             4 + 2
          6                        16             3 + 2
          7                         8             2 + 2
          8                         4             1 + 2
          9                         2             0 + 2
                                                  -----
      Total messages:                                54


  With a simple binary tree approach, the number of messages required
  to rotate the keys after a listener leaves is reduced from 2,000 to
  a minimum of 65. The tree would require 1024 SUBGROUP channels.

  With a larger number of branches at each level of the tree, the
  depth of the tree could be reduced. This would in turn reduce both
  the number of SUBGROUP channels required and the number of messages
  required for key rotation after a member leaves the group.

  Note that constrained listeners that are not able to join a
  sufficient number of subgroups may still need to be individually
  updated by the controller in some circumstances.


  If a listener has not received the new security association but
>> receives messages on the new epoch, the listener SHOULD request the
  information using the "reqsa" message on its CLIENT channel. If the
  listener is unable to buffer the messages on the new security
  association whilst waiting for the controller to provide the
  security association details, the listener will be forced to drop
Lucas                   Expires March 17, 2018                [Page 23]


Internet-Draft               DTLS Multicast              September 2017
  the packets and data loss will occur.


17.  DTLS multicast controller failure detection and election protocol

>> All DTLS multicast groups MUST have a controller.  Some groups may
  allow controller election whereas others may have a fixed controller
  (which should be highly available if the group is to be reliable).

>> Groups that allow controller election MUST implement the DTLS
  multicast controller election protocol.

>> A member MUST NOT take part in the election unless it has been
  provided with the security association for the ELECTION channel and
  has been granted permission to send on that channel.

>> A member SHOULD NOT attempt to monitor the controller for failure
  unless it has been allowed to take part in the election.

>> Members allowed to take part in the election SHOULD monitor the
  controller for failure.

>> A member monitoring the controller MUST consider it to have failed
  if the following occurs:

  o  The member has lost its CLIENT channel connection AND the
     controller has not responded to at least 3 subsequent JOIN
     messages from the member
  OR
  o  No group key rotation has occurred but the sequence number on any
     SENDER channel has both MSBs set
  OR
  o  No subgroup key rotation has occurred but the sequence number on
     a valid packet on a SUBGROUP channel has both MSBs set

>> A member MAY consider the controller to have failed if the following
  occurs:

  o  At least 2 JOIN messages have been seen from a 3rd party on the
     JOIN channel but no controller response has been seen.

>> A member MUST trigger an election if it considers the controller to
  Have failed.

  The election uses the DTLSMulticastElection messages.  These are
  always sent as a DTLSCiphertext content on the ELECTION channel and
  protected by the election security association.

  If a member wishes to trigger an election or join an active
  election, it first generates a random UUID if it does not have one
  already. It then sends a DTLSMulticastElectionVote message on the
Lucas                   Expires March 17, 2018                [Page 24]


Internet-Draft               DTLS Multicast              September 2017
  ELECTION channel with the "current" epoch and sequence number zero,
  setting the "age" field to the "channel" value from the
  DTLSMulticastAddSA it received for the ELECTION channel and "uuid"
  field with its UUID.

>> If the current controller has not failed, it MUST join the election
  and send a DTLSMulticastElectionVote with age of 0 and its UUID.

  If any member of the election sees a DTLSMulticastElectionVote
  message with a LOWER age than its own, it should withdraw from the
  election.

  If any member of the election sees a DTLSMulticastElectionVote
  message with the SAME age as its own AND with a lower UUID, it
  should withdraw from the election.

  All members of the election should retransmit their
  DTLSMulticastElectionVote message after the ELECTION timeout period
  (as defined in the DTLSMulticastSA message for the ELECTION
  channel).

  A member of the election can consider itself the elected master if
  it is still a member of the election after two timeout periods have
  expired with no DTLSMulticastElection messages seen from other
  members.

  The above election process is not intended to be fair. It is instead
  deliberately designed to prioritise the election as follows:

      HIGHEST
          The existing controller (if it is still running)
          The oldest member in the election group
          ...
          The newest member in the election group
      LOWEST

  If the controller has changed as a result of the election, the new
  controller must trigger all members of the group to re-connect to it
  so it can reconstruct the details of the group and hence be able to
  handle JOIN, LEAVE and key rotation as necessary.

  The controller triggers all members to reconnect as follows:

     1)  It generates a random 32-bit number as the "controller_magic"
     2)  It sets its next sequence number to 0x8000_0000 for the
         CONTROL channel.
     3)  It sends a DTLSMulticastReconnect on the CONTROL channel.
     4)  It waits for DTLSMulticastSA[CONTROL].timeout seconds.
     5)  It repeats DTLSMulticastReconnect on the CONTROL channel.
     6)  It waits for DTLSMulticastSA[CONTROL].timeout seconds.
     7)  It repeats DTLSMulticastReconnect on the CONTROL channel.
Lucas                   Expires March 17, 2018                [Page 25]


Internet-Draft               DTLS Multicast              September 2017
     8)  It waits for DTLSMulticastSA[CONTROL].timeout seconds.
     9)  It continues to wait if any clients are still joining the
         group.
     10) It performs a key rotation for the CONTROL channel in the
         usual way.

  All listeners will receive the DTLSMulticastReconnect messages on
  the CONTROL channel in the usual way. Each listener inspects the
  "controller_magic" value and if it is new, drops its current MEMBER
  connection (which is no longer valid) and reconnects to the new
  group in the usual way.

>> A listener MUST ignore DTLSMulticastReconnect messages if they have
  the same "controller_magic" value as a previous
  DTLSMulticastReconnect message and the listener has already
  reconnected (or is in the process of reconnecting) to the group as a
  result of the earlier message.

>> The new controller SHOULD attempt to preserve the SENDER channel
  assigned to each sender when it reconnects to the group unless there
  is a conflict.

  Even if a controller fails, normal application traffic can continue
  to flow on the SENDER channels while the detection, election,
  reconnect and key rotation actions are taking place. If these
  actions all complete before any of the sender sequence numbers would
  need to wrap, there will be no impact on the flow of application
  data.

  New clients will not be able to connect to the group after a
  controller has failed until the election process has completed.

18.  Acknowledgements

  Parts of this document are a byproduct of the "aSSURE" project,
  partially funded by Innovate UK. It is provided "as is" and without
  any express or implied warranties,including, without limitation, the
  implied warranties of fitness for a particular purpose. The views
  and conclusion contained herein are those of the author and should
  not be interpreted as necessarily representing the official
  policies or endorsements, either expressed or implied, of the aSSURE
  project or Innovate UK.

19.  Security Considerations

  DTLS Multicast is all about security. Minor changes, for example
  adding headers in the frame before the traffic data helps
  establishes secure channels between 1 to N or M to N end nodes.

20.  IANA Considerations

Lucas                   Expires March 17, 2018                [Page 26]


Internet-Draft               DTLS Multicast              September 2017
  None

21.  References

21.1  Normative References

  [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

  [RFC4279]  Eronen, P., Ed., and H. Tschofenig, Ed., "Pre-Shared Key
             Ciphersuites for Transport Layer Security (TLS)", RFC
             4279, DOI 10.17487/RFC4279, December 2005,
             <http://www.rfc-editor.org/info/rfc4279>.

  [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
             (TLS)
             Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246,
             August 2008,
                <http://www.rfc-editor.org/info/rfc5246>.

  [RFC5847]  Badra, M., "Pre-Shared Key Cipher Suites for TLS with
             SHA-256/384 and AES Galois Counter Mode", RFC 5487,
             DOI 10.17487/RFC5487, March 2009,
             <http://www.rfc-editor.org/info/rfc5487>.

21.2  Informative References

  [RFC3740]   Hardjono, T. and B. Weis, "The Multicast Group Security
              Architecture", RFC 3740, DOI 10.17487/RFC3740, March 2004,
              <http://www.rfc-editor.org/info/rfc3740>.

  [I-D.  keoh-dice-multicast-security]
             Keoh, S., Kumar, S., Garcia-Morchon, O., Dijk, E., and A.
             Rahman, "DTLS-based Multicast Security in Constrained
             Environments", expired, draft-keoh-dice-
             multicast-security-08, July 2014,
             https://datatracker.ietf.org/doc/draft-keoh-dice-
             multicast-security/
             https://www.ietf.org/archive/id/draft-keoh-dice-
             multicast-security-08.txt

  [I-D.  keoh-tls-multicast-security]
             Keoh, S., Kumar, S., Garcia-Morchon, O., Dijk, E.,
             "DTLS-based Multicast Security for Low-Power and
             Lossy Networks (LLNs), expired, draft-keoh-tls-multicast-
             security-00, October 2012,
             https://tools.ietf.org/html/draft-keoh-tls-multicast-00,
             https://www.ietf.org/proceedings/85/slides/slides-85-tls-
            .pdf

Author's Address
Lucas                   Expires March 17, 2018                [Page 27]


Internet-Draft               DTLS Multicast              September 2017

  Roger Lucas
  c/o Cisco International Limited
  10, New Square Park
  Bedfont Lakes
  Feltham
  TW14 8HA
  United Kingdom

  Email: iot@hiddenengine.co.uk













































Lucas                   Expires March 17, 2018                [Page 28]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/