Last Call Review of draft-ietf-lpwan-ipv6-static-context-hc-21

Request Review of draft-ietf-lpwan-ipv6-static-context-hc
Requested rev. 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 Salowey (diff)
Assignment Reviewer Joseph Salowey 
State Completed
Review review-ietf-lpwan-ipv6-static-context-hc-21-secdir-lc-salowey-2019-07-31
Posted at
Reviewed rev. 21 (document currently at 24)
Review result Ready
Review completed: 2019-07-31


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.