Subject: [secdir] secdir review of draft-ietf-6tisch-architecture-21

From: David Mandelberg <[email-masked]>
Date: Sun, 23 Jun 2019 21:22:05 -0400

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

The summary of the review is Ready with nits.

The review deadline for this was really short, so I didn't have a chance 
to read this as closely as I would have liked. That said, from skimming 
the document and reading the sections that looked most interesting, it 
looks pretty good. The security considerations section covers what I 
expected it to. I have only one question/concern:

Sections 4.2.1 and 4.3.4 talk about the security of joining a network, 
and time synchronization, respectively. Do any of the security 
mechanisms in 4.2.1 rely on having an accurate clock? (E.g., to distrust 
old/expired keys.) Is time synchronization done before the join process, 
and is there any way to exploit time synchronization in order to cause a 
node to join a malicious network?

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 24 Jun 2019 08:20:12 +0000

Hello David:

Many thanks for your review. I do hope that you found it interesting.

> Sections 4.2.1 and 4.3.4 talk about the security of joining a network, and time
> synchronization, respectively. Do any of the security mechanisms in 4.2.1 rely
> on having an accurate clock? (E.g., to distrust old/expired keys.) Is time
> synchronization done before the join process, and is there any way to exploit
> time synchronization in order to cause a node to join a malicious network?

This is really a MAC layer question for IEEE. I'm cc'ing Thomas who was one of the inventors of TSCH, as well as Michael and Malisa who led the join process study.

Time synchronization (date):
--------------------------------------
For all I know, the time sync is about giving a epoch time from which an Absolute Slot Number (ASN, expressed in slot duration e.g., 10ms) is derived.
ASN plays a key role as it is used in NONCE. An attack that one could think of would be to fool the new node into thinking that ASN is earlier. This could happen before the keys are exchanged, or if an authorized peer is compromised.
For the former, I'll defer to the others to answer fully how we protect the new comer. 
For the latter, 6TiSCH provides an additional protection since we derive time from a RPL parent. RPL has its own protections, some of them in the standard itself, some of them in zerotrust papers that need publishing. 

Time synthonization (precise tic, hourless)
--------------------------------------------------------
This is the process whereby a node corrects its tic to realign with the parent. ASN is not changed but the drift of crystals is compensated.
An attacker could try to inject a sense of time that it slightly shifted to the point that the node lose sync with the rest of the network (the guard time is like an event horizon). Then again, RPL provides an additional protection on top of the MAC provisions.

In the meantime your remark reserves some text. Note that the dependency on time is inherited from DetNet and TSN, and DetNet has text about it that we can reference.

In conjunction with Andrew's review I'd propose:
"
    The operation of 6TiSCH Tracks inherits its high level operation from DetNet
    and is subject to the observations in section 5 of [ietf-detnet-architecture].
    As discussed there, measures  must be taken to protect the time 
    synchronization, and for 6TiSCH this includes ensuring that the ASN, which is
    used for the computation of NONCE, is not compromised. Also, the installation
    and maintenance of 6TiSCH Tracks depends in the availability of a controller
    with a PCE to compute and push them in the network. When that connectivity
    is lost, existing Tracks may continue to operate until the end of their
    lifetime, but cannot be removed or updated, and new Tracks cannot be
    installed. As with DetNet in general, the communication with the PCE must be
    secured and should be protected against DoS attacks, and the discussion on
    the security considerations defined for Abstraction and Control of Traffic
    Engineered Networks (ACTN) applies equally to 6TiSCH.
"

Does that sound good?

Pascal

> -----Original Message-----
> From: David Mandelberg <[email-masked]>
> Sent: lundi 24 juin 2019 03:22
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: secdir review of draft-ietf-6tisch-architecture-21
> 
> I have reviewed this document as part of the security directorate's ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments were written primarily for the benefit of the security area directors.
> Document editors and WG chairs should treat these comments just like any
> other last call comments.
> 
> The review deadline for this was really short, so I didn't have a chance to read
> this as closely as I would have liked. That said, from skimming the document
> and reading the sections that looked most interesting, it looks pretty good. The
> security considerations section covers what I expected it to. I have only one
> question/concern:
> 
> Sections 4.2.1 and 4.3.4 talk about the security of joining a network, and time
> synchronization, respectively. Do any of the security mechanisms in 4.2.1 rely
> on having an accurate clock? (E.g., to distrust old/expired keys.) Is time
> synchronization done before the join process, and is there any way to exploit
> time synchronization in order to cause a node to join a malicious network?

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 25 Jun 2019 02:45:15 +0300

