#36: Last call comments: MCR comments
Comment (by [email protected]): 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 =- -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-6tisch- [email protected] | [email protected] Type: defect | Status: new Priority: major | Milestone: Component: | Version: architecture | Resolution: Severity: In WG Last | Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: <http://trac.tools.ietf.org/wg/6tisch/trac/ticket/36#comment:4> 6tisch <http://tools.ietf.org/6tisch/> _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
