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

Jong-Hyouk Lee <> Fri, 06 January 2017 07:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B52F5129C21; Thu, 5 Jan 2017 23:15:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PUcWolv7rEMT; Thu, 5 Jan 2017 23:15:13 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c05::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C6ED1128BA2; Thu, 5 Jan 2017 23:15:13 -0800 (PST)
Received: by with SMTP id g1so43181849pgn.0; Thu, 05 Jan 2017 23:15:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=LrwntxkQVkLbDxb3F0qPLcloediKbgUB3L4bOdaHxqg=; b=QSCStFrQxhv6xThozo76jHz4+7dnfcNplMXDyFXuj1zE+Ryi4iqpZbaAyYidRwMywP qYg8TOIRri+5X9L64hHbNJSHmNqsuMSjlztJabeaipVtZAYTED6VNqGBphBHlq/YsMHc pKLPCPy4j1WDOntW5ztWDxFvz7EAM5NfEztWtAnQ5e7bGi7R1IeL4z7+UequSwAPKiAd P0Bi+BJ3XV7+ZA3PWvm6ymI9d4ZigaEnPRjKhtWkFyhnCI6BOSwdQPVCm1yS1E/CY11A mVxMEb44XRrd20XLBMpGk+9i+G3yoQh0CbSJv3lRtpo9hz4XJA5N9pCScFGpea4EXKQ+ 25Qw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=LrwntxkQVkLbDxb3F0qPLcloediKbgUB3L4bOdaHxqg=; b=RmAC5wcfqBBpBwnQZePi46vg0+Nj3bYzq4Bl7YJILZSd3AkTvnEcc6ikfOTD4sUlYu 7EGVg9q8GP1WJI2mrs+4bC3zbikXjZlnwrl3JGTtpL1ulMmTKJatPNi7C14WoiSTjqKP YRKVYj3rqUsVsJm+6DCNTTdXvf0/OPCCZXw8190fIS3zwWQpoMdCNGLJpQ9MQJyO/deU a8YBM8osare3kBewQ2NxVyIqj1+09Tmhz2HvrQcg24Y08ofyeOyhaZWqZmYo6362Hty1 GSsZ+1byEH/6q3scVc+3WykOVcq1GmrzZTaNp11rMzPNNM9lMX7LXQrAs4MmNkvH4Z3U W1hQ==
X-Gm-Message-State: AIkVDXJLjvUIaMoMaXH3lgm6ChX6XNAbMFJPcWDSh2CZbgmwFGoMFRiE4XWc8W/aEWqp5Q==
X-Received: by with SMTP id m61mr161940875plb.60.1483686913351; Thu, 05 Jan 2017 23:15:13 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id j130sm134138439pgc.2.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Jan 2017 23:15:11 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_7C1CF441-30A3-4DFA-B4C6-0369364C08DF"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: [DMM] Review of draft-ietf-dmm-hnprenum-03
From: Jong-Hyouk Lee <>
In-Reply-To: <>
Date: Fri, 6 Jan 2017 16:15:07 +0900
Message-Id: <>
References: <>
To: Jean-Michel Combes <>
X-Mailer: Apple Mail (2.3259)
Archived-At: <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 06 Jan 2017 07:15:15 -0000

Dear Jean-Michel

Thanks for your kind comments. We have revised the draft and uploaded it: <>

Plz see inline then.

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


> On 20 Dec 2016, at 3:35 AM, Jean-Michel Combes <> 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
> 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.”


> Best regards,
> JMC.
> </JMC>
> _______________________________________________
> dmm mailing list