Re: [DMM] Review of draft-ietf-dmm-hnprenum-03

[Jong-Hyouk Lee <jonghyouk@xxxxxxxxx>]

Dear Jean-Michel

Thanks for your kind comments. We have revised the draft and uploaded it: https://tools.ietf.org/html/draft-ietf-dmm-hnprenum-04

Plz see inline then.

--
Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random
Protocol Engineering Lab., Sangmyung University

#email: jonghyouk@xxxxxxxxx
#webpage: https://sites.google.com/site/hurryon

On 20 Dec 2016, at 3:35 AM, Jean-Michel Combes <jeanmichel.combes@xxxxxxxxxx> wrote:

Reviewer: Jean-Michel Combes
Review result: Ready with Issues

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?

Thx for your point. The related reference (RFC7010) from 6renum WG has been added in the revised draft (-04).

*** 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.

Thx for your comment. As you mentioned, unlike MIPv6, PMIPv6 does not allow the MN to be involved in creating security associations or creating binding cache entries. The LMA assigns the HNP for the MN. The assignment of the valid HNP is a responsibility of the LMA in PMIPv6. 

To reflect your comment, we have revised a bit Section 7 (Security Considerations) as: "The protection of UPN and UPA messages in this document follows [RFC5213] and [RFC7077].  This extension thus causes no further security problems for protecting of the messages.” In addition, we have added the following sentence in Section 6 (Other Issues): "The LMA must assign only an authorized HNP for the MN.”

Thanks!

Best regards,

JMC.

</JMC>


_______________________________________________
dmm mailing list
dmm@xxxxxxxx
https://www.ietf.org/mailman/listinfo/dmm