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 carlesgo@entel.upc.edu Jon Crowcroft University of Cambridge IETF 97 – Seoul, November 2016

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

Overview 6LoWPAN fragmentation (RFC 4944) IPv6 MTU requirement: 1280 bytes IEEE 802.15.4 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

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

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

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

IANA considerations 6LoFHL allocates 16 Dispatch values: 11001 000 through 11001 111 11010 000 through 11010 111 IETF 97 – Seoul, November 2016

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

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

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

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

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