1. Carles Gomez, Josep Paradells
Optimized 6LoWPAN Fragmentation Header draft-gomez-6lo-optimized-fragmentation-header-00
Carles Gomez, Josep Paradells
Universitat Politècnica de Catalunya (UPC)/Fundació i2cat
Jon Crowcroft
University of Cambridge
IETF 97 – Seoul, November 2016

2. Slide 0: context
Originally motivated by requirements of some LPWAN technologies
S1 and S0 [7228bis], no fragmentation
Very low bit rate, very low message rate
RFC 4944 fragmentation header not suitable
draft-gomez-lpwan-fragmentation-header-02
Suggested to be considered by the 6lo WG
draft-gomez-6lo-optimized-fragmentation-header-00
Same fragmentation header format
Generic motivation
Updated performance analysis in Annex
IETF 97 – Seoul, November 2016

3. Overview 6LoWPAN fragmentation (RFC 4944)
IPv6 MTU requirement: 1280 bytes
IEEE
Maximum frame size of 127 bytes
Fragmentation header
4-byte header (first fragment)
5-byte header (subsequent fragments)
Optimized 6LoWPAN Fragmentation Header (6LoFH)
3-byte header
Lower overhead
Additionally: supports S0 technologies (L2 MTU ≥ 4 bytes)
IETF 97 – Seoul, November 2016

4. Proposed new format Optimized 6LoWPAN Fragmentation Header (6LoFH)
First fragment
Subsequent fragments
IETF 97 – Seoul, November 2016

5. Changes from RFC 4944 and rationale
datagram_size field only included in the first fragment
The format still supports reordering
datagram_tag field size reduced to 1 byte
Ambiguities due to wrapping not expected
Low message rate
datagram_offset increased from 8 bits to 11 bits
Allows to express the offset in 1-byte increments
IETF 97 – Seoul, November 2016

6. Benefits of 6LoFH Simple, byte-exact, short format
Supports maximum L2 payloads ≥ 4 bytes
Overhead (adapt. layer fragm. header bytes)

7. IANA considerations 6LoFHL allocates 16 Dispatch values:
through
through
IETF 97 – Seoul, November 2016

8. Security considerations (I/III)
6LoWPAN fragmentation attacks and mitigation analyzed in the literature
Buffer reservation DoS attack
Attacker sends a first fragment to a target
Reassembly buffer occupied during reassembly timeout
Repeat after the timeout
Low cost attack
Mitigation
Allow fragments of multiple packets in reassembly buffer
Define buffer slots
If buffer overload, discard packets based on sender behavior
IETF 97 – Seoul, November 2016

9. Security considerations (II/III)
Sending spoofed duplicates
Malicious node is required to have overhearing capabilities
Attacker
Overhears fragment
Sends spoofed duplicate (e.g. with random payload)
Receiver
Cannot distinguish legitimate from spoofed
Original IPv6 packet considered corrupt and dropped
Mitigation suggested
Establish a binding among the fragments to be sent
E.g. with cryptographic hash functionality
Receiver can distinguish illegitimate fragments
IETF 97 – Seoul, November 2016

10. Security considerations (III/III)
Implementers should avoid problems due to:
Sending overlapped fragments
Comprising overlapping parts of the original datagram
Announcing a fake datagram size (1st fragment)
IETF 97 – Seoul, November 2016

11. Carles Gomez, Josep Paradells
Questions ?
Carles Gomez, Josep Paradells
Universitat Politècnica de Catalunya (UPC)/Fundació i2cat
Jon Crowcroft
University of Cambridge
IETF 97 – Seoul, November 2016

12. Back-up slide: RFC 4944 fragmentation header format
First fragment
Subsequent fragments
IETF 97 – Seoul, November 2016