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

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

Hello Malisa:

I went through the security section of minimal-security and found that the text below would be useful there to. Alt a pointer to the security section of the architecture would do once I incorporate some of the below.
(Though I thought it did at a time) minimal-security does not indicate that the JRC should be aware of the network ASN to enable the protection that Tero is discussing below, does it?

All the best,

Pascal

> -----Original Message-----
> From: David Mandelberg <[email-masked]>
> 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
> 
> 
> 
> On 6/24/19 7:45 PM, Tero Kivinen wrote:
> > Pascal Thubert (pthubert) writes:
> >> 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.
> >
> > 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.
> 
> Is this discussion of nonce reuse in any relevant documents already, 
> or is it something that should be added somewhere?
> 
> > 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.
> >
> >
> >> 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.
> >
> > 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.
> >

---

From: Mališa Vučinić <[email-masked]>
Date: Tue, 25 Jun 2019 10:21:51 +0200

Pascal, Tero,

The issue raised seems valid and going through minimal-security and the MSF draft it seems that some clarification is needed. We purposely avoided keeping the network notion of time at the JRC in order to facilitate deployments where JRC is outside of the local network and is managing multiple 6tisch networks. I do not believe we want to change that, as it would be quite challenging to require the synchronization of the JRC with each 6tisch network. 

Instead, as with traditional TSCH, the joined node can obtain its time information from its time source neighbor, i.e. RPL preferred parent, by triggering an exchange of link-layer frames with L2 security features enabled. The MSF draft already mandates that the first outgoing message from the joined node after joining is the 6P ADD message to its preferred parent, which consequently gets protected with L2 security. What needs to be specified clearly is that this first 6P exchange should not be encrypted but only authenticated at L2. Upon successful completion of the first 6P exchange with its time (routing) parent, the joined node obtains a negotiated cell and as a side effect proves freshness of the ASN used. 

What seems missing is some text in minimal-security adding guidance for other scheduling function and stressing this issue beyond the text in the last paragraph of Section 9 of draft-ietf-6tisch-minimal-security-11 that is rather vague.

Mališa

> On 25 Jun 2019, at 09:29, Pascal Thubert (pthubert) <[email-masked]> wrote:
> 
> Hello Malisa:
> 
> -- 
> MailScanner believes this is threat-free - www.ucg.ac.me
>

---

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

Hello Malisa
 
> The issue raised seems valid and going through minimal-security and the MSF
> draft it seems that some clarification is needed. We purposely avoided keeping
> the network notion of time at the JRC in order to facilitate deployments where
> JRC is outside of the local network and is managing multiple 6tisch networks. I
> do not believe we want to change that, as it would be quite challenging to
> require the synchronization of the JRC with each 6tisch network.

Yes, I remember that discussion. Bottom line is that the proposal that Tero mentioned is not used.
Note that since we use RPL, the absolute source of Truth is the Root. But the root is several hops away and we cannot get the ASN directly so whatever we transfer to the node will be offset by the propagation time.

> 
> Instead, as with traditional TSCH, the joined node can obtain its time
> information from its time source neighbor, i.e. RPL preferred parent, by
> triggering an exchange of link-layer frames with L2 security features enabled.

Yes, but as Tero mentioned even an authenticated beacon can be replayed, making the node believe it is somewhere in the past. 

> The MSF draft already mandates that the first outgoing message from the
> joined node after joining is the 6P ADD message to its preferred parent, which
> consequently gets protected with L2 security. What needs to be specified
> clearly is that this first 6P exchange should not be encrypted but only

Is MSF the best place for this? 

I believe that the architecture should say something vague like " a first exchange is needed with a node that is trusted and already joined, e.g., a RPL time parent, and that message should not be encrypted but only authenticated at L2. The request from the pledge should contain a nonce and the response should contain the signed nonce+ASN+stuff. " On that base, MSF and minimal-security could elaborate on which message exactly is used.

> authenticated at L2. Upon successful completion of the first 6P exchange with
> its time (routing) parent, the joined node obtains a negotiated cell and as a
> side effect proves freshness of the ASN used.

Am I missing something? Looks like an ASN would appear to work if it is correct modulo the number of channels, something like 16... Which the attacker can derive by observing the period of transmissions by a node, doing, e.g., 6tisch minimal support.

> What seems missing is some text in minimal-security adding guidance for
> other scheduling function and stressing this issue beyond the text in the last
> paragraph of Section 9 of draft-ietf-6tisch-minimal-security-11 that is rather
> vague.

Yes : ) I'm working on high level text in archie, and will propose it to you and Tero. I'll be happy that you refer to it and refine it in minimal-security.

All the best

Pascal

