Hello Mirja: Again many thanks for your very deep review.
I published -14 to propose some changes that address your DISCUSS comments as well as Benjamin's Please see https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-fragment-recovery-14 . Then I published https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-fragment-recovery-15 with proposals to fix Benjamin's COMMENTS. Since it is cut off, I'm publishing https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-fragment-recovery-16 with proposals to fix your COMMENTS in a row without waiting for the answer. Please find a first round of discussion on your COMMENTS below: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > 1) side comment regarding section 2.2: Note that there is also a working group > draft defining PMTUD for datagram transports: draft-ietf-tsvwg-datagram- > plpmtud Yes, I guess 6LoWPAN could learn and adapt. The problem is below IP for sub 1280 interfaces over a number of mesh hops, but the method could be the same or similar. > > 2) Sec 6: > "Note that acknowledgments might consume precious resources so the use of > unsolicited acknowledgments should be configurable and not enabled > by default." > Maybe SHOULD? done > > 3) Sec 6: Maybe use normative language here? > OLD > "Fragments are sent in a round-robin fashion: the sender sends all the > fragments for a first time before it retries any lost fragment; lost > fragments are retried in sequence, oldest first. This mechanism > enables the receiver to acknowledge fragments that were delayed in > the network before they are retried." > NEW > "Fragments MUST be sent in a round-robin fashion: the sender MUST send all > the > fragments for a first time before it retries any lost fragment; lost > fragments MUST be retried in sequence, oldest first. This mechanism > enables the receiver to acknowledge fragments that were delayed in > the network before they are retried." > Applied > 4) Sec 6: > "When a single frequency is used by contiguous hops, the sender should > insert a delay between the frames (e.g., carrying fragments) that are > sent to the same next hop. > Maybe SHOULD? > done > 5) sec 6.3: > "Until the timer > elapses, fragments of that datagram may still be received, e.g. if > the RFRAG-ACK was lost on the way back and the source retried the > last fragment. In that case, the router forwards the fragment > according to the state in the VRB." > Why should a router forward the segment, rather than re-sending/re- > generating the full ACK knowing that all segments have been successfully > received? I guess that there was a reason; but I cannot fathom it at this point. Let me change the text. " Either way, if the RFRAG-ACK indicates that the fragment was entirely received (FULL bitmap), it arms a short timer, and upon timeout, the VRB and all the associated state are destroyed. Until the timer elapses, fragments of that datagram may still be received, e.g. if the RFRAG-ACK was lost on the path back and the source retried the last fragment. In that case, the router generates an RFRAG-ACK with a FULL bitmap back to the fragmenting endpoint if an acknowledgement was requested, else it silently drops the fragment. " > 6) sec 8: > As currently described an off-path attacker could abort the transmission if > the > datagram_tag is known. I think it should be mention somewhere that a null > bitmap should only be accepted and forwarded if received on the right > interface. Further it might make sense to not erase state immediately but wait > to see if any further fragments are received from the sender. In any case this > attack should at least be mentioned in section 8. You are correct, I made a change in 15 that now includes the interface in the lookup for another comment from Benjamin. That caused me to change minimal fragments as well. With that change, the attacker would need to be on the same interface as a hop of the path, which means on-path really, otherwise it cannot cause the MPLS forwarding. The text quoted above has the timer that maintains a short-lived state for the retries in flight. Some new text was added to section 8 in particular: " 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. " Basically the only protection we have for 6LoWPAN compression and fragmentation as a whole is the lower layer security. > > 7) Appendix B: > "The recovery mechanism must support highly > fragmented packets, with a maximum of 32 fragments per packet." > Where does the 32 come from and shouldn't this be stated normatively in > body of the document? It was computed from LoWPAN (IEEE std 802.15.4) to ensure we fit above 2K bytes in a payload that could be in the order or above 70 bytes, with a margin. We used that requirement to dimension the bitmap. I'm not sure about normative, this is the information that we used to design the protocol but the protocol coud live without that text at all. > > Nit: you use both "time out" and "time-out". I recommend to change the two > occasions of "time out" to "time-out". > Fixed Again many thanks! P _______________________________________________ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