Pascal Thubert (pthubert) writes:
> > Sections 4.2.1 and 4.3.4 talk about the security of joining a
> > network, and time synchronization, respectively. Do any of the
> > security mechanisms in 4.2.1 rely on having an accurate clock?
> > (E.g., to distrust old/expired keys.) Is time synchronization done
> > before the join process, and is there any way to exploit time
> > synchronization in order to cause a node to join a malicious
> > network?
> 
> This is really a MAC layer question for IEEE. I'm cc'ing Thomas who
> was one of the inventors of TSCH, as well as Michael and Malisa who
> led the join process study.
> 
> For all I know, the time sync is about giving a epoch time from
> which an Absolute Slot Number (ASN, expressed in slot duration e.g.,
> 10ms) is derived. ASN plays a key role as it is used in NONCE. An
> attack that one could think of would be to fool the new node into
> thinking that ASN is earlier. This could happen before the keys are
> exchanged, or if an authorized peer is compromised. For the former,
> I'll defer to the others to answer fully how we protect the new
> comer. For the latter, 6TiSCH provides an additional protection
> since we derive time from a RPL parent. RPL has its own protections,
> some of them in the standard itself, some of them in zerotrust
> papers that need publishing.

In normal TSCH in 802.15.4 the joining node will listen to beacons
sent by the nodes already part of the network, and they will find out
the ASN from there. As they do not yet have keys for the network they
cannot verify the message integrity code authenticating the beacon,
and even if they did have the keys, they still cannot verify it as it
could be replay by attacker.

After they find out the ASN, they need to authenticate themself to the
network using some mechanism outside the 802.15.4. This authentication
step must be such that it cannot be replayed by attacker, i.e., they
must not trust ASN giving them any protection.

Note, that in general 802.15.4 TSCH DOES NOT provide replay protection
at all. I.e., attacker can cause legimite node to retransmit its
previous message by destroying ack, and upper layer protocol must
provide way to detect replays and cope with them.

During the authentication the JRC needs to provide the keying material
to the joining node, but that does NOT provide protection against
spoofed ASN. After the node has actual keys used in the network it
still needs to verify the ASN by sending some message to JRC using
authentication and verify that JRC replies to that.

If this 2nd step is omitted attacker do following attack:

Joining node (JN)   attacker	     		  JRC
		    <- beacon for ASN=23	  <- beacon for ASN=44
See beacon
from attacker,
assume ASN=23.

Auth->JRC
(no security)					  Check authentication
						  Return keys
						  keys->JN

Receive keys
send first
frame using
keys using ASN=23->

Now, if JN is using extended address to generate nonce, the nonce will
be different for all other nonces ever used, even the ASN is faked,
and has been used before. On the other hand if JN also receives short
address assignment from the JRC, JRC needs to make sure that short
address has not been assigned to anybody else before, as if it was
used by someone else, and frame sent by JN is encrypted, then attacker
will now have two packets with same ASN, and short address, meaning
same nonce, and it can now decrypt packets. 

Note, that attacker might be able to replay valid ACKs for the frame
sent by the JN, provided that the JRC (or whoever JN sent the message
to) happened to ack message using the same ASN attacker faked for JN.

If JN sends message to JRC which only JRC can reply, and uses wrong
ASN, the JRC will not be able to decrypt/validate that frame because
of wrong ASN in nonce, and will drop it silently, so if JN uses wrong
ASN it might be getting ACKs, but it will not get any real reply
frames back from real participants in the network. After it will not
receive confirmation from JRC that it has proper keys and ASN, it
knows something went wrong.

> This is the process whereby a node corrects its tic to realign with
> the parent. ASN is not changed but the drift of crystals is
> compensated. An attacker could try to inject a sense of time that it
> slightly shifted to the point that the node lose sync with the rest
> of the network (the guard time is like an event horizon). Then
> again, RPL provides an additional protection on top of the MAC
> provisions.

