Skip to main content

Last Call Review of draft-ietf-lpwan-ipv6-static-context-hc-21
review-ietf-lpwan-ipv6-static-context-hc-21-secdir-lc-salowey-2019-07-31-00

Request Review of draft-ietf-lpwan-ipv6-static-context-hc
Requested revision No specific revision (document currently at 24)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2019-07-19
Requested 2019-07-05
Authors Ana Minaburo , Laurent Toutain , Carles Gomez , Dominique Barthel , Juan-Carlos Zúñiga
Draft last updated 2019-07-31
Completed reviews Genart Last Call review of -21 by Pete Resnick (diff)
Secdir Last Call review of -21 by Joseph A. Salowey (diff)
Assignment Reviewer Joseph A. Salowey
State Completed
Review review-ietf-lpwan-ipv6-static-context-hc-21-secdir-lc-salowey-2019-07-31
Posted at https://mailarchive.ietf.org/arch/msg/secdir/p-D9T5Z2nOJ9DHox1nqLCkd2z0A
Reviewed revision 21 (document currently at 24)
Result Ready
Completed 2019-07-31
review-ietf-lpwan-ipv6-static-context-hc-21-secdir-lc-salowey-2019-07-31-00
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

The summary of the review is Ready.  The document has a good discussion of
problems that an attacker can cause with compression and fragmentation.   My
knowledge of LPWAN is limited, so I included two possible additions to the
security considerations if they are relevant to the LPWAN environment.

One area that is not covered in the security considerations but has been a
problem with fragmentation in practice is the use of fragmentation to try to
bypass network packet inspection devices such as firewalls.   I don't know
enough about the deployment environments to know if the fragmented packets
would traverse such a device.

It is not clear to me if the header to be compressed can contain secret
information such as a cookie or authentication token.  If these packets are
going to be encrypted then compression can provide an attacker with a means to
break the confidentiality on certain data in special circumstances.  Examples
of these are BREACH[1] and CRIME attacks.  These require some specific
conditions that may not exist in the use cases for this protocol. In general
some secret information must be present in a packet,  an attacker must be able
to inject arbitrary data into the packet and the attacker must be able to
observe the effect on the encrypted compressed packet-size.  I don't know if
this is a likely scenario in the protocols use cases.  These attacks can be
mitigated by not compressing values that may be secret in the header.

[1] https://en.wikipedia.org/wiki/BREACH
[2] https://en.wikipedia.org/wiki/CRIME