Hello Benjamin: Again and again, many thanks, it's really a pleasure to work on your reviews. My plan is a single publication for all 3 emails. I'm merging the 2 mails on the same thread and removing all the items for which we reached an agreement, I hope that helps.
Let's see 😊 > I guess this means that a recipient of a "bitmap with as many bits set as > fragments have been sent but not all bits set" has to assume that > refragmentation has occurred and that the full datagram is not acknowledged > yet, which is fine. If the recipient is an intermediate node, it is not supposed to maintain a map of the datagram so it cannot know what constitutes a full coverage by fragments. The fact that all the fragments that it saw are acknowledged does not mean that it's the full datagram. The sender may operate with a window of one and only send the next fragment when the previous was acknowledged. If the recipient is the fragmenting node, it may infer that the datagram is received in full from the bitmap but we do not ask him to do so. Fine if he does and raises an alert when it thinks that the reassembling node should have sent a FULL bitmap, but that's extra code that we cannot mandate for a constrained device. > > > What's the transition/backwards-compatibility story? That is, how > > > does a sender know that all nodes on the path support the RFRAG > > > dispatch types, and what happens if they are sent anyway and get to > > > a node that doesn't implement them? > > > > It has to be management and configuration or alliance games. There is no > negotiation. > > There is no overarching 6LoWPAN protocol that can advertise capabilities > though we're building one for RPL. > > Same goes for all the prior changes to 6LoWPAN, e.g., RFC 8025. > > In practice there is no 6LoWPAN network. There's an ISA100.11a network, a > ZigbeeIP network, a Thread network, or a WiSUN network. Those alliances > specify a particular bundle of functionalities from a bunch of RFCs and build > their compliance tests on that. If Thread decides that the RFRAGs are used, > then all the nodes are capable of it. > > But that's a long story to make in the RFC just to say we do nothing. Do we > really want that? > > I see your point, but we are also in theory supposed to consider the IAB's > guidance from RFC 8170, including among other things incremental > deployability. So my inclination is to include a brief note that since > deployments are expected to be managed and homogeneous, incremental > transition requires a flag day. I used your wording as the last sentence of the introduction. > It did occur to me while reading the diff that we do treat the fragment with > sequence 0 specially, and I didn't fully think through the possibilities if > it is that > first packet that is "too long" and needs to be subdivided. There may be > special considerations for the initial fragment where it gets some special > handling, and though I suspect that there are not any real problems here, and > in any case the datagram itself could be re-sent, I mention it just in case > there > are some new problems (e.g., we get stuck in a case where we have to send > something that gets treated as a reset even if we don't want it to). Not sure I get you. Tentative answers: 1) The first fragment even when retried carries the Datagram_Size in the Fragment_Offset so it is not zero and not confused with a reset. 2) This may enter PMTU discovery land... does it? We could use the first fragment for that, but that will be another specification. > > > > > ---------------------------------------------------------------------- > > > COMMENT: (merged email) > > > ---------------------------------------------------------------------- > > > > > What about > > > > " > > > > There is no requirement on the reassembling endpoint to check that > > the received fragments are consecutive and non-overlapping. > > > > " > > That seems to cover it, though of course there are the usual potential > security considerations if it doesn't check, which IIRC are in the > companion document now. For memory the companion doc https://tools.ietf.org/html/draft-ietf-6lo-minimal-fragment-14 says " * Overlapping fragment attacks are possible with 6LoWPAN fragments but there is no known firewall operation that would work on 6LoWPAN fragments at the time of this writing, so the exposure is limited. An implementation of a firewall SHOULD NOT forward fragments but instead should recompose the IP packet, check it in the uncompressed form, and then forward it again as fragments if necessary. Overlapping fragments are acceptable as long as they contain the same payload. The firewall MUST drop the whole packet if overlapping fragments are encountered that result in different data at the same offset. " > > > > > > > > > > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > |1 1 1 0 1 0 1|E| Datagram_Tag | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | RFRAG Acknowledgment Bitmap (32 bits) | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > I think we need to explicitly say here that the Datagram_Tag, in a > > > reversal > of > > > the previous usage, is scoped to the link-layer *recipient* of the > RFRAG_ACK > > > frame. > > > > It is indeed. Added: > > " > > Datagram_Tag: 8 bits; an identifier of the datagram that is locally > > unique to the Link-Layer recipient. > > > > " > > Hmm, the -16 is showing this still as "sender", not "recipient" (maybe > conflicting edits in intermediate versions?). Confusing isn't it? I guess you're looking at the wrong place 😊 We're talking about the acknowledgment. The text page 12 is correct: " Datagram_Tag: 8 bits; an identifier of the datagram that is locally unique to the Link-Layer recipient. " The text page 10 is about the fragment going the forward way, so it is the sender's namespace " Datagram_Tag: 8 bits; an identifier of the datagram that is locally unique to the Link-Layer sender. " > > "if" was meant to say " in case ", replacing. This can happen. E.g., the > > window > may be smaller than the capacity of the network (related to the nb of hops). > > > > (even more after Mirja's review) I do not want to dig into flow control and > this is borderline. I just wanted to leave the door open for future mechanisms > that are out of scope and that would do it. > > > > Okay, I will not insist on it. Thanks a bunch, slippery slope. > > " > > This specification extends the Virtual Reassembly Buffer (VRB) > > technique to forward fragments with no intermediate reconstruction of > > the entire packet. It inherits operations like Datagram_Tag > > switching and using a timer to clean the VRB once the traffic ceases. > > The first fragment carries the IP header and creates a path from the > > fragmenting endpoint to the reassembling endpoint that all the other > > fragments follow. > > > > " > > Sounds good ("creating the path" is important; "in-order" less so). For this spec that's fully correct. Note that for the LWIG VRB draft, fragments have to be processed in order because of the leftover game even if they are not received in order. > > " > > In addition, the router also forms a reverse LSP state indexed by the > > interface to the next hop, the Link-Layer address the router uses as > > source for that datagram, and the swapped Datagram_Tag. This reverse > > LSP state enables matching the (next interface, destination Link- > > Layer address, swapped_Datagram_Tag) found in an RFRAG > Acknowledgment > > to the abstract forwarding information (previous interface, previous > > Link-Layer address, Datagram_Tag) used to forward the Fragment > > Acknowledgment (RFRAG-ACK) back to the fragmenting endpoint. > > > > " > > Ah, that makes sense. I think I had envisoned the datagram_tag as being > global to the node, across all interfaces and MAC addresses, but there's > not a reason to do so (and in fact reason to not do so, as you discuss > somewhere about how to cope with the limited 8-bit space). The initial text was buggy and your comments made me see it and fix it. Please never refrain from making them! There can be a lot of dust behind a carpet of lack of clarity. > > I cannot see that? Logically that one would have been sent before and > received after. > > Once the FULL is achieved the fragmenting node knows that the > reassembling endpoint is done. > > I couldn't see anything either, but it resembles an edge case that we like > to double-check. So, thanks for double-checking :) Same as above, please keep doing it. > > In addition to the threats detailed therein, an attacker that is on- > > path can prematurely end the transmission of a datagram by sending a > > RFRAG Acknowledgment to the fragmenting endpoint. It can also cause > > extra transmissions of fragments by resetting bits in the RFRAG > > Acknowledgment bitmap, and of RFRAG Acknowledgments by forcing the > > Ack-Request bit in fragments that it forwards. As indicated in > > [FRAG-FWD], Secure joining and the Link-Layer security are REQUIRED > > to protect against those attacks. > > " > > > > Do we want more? > > That looks good. The only thing I'd consider adding is another clause at > the very end, ", as the fragmentation protocol does not include any native > security mechanisms". But it's up to you. Picked > > > Section 7.1 > > Me who thought that the physics exams were behind! > > :) > Must be my chemistry degree at work... I guess that the right (or wrong) molecule can take you anywhere ; ) > I will go reballot now; I had a few more nits that I saw while reading the > diff. Very cool. I'll answer it separately and publish as usual. I should have a stamp to say thanks by now... Pascal _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
