Early Review of draft-ietf-dmm-hnprenum-03
review-ietf-dmm-hnprenum-03-intdir-early-combes-2016-12-19-00
Request | Review of | draft-ietf-dmm-hnprenum |
---|---|---|
Requested revision | No specific revision (document currently at 07) | |
Type | Early Review | |
Team | Internet Area Directorate (intdir) | |
Deadline | 2016-12-21 | |
Requested | 2016-12-06 | |
Requested by | Bernie Volz | |
Authors | Zhiwei Yan , Jong-Hyouk Lee , XiaoDong Lee | |
I-D last updated | 2016-12-19 | |
Completed reviews |
Intdir Early review of -03
by Jean-Michel Combes
(diff)
Opsdir Last Call review of -06 by Tim Chown (diff) Genart Last Call review of -05 by Meral Shirazipour (diff) Genart Telechat review of -06 by Meral Shirazipour (diff) |
|
Assignment | Reviewer | Jean-Michel Combes |
State | Completed | |
Request | Early review on draft-ietf-dmm-hnprenum by Internet Area Directorate Assigned | |
Reviewed revision | 03 (document currently at 07) | |
Result | Ready w/issues | |
Completed | 2016-12-19 |
review-ietf-dmm-hnprenum-03-intdir-early-combes-2016-12-19-00
Hi, First, this is the first time I am trying this new tool for reviewers, so, sorry if I am making process mistakes. Please find the official text below: <JMC> I am an assigned INT directorate reviewer for draft-ietf-dmm-hnprenum-03. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see http://www.ietf.org/iesg/directorate.html. Please, find my review below: *** Section 1, p2 *** "However, a widespread use of PI addresses may cause Border Gateway Protocol (BGP) scaling problems." Any Ref? *** Section 7, p6 *** "The protection of UPN and UPA messages in this document follows [RFC5213] and [RFC7077]. This extension causes no further security problem." Sorry but, I must admit I don't agree: [RFC5213] says: "The Mobile IPv6 specification [RFC3775] requires the home agent to prevent a mobile node from creating security associations or creating binding cache entries for another mobile node's home address. In the protocol described in this document, the mobile node is not involved in creating security associations for protecting the signaling messages or sending binding updates. Therefore, the local mobility anchor MUST restrict the creation and manipulation of proxy bindings to specifically authorized mobile access gateways and prefixes. The local mobility anchor MUST be locally configurable to authorize such specific combinations. Additional mechanisms, such as a policy store or Authentication, Authorization, and Accounting (AAA) may be employed, but these are outside the scope of this specification." Based on the fact that an operator could set up internal check-ups about the allowed HNP(s) for the MN, there could be strong restrictions (e.g., not allowed roaming between operators) about the mechanism described inside this document. So, IMHO, additional text is needed regarding this point. Best regards, JMC. </JMC>