> > I went through the security section of minimal-security and found that the
> text below would be useful there to. Alt a pointer to the security section of the
> architecture would do once I incorporate some of the below.
> > (Though I thought it did at a time) minimal-security does not indicate that
> the JRC should be aware of the network ASN to enable the protection that
> Tero is discussing below, does it?
> >
> > All the best,
> >
> > Pascal
> >
> >
> >

---

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

Mališa Vučinić <[email-masked]> wrote:
    > information from its time source neighbor, i.e. RPL preferred parent,
    > by triggering an exchange of link-layer frames with L2 security
    > features enabled. The MSF draft already mandates that the first
    > outgoing message from the joined node after joining is the 6P ADD
    > message to its preferred parent, which consequently gets protected with
    > L2 security.

But, how can the L2-security work if the newly-joined node has an ancient
ASN?  Won't the parent just drop the packet as being a replay, and then what?

    > What needs to be specified clearly is that this first 6P
    > exchange should not be encrypted but only authenticated at L2.
    > Upon successful completion of the first 6P exchange with its time (routing)
    > parent, the joined node obtains a negotiated cell and as a side effect
    > proves freshness of the ASN used.

I'd rather that we added a new exchange, rather than special casing some 6P
interaction here.   An RPL DIS would be a better choice here, I think, with
an RPL DAO unicast reply.  Still, I hate to special case this as being
authenticated only.
Doesn't that have to happen first?

Is the DIS unicast or multicast. Hmm.
How do we put something unique in it that has to be replied to proving the
freshness of the ASN against a reply attack.

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

---

From: Mališa Vučinić <[email-masked]>
Date: Wed, 26 Jun 2019 12:03:17 +0200

> On 25 Jun 2019, at 17:36, Michael Richardson <[email-masked]> wrote:
> 
> 

Yes, so the node will desynchronize eventually, fall out of network and restart the join process, hopefully with a different network. 

> Doesn't that have to happen first?

Whatever packet we send here, be it DIS or 6P, they need to have special handling in terms of L2 security… Is DIS mandatory to send upon preferred parent selection?

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 26 Jun 2019 11:50:51 +0000

Hello Malisa

> >> Instead, as with traditional TSCH, the joined node can obtain its
> >> time information from its time source neighbor, i.e. RPL preferred
> >> parent, by triggering an exchange of link-layer frames with L2
> >> security features enabled. The MSF draft already mandates that the
> >> first outgoing message from the joined node after joining is the 6P
> >> ADD message to its preferred parent, which consequently gets
> >> protected with
> >> L2 security.
> >
> > But, how can the L2-security work if the newly-joined node has an
> > ancient ASN?  Won't the parent just drop the packet as being a replay, and
> then what?
> 
> Yes, so the node will desynchronize eventually, fall out of network and restart
> the join process, hopefully with a different network.

My own Q&A

How is the bad ASN identified? -> I guess it can be picked from the frame counter in the Auxillary Security Header.
But then does the spec require that the receiver checks the frame counter that the sender used ? Is that implemented?
What is the reaction of the receiver in case of a bad ASN?  -> It could send a beacon with a correct ASN I guess.
But then how can we determine who of the 2 has the correct ASN? -> I guess a node should not have the right to act as coordinator until it confirmed his sense of ASN.

Otherwise, a bad ASN with the good modulo gets the frame in the right channel offset...

> 
> >> What needs to be specified clearly is that this first 6P exchange
> >> should not be encrypted but only authenticated at L2.
> >> Upon successful completion of the first 6P exchange with its time
> >> (routing) parent, the joined node obtains a negotiated cell and as a
> Whatever packet we send here, be it DIS or 6P, they need to have special
> handling in terms of L2 security… Is DIS mandatory to send upon preferred
> parent selection?

It is not mandatory but we could use it. A more generic method would be for the pledge to solicit a beacon with a nonce that does not depend on ASN and see check the MIC/MAC of the beacon.
 
All the best,

Pascal

---

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

> Yes, so the node will desynchronize eventually, fall out of network and
    > restart the join process, hopefully with a different network.

hmm.   Or, it sees a new beacon, which it can integrity check, and then sees
the ASN jump forward.  This would be the same as if it had slept for awhile.

Unless the attacker can continuously *block* the node from seeing the latest
beacons, and continuously feeds it old beacons, the problem should go away.

So maybe this is really not as a big a deal as I thought.

    > Whatever packet we send here, be it DIS or 6P, they need to have
    > special handling in terms of L2 security… Is DIS mandatory to send upon
    > preferred parent selection?

I think that we can do nothing.

Maybe the replayed beacon attack (and solution: wait for another beacon)
belongs in the Security Considerations of the Architecture.

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 27 Jun 2019 09:53:28 +0000

