Re: [6lo] Benjamin Kaduk's Discuss on draft-ietf-6lo-minimal-fragment-12: (with DISCUSS and COMMENT)

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

Hello Benjamin:

Let's go then!

> >
> > So I suggest 'typically' instead of "if needed":
> > "
> >    Typically, Node A starts with an uncompressed packet and compacts the
> >    IPv6 packet using the header compression mechanism defined in
> >    [RFC6282].
> > "
> 
> That seems reasonable.  IIRC, my understanding at the time was that this
> scenario would only arise when fragmentation was performed at a different
> node than the original sender of the IP packet, which I expect to be rare in
> homogeneous LPWANs.

Sorry I confused you. For a packet sourced in the Internet, the border router does the compression at the ingress of the 6LoWPAN network. So it is not the original sender. But it is both the 6LoWPAN endpoint and the fragmenting endpoint.




> > I would have appreciated a suggestion here : ) does this work?
> > "
> >    *  Attacks based on predictable fragment identification values are
> >       also possible but can be avoided.  The datagram_tag SHOULD be
> >       assigned pseudo-randomly in order to defeat such attacks.  A
> >       larger size of the datagram_tag makes the guessing more difficult
> >       and reduces the chances of an accidental reuse while the original
> >       packet is still in flight, at the expense of more space in each
> >       frame.
> > "
> 
> Hmm, talking about a "larger size of the datagram_tag" (or wait, did we end up
> at "Datagram_Tag"?) feels odd since this document has fixed it at 16 bits.

Hum, not this doc but RFC 4944 which is described page 6. 
"
Section 5.3 of
   [RFC4944] defines the format of the header for the first and
   subsequent fragments.  All fragments are tagged with a 16-bit
   "Datagram_Tag", used to identify which packet each fragment belongs
"
This doc does not impose anything per se, e.g. fragment recovery inherits from this but uses a smaller tag.


> Maybe:
> 
>    *  Attacks based on predictable fragment identification values are
>       also possible but can be avoided.  The datagram_tag SHOULD be
>       assigned pseudo-randomly in order to reduce the risk of such attacks.
>       Nonetheless, some level of risk remains that an attacker able to
>       authenticate to and send traffic on the network can guess a valid
>       Datagram_Tag value, since there are only 2^16 possible values.

Nice, I'd just change " only 2^16" with " a limited number of" to keep it generic

I'm continuing with your other mails based on -14.

Keep safe;

Pascal