Re: [6lo] Magnus Westerlund's No Objection on draft-ietf-6lo-fragment-recovery-12: (with COMMENT)

["Pascal Thubert (pthubert)" <[e-mail]>]

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