Those time syncronization IEs are also protected by MAC level
authentication, so attackers who do not know the keys cannot generate
them. Attackers who do know keys can do whatever they like anyways... 

Btw, I will be leaving for vacation tomorrow, so I might not be able
to reply any messages related to this until I get back end of next
week. 
-- 
[email-masked]

---

From: David Mandelberg <[email-masked]>
Date: Mon, 24 Jun 2019 20:30:40 -0400

> same nonce, and it can now decrypt packets.

Is this discussion of nonce reuse in any relevant documents already, or 
is it something that should be added somewhere?

---

From: David Mandelberg <[email-masked]>
Date: Mon, 24 Jun 2019 20:31:17 -0400

> Time synchronization (date):

Yup, sounds good to me.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 25 Jun 2019 07:04:38 +0000

This is great and concise information; I'd be happy to add it in the security section even if it is available elsewhere...

All the best,

Pascal

> Sent: mardi 25 juin 2019 02:31
> To: Tero Kivinen <[email-masked]>; Pascal Thubert (pthubert)
> <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked];
> Thomas Watteyne <[email-masked]>; Michael Richardson
> <[email-masked]>; Mališa Vučinić <[email-masked]>
> Subject: Re: [secdir] secdir review of draft-ietf-6tisch-architecture-21
> 
> 
> 
> >> For all I know, the time sync is about giving a epoch time from which
> >> an Absolute Slot Number (ASN, expressed in slot duration e.g.,
> >> comer. For the latter, 6TiSCH provides an additional protection since
> >> we derive time from a RPL parent. RPL has its own protections, some
> >> of them in the standard itself, some of them in zerotrust papers that
> >> need publishing.
> >
> Is this discussion of nonce reuse in any relevant documents already, or is it
> something that should be added somewhere?
> 
> >> of the network (the guard time is like an event horizon). Then again,
> >> RPL provides an additional protection on top of the MAC provisions.
> >

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 25 Jun 2019 14:04:33 +0300

> is it something that should be added somewhere?

All 802.15.4 documents assume that ASN is already distributed securely
to the nodes having keys. I.e., this attack is not considered by those
documents, as it is outside the scope of them...
-- 
[email-masked]

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 25 Jun 2019 12:45:55 +0000

Hello Tero:

Some clarification questions below:

> Now, if JN is using extended address to generate nonce, the nonce will be
> different for all other nonces ever used, even the ASN is faked, and has been

This is assuming that the attacker is not attacking the same device twice, isn't it?

> used before. On the other hand if JN also receives short address assignment
> from the JRC, JRC needs to make sure that short address has not been
> assigned to anybody else before, as if it was used by someone else, and frame
> sent by JN is encrypted, then attacker will now have two packets with same
> ASN, and short address, meaning same nonce, and it can now decrypt packets.

That's unless new keys are given if the short address is reattributed, correct?

> Note, that attacker might be able to replay valid ACKs for the frame sent by
> the JN, provided that the JRC (or whoever JN sent the message

Your mean that the faked ASN is only slightly in the future, so the attacker can repeat messages from the pledge after that delay?

> If JN sends message to JRC which only JRC can reply, and uses wrong ASN, the
> JRC will not be able to decrypt/validate that frame because of wrong ASN in
> nonce, and will drop it silently, so if JN uses wrong ASN it might be getting
> ACKs, but it will not get any real reply frames back from real participants in the
> network. After it will not receive confirmation from JRC that it has proper keys
> and ASN, it knows something went wrong.

I'm not sure about the status of sync'ing the JRC with the network. Minimal-security does not discuss it. Talking to Malisa to improve that piece proactively to the sec-dir review.

I'll propose text based on your reply and Malisa's separately.

Many thanks for your clarifications!

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 25 Jun 2019 13:36:34 +0000

Ok so we went through a lot based on this ASN discussion.
I produced the following.
Michael, Malisa and Tero please confirm that it looks good / help me fix it : )

"
  The operation of 6TiSCH Tracks inherits its high level operation from
   DetNet and is subject to the observations in section 5 of
   [I-D.ietf-detnet-architecture].  As discussed there, measures must be
   taken to protect the time synchronization, and for 6TiSCH this
   includes ensuring that the Absolute Slot Number (ASN), which is used
   as ever incrementing counter for the computation of the Link-Layer
   security nonce, is not compromised, more below on this.  

<snip>

   In a TSCH network as specified by IEEE Std. 802.15.4 [IEEE802154],
   the nonce that is used to secure Link-Layer exchanges includes an
   address of the source and the ASN.  The ASN itself is supposed to be
   distributed securely by other means.  If the ASN is compromised and a
   short address is reused, then a nonce-reuse attack becomes possible.

   With 6TiSCH, the pledge discovers a tentative ASN in beacons sent by
   nodes that have already joined the network.  As the pledge is not in
   possession of Link-Layer keys for the visited network, it cannot
   verify the message integrity code (MIC) authenticating the beacon.
   Even if it did have the keys, it still could not verify the beacon as
   it could be a replay by an attacker and thus could still announce an
   ASN that represents a time in the past.  That time would match a
   valid timeslot it if is correct modulo the number of channels used for
   hopping.

   After obtaining that tentative ASN, the pledge authenticates itself
   to the network using some mechanism outside of IEEE Std 802.15.4.
   With 6TiSCH, a Join Proxy (JP) helps the pledge for the join
   procedure by relaying the link-scope Join Request over the IP network
   to a Join Registrar/Coordinator (JRC) that can authenticate the
   pledge and validate that it is attached to the appropriate network.
   As a result of this exchange the pledge is in possession of a Link-
   Layer material including a key and a short address, and assuming that
   the ASN is correct, all traffic can be secured at the Link-Layer.

   This authentication steps must be such that they cannot be replayed
   by an attacker, and it must not depend on th tentative ASN being
   valid.  Note that IEEE std. 802.15.4 TSCH does not provide replay
   protection at all, and that for instance attacker can cause a
   legitimate node to retransmit a previous message by destroying an
   ack. It results and upper layer protocol must provide a way to detect
   replayed messages and cope with them.

   During the authentication the keying material that the pledge obtains
   from the JRC does NOT provide protection against spoofed ASN.  Once
   the pledge has obtained the keys to use in the network, it still
   needs to verify the ASN.  If the nonce used in the Layer-2 security
   derives from the extended (MAC-64) address, then replaying the ASN
   alone cannot enable a nonce-reuse attack unless the same node is
   attacked twice and loses all state in-between.  But if the nonce
   derives from the short address (e.g., assigned by the JRC) then the
   nonce-reuse attacks are possible, and the JRC must ensure that it
   never assigns short addresses that were already given to this or
   other nodes with the same keys.

   At that point, an additional step may be required to ensure that the
   ASN is correct.  For instance, the pledge could perform a first
   exchange with a peer node that is trusted and has already joined,
   e.g., its RPL time parent, and the message should not be encrypted
   but only authenticated at the Link-Layer.  The request from the
   pledge should contain a nonce with a random part that is not ASN, and
   the authenticated response should contain the current ASN and echo
   the nonce.

"

All the best,

Pascal

> and reading the sections that looked most interesting, it looks pretty good.
> The security considerations section covers what I expected it to. I have only
> one question/concern:
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 25 Jun 2019 11:31:11 -0400

> authentication and verify that JRC replies to that.

I thought that the 6LRs could provide authentication of the beacons with the
network-wide-key, and that we could (after the join process), verify the beacon we
saw, using the key(s) that the JRC provided.

>		    <- beacon for ASN=23	  <- beacon for ASN=44

So this is a replay of the valid beacon with ASN=23.

    > be different for all other nonces ever used, even the ASN is faked, and
    > has been used before. On the other hand if JN also receives short
    > address has not been assigned to anybody else before, as if it was used
    > by someone else, and frame sent by JN is encrypted, then attacker will
    > now have two packets with same ASN, and short address, meaning same
    > nonce, and it can now decrypt packets.

I thought that we have text in 6tisch-minimal about needing to rekey the
network if we run out of short-addresses for this reason.  Well, no.
We explain how to rekey well, but not why to rekey :-)

