Hello Magnus: Many thanks for your review!
Let's see below: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I am uncertain if there is security risk that is poorly noted. I don't think > it is > significant as an intermediate node will in many other ways be able to > interfere > with the transmission of the fragments. However, it appears to me that the > below formulation potentially allow a fragment sender to go into an > interesting > state by acknowledging fragments prior to even have received them, causing > the sender to abort the transmission prematurely? > > When all the fragments are received, the receiving endpoint > reconstructs the packet, passes it to the upper layer, sends an RFRAG > Acknowledgment on the reverse path with a FULL bitmap, and arms a > short timer, e.g., in the order of an average round-trip delay in the > network. As the timer runs, the receiving endpoint absorbs the > fragments that were still in flight for that datagram without > creating a new state. The receiving endpoint abort the communication > if it keeps going on beyond the duration of the timer. > > Could the author please comment on this aspect of what would occur in the > fragment sender if it receives an RFRAG-ACK will full bitmap prior to having > send all fragments, and also what would happen if this is received very > shortly > after having sent the last fragment? > An attacker that is on path can indeed do many things. The ones that you point out could be detected by the transmitter. Others cannot. A critical aspect in 6LoWPANs is to keep the implementation concise and simple. So yes, a "rich" implementation can detect some situations and report, provided that it has extra memory and bandwidth to do so. But the recommendation stays the same, inherited from [FRAG-FWD]. We need a secure join and a link layer security that prevents rogue access. I suggest to add the second paragraph below: " This document specifies an instantiation of a 6LoWPAN Fragment Forwarding technique. [FRAG-FWD] provides the generic description of Fragment Forwarding and this specification inherits from it. The generic considerations in the Security sections of [FRAG-FWD] apply equally to this document. 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 sender. 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. " Is that enough? Many thanks again; Pascal _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
