6tisch issue tracker <[email protected]> wrote: >> 3) I don't think that [I-D.ietf-roll-rpl-industrial-applicability] >> will
> ever get published. If there is terminology there that we still need,
> I think it should be extracted into the 6tisch-terminology
> document. While it is an informative reference, the fewer references to
> IDs the better in my opinion.
> But this one is really key on why we do RPL on TSCH at 6TiSCH. I'd
> rather keep it.
okay.
> I suggest we remove the term debate and say this as follows:
> " PANA (Layer-3), IEEE802.1x (Layer-2) or some light weight variation
> of those could be used in the join process. Regardless, the security
> model must ensure that, prior to a join process, packets from a
> untrusted device are controlled in volume and in reachability. This
> piece of the architecture is also deferred to a subsequent volume of
> the architecture. A status of the work can be found in Section 13. "
okay.
>> 7) I don't understand why PANA lives above ACE in figure 3. I think
>> that
> ACE lives above CoAP/DICE (DTLS is missing, but perhaps understood by
> DICE). I think that while technically PANA lives on top of UDP, there
> is of course a layer of EAP, and TLS above it, and perhaps a layer of
> ACE as well. So I'm not saying that this picture needs to be changed,
> just to observe this.
> I suggested one, but please come back to me. I think ultimately we
> need to move all to COMI, including PANA if we adopt it, but none of
> that is clear now.
It might be best to remove items from the picture rather than give wrong
impressions.
> to the full routing protocol. The architecture also expects that a
> 6LoWPAN node that is not aware at all of the RPL protocol may also
> connect as a host. This can be achieved with an extension to 6LoWPAN
> ND, adding the capability to carry a sequence number that is used to
> track the movements of the device, and optionally some abstract
> information about the RPL instance (topology) that this device will be
> reachable over. "
I'm uncomfortable with things that say, "we can do X by extending Y".
That's always true. ("We can extend 1950s telephone service to do web browsing
by extending circuit switched networks to do IPv6...")
Do we need/want to do X? Is extending Y in our charter already?
> When 6LoWPAN ND is coupled with RPL, the 6LBR and RPL root
> functionalities are co-located in order that the address of the 6LBR be
> indicated by RPL DIO messages and to associate the unique ID from the
> DAR/DAC exchange with the state that is maintained by RPL. The DAR/DAC
> exchange becomes a preamble to the DAO messages that are used from then
> on to reconfirm the registration, thus eliminating a duplication of
> functionality between DAO and DAR messages. "
good.
>> 13) I think that 6.6 is saying that SEND can not be applied. I think
>> it
> should be clearer in saying something like: "The threats against IPv6
> ND as described in RFC3971 apply as well, but the solution can not work
> as the route over network does not permit direct peer to peer
> communication. As can be seen in Figure 4..."
>>
> What about
> " A typical attack against IPv6 ND is address spoofing, whereby a
> rogue node claims the IPv6 Address of another node in and hijacks its
> traffic. The threats against IPv6 ND as described in SEcure Neighbor
> Discovery (SEND) [RFC3971] are applicable to 6LoPWAN ND as well, but
> the solution can not work as the route over network does not permit
> direct peer to peer communication.
good.
> Additionally SEND requires considerably enlarged ND messages to
> carry cryptographic material, and requires that each protected address
> is generated cryptographically, which implies the computation of a
> different key for each Cryptographically Generated Address (CGA). SEND
> as defined in [RFC3971] is thus largely unsuitable for application in a
> LLN.
> With 6LoWPAN ND, as illustrated in Figure 4, it is possible to
> leverage the registration state in the 6LBR, which may store additional
> security information for later proof of ownership. If this information
> proves the ownership independently of the address itself, then a single
> proof may be used to protect multiple addresses.
good.
>> 14) I think that the relevant parts of [I-D.ietf-roll-rpl-industrial-
> applicability] need to imported into this document, since this sure
> looks like a normative reference to me.
>>
> I agree that this spec is fundamental to us. But importing it?
If it's important, then it needs to be a normative reference. Otherwise, it
will be a downref that will break publication.
> " The architecture defines "soft" cells and "hard" cells. "Hard" cells
> are owned and managed by an separate scheduling entity (e.g. a PCE)
> that specifies the slotOffset/channelOffset of the cells to be
> added/moved/deleted, in which case 6top can only act as instructed, and
> may not move hard cells in the TSCH schedule on its own.
> "
>> "6top contains a monitoring process which monitors the performance of
> cells, and can move a cell in the TSCH schedule when it performs bad."
s/performs bad/performs poorly/
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