Are you suggesting that we need to put this in the architecture document too?
Maybe we should have included the ASN as an attribute in the JRC response.

    > ASN, the JRC will not be able to decrypt/validate that frame because of
    > wrong ASN in nonce, and will drop it silently, so if JN uses wrong ASN
    > it might be getting ACKs, but it will not get any real reply frames
    > back from real participants in the network. After it will not receive
    > confirmation from JRC that it has proper keys and ASN, it knows
    > something went wrong.

Still, that's more code to implement a heuristic.

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

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

---

From: Michael Richardson <[email-masked]>
Date: Tue, 25 Jun 2019 11:39:24 -0400

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > Your mean that the faked ASN is only slightly in the future, so the
    > attacker can repeat messages from the pledge after that delay?

The faked ASN is always in the past.
So the L2-ACKs can be faked, was the point.

The best scenario would be to distribute the ASN within the JRC reply (CoJP),
but (as Malisa has pointed out) that also has the problem that it requires
the JRC to get ASN coordination/update messages from the 6LBR if they are not co-located.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 25 Jun 2019 11:45:09 -0400

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > the following.  Michael, Malisa and Tero please confirm that it looks
    > good / help me fix it : )

...

    > possession of Link-Layer keys for the visited network, it cannot verify
    > the message integrity code (MIC) authenticating the beacon.