Hello Michael

Both ASN and sync create event horizons.
* A wrong ASN will cause MIC processing to fail and the packet will be ignored.
* If an attacker syncs a pledge outside of the network sync's beyond guard time, the pledge will not even see that legitimate nodes are sending.

In both cases, a node that believes an attacker has no way to validate ASN right there. It needs an additional one-hop authenticated exchange with a legitimate node with a, e.g., random nonce in payload. Some people will want that step even if the window is narrow. I think we should describe it in archie and in minimal sec.

6P or MSF could be used for that purpose when present but cannot be the only way since they are optional.

All the best,

Pascal

> From: 6tisch <[email-masked]> On Behalf Of Michael Richardson
> Sent: mercredi 26 juin 2019 17:49
> To: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= <[email-masked]>
> Cc: Pascal Thubert (pthubert) <[email-masked]>; [email-masked]; Tero
> Kivinen <[email-masked]>
> Subject: Re: [6tisch] [secdir] secdir review of draft-ietf-6tisch-architecture-21
> 
> 
> ancient
> (routing)
> Michael Richardson <[email-masked]>, Sandelman Software Works  -
> = IPv6 IoT consulting =-
> 
>

---

From: Mališa Vučinić <[email-masked]>
Date: Thu, 27 Jun 2019 12:47:44 +0200

Pascal,

Before the pledge selects a JP, the text from RFC8180 that is relevant seems to be (Section 6.2):

When a node joins a network, it may hear EBs sent by different nodes
   already in the network.  The decision of which neighbor to
   synchronize to (e.g., which neighbor becomes the node's initial time-
   source neighbor) is implementation specific.  For example, after
   having received the first EB, a node MAY listen for at most
   MAX_EB_DELAY seconds until it has received EBs from
   NUM_NEIGHBOURS_TO_WAIT distinct neighbors.  Recommended values for
   MAX_EB_DELAY and NUM_NEIGHBOURS_TO_WAIT are defined in Figure 5.
   When receiving EBs from distinct neighbors, the node MAY use the Join
   Metric field in each EB to select the initial time-source neighbor,
   as described in Section 6.3.6 <https://tools.ietf.org/html/rfc8180#section-6.3.6> of IEEE Std 802.15.4 [IEEE.802.15.4 <https://tools.ietf.org/html/rfc8180#ref-IEEE.802.15.4>].

To me, this text is ambiguous on whether the pledge should duty cycle its radio according to the schedule found in the first received EB. In case the pledge does not duty cycle its radio upon receiving the first EB that happens to be a replay, the attacker cannot really desync the pledge due to its radio being on 100% of the time waiting for additional beacons. Eventually, as Michael noted, one fresh EB will arrive from a legitimate node with a higher ASN, at which point it becomes critical for the pledge to select the JP with the largest available ASN for a given advertised PAN ID. I believe this text deserves expanded discussion in the Security Considerations of minimal-security but I am not convinced on the need for a special mechanism to exchange/sign the ASN.

Mališa

> On 27 Jun 2019, at 11:53, Pascal Thubert (pthubert) <[email-masked]> wrote:
> 
> Hello Michael
> 
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 27 Jun 2019 12:06:35 +0000

Hello Malisa

