Skip to main content

Last Call Review of draft-ietf-v6ops-64share-09
review-ietf-v6ops-64share-09-secdir-lc-sheffer-2014-02-19-00

Request Review of draft-ietf-v6ops-64share
Requested revision No specific revision (document currently at 10)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2014-02-21
Requested 2014-02-13
Authors Cameron Byrne , Dan Drown, Vizdal Ales
I-D last updated 2014-02-19
Completed reviews Genart Last Call review of -09 by Ben Campbell (diff)
Secdir Last Call review of -09 by Yaron Sheffer (diff)
Opsdir Last Call review of -09 by Victor Kuarsingh (diff)
Assignment Reviewer Yaron Sheffer
State Completed
Request Last Call review on draft-ietf-v6ops-64share by Security Area Directorate Assigned
Reviewed revision 09 (document currently at 10)
Result Ready
Completed 2014-02-19
review-ietf-v6ops-64share-09-secdir-lc-sheffer-2014-02-19-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.



This document describes two options of providing hosts behind a 3GPP UE 


(e.g., cellular router) with an IPv6 network prefix, in networks that do 


not support IPv6 prefix delegation. The document is explicitly 


non-normative.




Summary

The document is ready to progress.

Details



- I don't understand why the first scenario (sec. 4.2) is even useful, 


i.e. why allocate the /64 to the LAN (and not just settle for a 


link-local prefix) when the UE does not have an address on the 3GPP 


link, and so cannot route traffic to the Internet?






- Despite the non-normative status of the document, I think the security 


considerations deserve stronger wording. I suggest to replace "shall be 


considered" by "SHOULD be applied".






- I would suggest that the security considerations also mention the 


privacy implications of having a (typically) small number of devices, 


all within a single unchanging network prefix. I *believe* this is 


behind the discussion of RFC 4941 is Sec. 4.3, but I would rather have 


the threat spelled out.




Thanks,
     Yaron