- Even if it
- did have the keys, it still could not verify the beacon as it could be
- a replay by an attacker and thus could still announce an ASN that
- represents a time in the past.  That time would match a valid timeslot
- it if is correct modulo the number of channels used for hopping.

+ Even after the join process, when it does have the keys, it still could not
+ verify the freshness of the the beacon as it could be
+ a replay by an attacker and thus could still announce an ASN that
+ represents a time in the past.  That time would match a valid timeslot
+ it if is correct modulo the number of channels used for hopping.

    >    This authentication steps must be such that they cannot be replayed
    + by an attacker, and it must not depend on the tentative ASN being valid.
    > Note that IEEE std. 802.15.4 TSCH does not provide replay protection at
    > all, and that for instance attacker can cause a legitimate node to

    - retransmit a previous message by destroying an ack. It results and
    + retransmit a previous message by destroying an ack. If this results an

    > upper layer protocol must provide a way to detect replayed messages and
    > cope with them.

    >    During the authentication the keying material that the pledge
    > obtains from the JRC does NOT provide protection against spoofed ASN.
    > Once the pledge has obtained the keys to use in the network, it still
    > nonce-reuse attacks are possible, and the JRC must ensure that it never
    > assigns short addresses that were already given to this or other nodes
    > with the same keys.

I think that in this place, the note about rekeying the network must occur
before running out of short addresses.

    > exchange with a peer node that is trusted and has already joined, e.g.,
    > its RPL time parent, and the message should not be encrypted but only
    > authenticated at the Link-Layer.  The request from the pledge should
    > contain a nonce with a random part that is not ASN, and the
    > authenticated response should contain the current ASN and echo the
    > nonce.

I think that we need to be explicit, not "for instance"

{please forgive me being behind on email. Summer cold and family responsabilities}
--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 26 Jun 2019 12:22:21 +0000

Many thanks Michael

I'm unclear whether implementations actually have to check the ASN before responding and what actions they would take should that occur.
I guess we are in IEEE land at that point bit I understand that the IEEE did not specify a method to validate ASN. 

I incorporated your recommendations below, please see:
 
> + Even after the join process, when it does have the keys, it still
> + could not verify the freshness of the the beacon as it could be a
> + replay by an attacker and thus could still announce an ASN that

Done

>     > all, and that for instance attacker can cause a legitimate node to

Fixed

>     > upper layer protocol must provide a way to detect replayed messages and

Sorry I cannot parse the resulting sentence with your proposal.
My mistake was only and -> an but I'm sure that the sentence can be better written.
I changed to
"

    This authentication steps must be such that they cannot be replayed by an
    attacker, and it must not depend on the tentative ASN being valid. Note that
    IEEE std. 802.15.4 TSCH does not provide replay protection at all, and that 
    an ack may be lost, which can cause a legitimate node to retransmit a frame.
    Upper layer protocols must thus provide a way to detect duplicates and cope
    with them.