Please find below the proposed text; note that last paragraph is commented out to leave space for minimal to complete the story.

    <t>
    The operation of 6TiSCH Tracks inherits its high level operation from DetNet
    and is subject to the observations in section 5 of
    <xref target="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. Also, the installation and the
    maintenance of the 6TiSCH Tracks depends on 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) in Section 9 of <xref target="RFC8453"/>, applies
    equally to 6TiSCH.
    </t>
     <t>
    In a TSCH network as specified by
    <xref target="IEEE802154">IEEE Std. 802.15.4</xref>, the nonce that is used
    to secure Link-Layer frames includes an address of the source and the ASN.
    The ASN itself is supposed to be distributed securely by other means. With
    TSCH, the ASN is included in the CCM* nonce for the computation of the
    Message Integrity Code (MIC), but it is only implicit in the data frames.
    This is not considered as a complete replay protection and upper layer
    protocols must provide a way to detect duplicates and cope with them.

    </t>
     <t>
    If the receiver and the sender have a different sense of ASN, the MIC will
    not validate and the frame will be dropped. In that sense, TSCH induces an
    event horizon whereby only nodes that have a common sense of ASN can talk to
    one another in an authenticated manner. With 6TiSCH, the pledge discovers a
    tentative ASN in beacons from nodes that have already joined the network.
    But even if the beacon can be authenticated, the ASN cannot be trusted as it
    could be a replay by an attacker and thus could announce an ASN that
    represents a time in the  past. If the pledge uses an ASN that is learned
    from a replayed beacon for an encrypted transmission, a nonce-reuse attack
    becomes possible and the network keys may be compromised.
    </t>
    <t>
    Time Synchronization in TSCH induces another event horizon whereby a node
    will only communicate with another node if they are synchronized within a
    guard time. The pledge discovers the synchronization of the network based
    on the time of reception of the beacon. If an attacker synchronizes a pledge
    outside of the guard time of the legitimate nodes then the pledge will never
    see a legitimate beacon and may not discover the attack.
    </t>
    <t>
    After obtaining the 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 keys and a short address, and
    if the ASN is known to be correct, all traffic can now be secured using CCM*
    at the Link-Layer.
    </t>
    <t>
    The authentication steps must be such that they cannot be replayed by an
    attacker, and they must not depend on the tentative ASN being valid.
    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 may still need 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 lost its state with a previous ASN. But
    if the nonce derives from the short address (e.g., assigned by the JRC) then
    the JRC must ensure that it never 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.
    </t>
    <t>
    These issues is are discussed in more details in
    <xref target="I-D.ietf-6tisch-minimal-security"/>.
    </t>
    <!--t>
    Once the node obtains the keys from the JRC, an additional step may be
    required to ensure that the ASN is correct before encrypting any message.
    If the ASN is not guaranteed to be correct by other means, the pledge should
    perform a non-replayable exchange (e.g., using a nonce in the payload that
    does not derive from ASN) with a peer node that is trusted and has already
    joined (e.g., the JP or a RPL time parent). The request by the pledge should
    not be encrypted at the Link-Layer but only authenticated to avoid
    nonce-replay attacks. A successful authenticated exchange proves a common
    sense of ASN and encrypted traffic can now happen.
    </t-->

All the best,

Pascal

From: Mališa Vučinić <[email-masked]>
Sent: jeudi 27 juin 2019 12:48
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: Michael Richardson <[email-masked]>; [email-masked]; Tero Kivinen <[email-masked]>
Subject: Re: [6tisch] [secdir] secdir review of draft-ietf-6tisch-architecture-21

Pascal,

   as described in Section 6.3.6<https://tools.ietf.org/html/rfc8180#section-6.3.6> of IEEE Std 802.15.4 [IEEE.802.15.4<https://tools.ietf.org/html/rfc8180#ref-IEEE.802.15.4>].

Mališa

On 27 Jun 2019, at 11:53, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:

Hello Michael

All the best,

Pascal

-----Original Message-----
From: 6tisch <[email-masked]<mailto:[email-masked]>> On Behalf Of Michael Richardson
Sent: mercredi 26 juin 2019 17:49
To: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= <[email-masked]<mailto:[email-masked]>>
Cc: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Tero
Kivinen <[email-masked]<mailto:[email-masked]>>
Subject: Re: [6tisch] [secdir] secdir review of draft-ietf-6tisch-architecture-21

Mališa Vučinić <[email-masked]<mailto:[email-masked]>> wrote:

Mališa Vučinić <[email-masked]<mailto:[email-masked]>> wrote:

message to its preferred parent, which consequently gets protected
with

L2 security.

ASN?  Won't the parent just drop the packet as being a replay, and then
what?

I'd rather that we added a new exchange, rather than special casing some
6P

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

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

_______________________________________________
6tisch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tisch

---

From: Mališa Vučinić <[email-masked]>
Date: Thu, 27 Jun 2019 16:57:55 +0200

Hello Pascal,

Thanks, this text is fine by me.

Mališa

> On 27 Jun 2019, at 14:06, Pascal Thubert (pthubert) <[email-masked]> wrote:
> 
> Hello Malisa
>  
> On 27 Jun 2019, at 11:53, Pascal Thubert (pthubert) <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hello Michael
> 
> From: 6tisch <[email-masked] <mailto:[email-masked]>> On Behalf Of Michael Richardson
> To: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= <[email-masked] <mailto:[email-masked]>>
> Cc: Pascal Thubert (pthubert) <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; Tero
> Kivinen <[email-masked] <mailto:[email-masked]>>
> Mališa Vučinić <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Mališa Vučinić <[email-masked] <mailto:[email-masked]>> wrote:
> 
> ]     [email-masked] <mailto:[email-masked]>  http://www.sandelman.ca/ <http://www.sandelman.ca/>        |   ruby on rails    [
> 
> 
> --
> Michael Richardson <[email-masked] <mailto:[email-masked]>>, Sandelman Software Works  -
> = IPv6 IoT consulting =-
> 
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/6tisch <https://www.ietf.org/mailman/listinfo/6tisch>
>