"

> before running out of short addresses.

Added
"
      assigns short addresses that were already given to this or other nodes with
+    the same keys. In other words, the network must be rekeyed before the JRC
+   runs out of short addresses.
"

> I think that we need to be explicit, not "for instance"

Proposed new text:
"
    At that point, an additional step may be required to ensure that the ASN is
    correct. If the ASN is not guaranteed to be correct by other means, the
    pledge should perform a first exchange with a peer node that is trusted and
    has already joined, e.g., its RPL time parent, and the message should not be
    encrypted but only authenticated at the Link-Layer.
    The request from the pledge should contain a nonce with a random part that
    is not ASN, and the authenticated response should contain the current ASN
    and echo the nonce.
"

> {please forgive me being behind on email. Summer cold and family

You're always helpful, Michael, how could one complain?

Many thanks

Pascal

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 26 Jun 2019 12:30:33 +0000

> The faked ASN is always in the past.

Do you mean the replayed ones? When the pledge does not have the keys, the attacker can forge the beacon with any ASN, and place random bytes in the MIC, can't it?
If the attacker fakes an ASN that is tomorrow and intercepts a join request, it could make the pledge seem to appear now on the network tomorrow even if the real pledge is long gone.

> So the L2-ACKs can be faked, was the point.

I can see that an ACK can be replayed. But the ACK that was stored in advance can only work if the attacked node speaks on the very ASN for which the attacker intercepted an ACK in the past. The attacker is not in control of that and that makes its life harder.

> but (as Malisa has pointed out) that also has the problem that it requires the
> JRC to get ASN coordination/update messages from the 6LBR if they are not
> co-located.
> 
> --

---

From: Michael Richardson <[email-masked]>
Date: Wed, 26 Jun 2019 11:51:46 -0400

Good, I like it fine.

    > is not ASN, and the authenticated response should contain the current ASN

okay. Tero?

---

From: Michael Richardson <[email-masked]>
Date: Wed, 26 Jun 2019 11:54:18 -0400

> Do you mean the replayed ones? When the pledge does not have the keys,
    > the attacker can forge the beacon with any ASN, and place random bytes
    > in the MIC, can't it?

Yes, the replayed one has a "fake" ASN that is in the past.

    > If the attacker fakes an ASN that is tomorrow and intercepts a join
    > request, it could make the pledge seem to appear now on the network
    > tomorrow even if the real pledge is long gone.

But that one won't validate.

    > I can see that an ACK can be replayed. But the ACK that was stored in
    > advance can only work if the attacked node speaks on the very ASN for
    > which the attacker intercepted an ACK in the past. The attacker is not
    > in control of that and that makes its life harder.

When I said faked, I should have said replayed.

I think that we don't need to do this: just wait for a beacon.  If the
attacker can block and replay them all, then they absolutely win, and the
network can not form.  Such an attacker probably can also put faraday cages
around all the nodes.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 28 Jun 2019 10:59:08 +0000

Hello David

Many thanks again. Your comments steered great discussions that led to improvements in both this draft and minimal security.
I posted -23 in the hope that it satisfies all your comments. Please let us know is there is any additional issue we need to look at.
 
All the best,
 
Pascal

> From: Michael Richardson <[email-masked]>
> Sent: mercredi 26 juin 2019 17:54
> To: Pascal Thubert (pthubert) <[email-masked]>
> Cc: Tero Kivinen <[email-masked]>; David Mandelberg
> <[email-masked]>; [email-masked]; [email-masked]; draft-ietf-6tisch-
> [email-masked]; Thomas Watteyne <[email-masked]>;
> =?iso-8859-2?Q?Mali=B9a_Vu=E8ini=E6?= <[email-masked]>
> I think that we don't need to do this: just wait for a beacon.  If the attacker can
> block and replay them all, then they absolutely win, and the network can not
> form.  Such an attacker probably can also put faraday cages around all the
> nodes.
> 
> --

---

From: David Mandelberg <[email-masked]>
Date: Sun, 30 Jun 2019 13:44:47 -0400

-23 looks good. Thank you all for doing the work to secure the protocols!