Re: [DMM] WGLC reminder - draft-ietf-dmm-hnprenum-02

Alexandre Petrescu <alexandre.petrescu@gmail.com> Wed, 08 June 2016 08:06 UTC

Return-Path: <alexandre.petrescu@gmail.com>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D93812D1E3 for <dmm@ietfa.amsl.com>; Wed, 8 Jun 2016 01:06:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.353
X-Spam-Level:
X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WcPeVzDlh66F for <dmm@ietfa.amsl.com>; Wed, 8 Jun 2016 01:06:27 -0700 (PDT)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BFFD12D10B for <dmm@ietf.org>; Wed, 8 Jun 2016 01:06:26 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u5886HrW018031; Wed, 8 Jun 2016 10:06:17 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0E41420748C; Wed, 8 Jun 2016 10:06:48 +0200 (CEST)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id F398E2038E6; Wed, 8 Jun 2016 10:06:47 +0200 (CEST)
Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u5886HNe010914; Wed, 8 Jun 2016 10:06:17 +0200
To: "Z.W. Yan" <yan@cnnic.cn>, "Jouni.nosmap" <jouni.nospam@gmail.com>
References: <95BCA70A-A090-407D-B44D-83E5F65FC501@gmail.com> <201606081326010369670@cnnic.cn>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <584fd9a5-86ea-d071-9556-b34ee7436de4@gmail.com>
Date: Wed, 08 Jun 2016 10:06:17 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <201606081326010369670@cnnic.cn>
Content-Type: text/plain; charset="gbk"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmm/tpIIaOdX3CwwU1xkH-zPuVKRvw8>
Cc: dmm <dmm@ietf.org>
Subject: Re: [DMM] WGLC reminder - draft-ietf-dmm-hnprenum-02
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jun 2016 08:06:30 -0000

Hi Z. W. Yan,


Le 08/06/2016 à 07:26, Z.W. Yan a écrit :
> Thank you for your comments, Alex, please find my inline responses.
>
>
> 2016-06-08
> ------------------------------------------------------------------------
>
>
Z.W. Yan
> ------------------------------------------------------------------------
>
>
*发件人:* Alexandre Petrescu
> *发送时间:* 2016-06-07  18:02:49 *收件人:* Jouni.nosmap *抄送:* dmm *主题:* Re:
> [DMM] WGLC reminder - draft-ietf-dmm-hnprenum-02 Hi, This is comments
> about draft-ietf-dmm-hnprenum-02
> https://tools.ietf.org/html/draft-ietf-dmm-hnprenum-02 The draft is
> short, and reads very well.  I think it should be further pursued.
> Here are some comments:
>> o  When the MN obtains the new HNP information, it deletes the old
>> HoA and configures a new HoA with the newly allocated HNP.
> It would make sense to delete not only _the_ old HoA but all
> addresses configured within the old HNP.  Because recently the hosts
> may configure more than one address when receiving a Router
> Advertisement - they may also configure at least one 'privacy'
> address.  All of them should be deleted.
>
> ***This description will be revised as "When the MN obtains the new
> HNP information,
>
> it deletes all the addresses (e.g., HoA) configured with the old HNP
> and configures new addresses with the newly allocated HNP."

I agree, thanks.

>
>> (1) UPN message
>>
>> In the UPN message sent from the LMA to the MAG, the notification
>> reason is set to 2 (UPDATE-SESSION-PARAMETERS).  Besides, the HNP
>> option containing the new HNP and the Mobile Node Identifier
>> option carrying Identifier of MN are contained as Mobility Options
>> of UPN.
> Can we see a message format of this?  Is it an ICMP message?  A
> Mobility Header?
>
> ***We did not present the message format because the UPN message, as
> a mobility header message, is speficied in RFC7077, (and also the
> notification reason used in this draft). And HNP option and Mobile
> Node Identifier option are speficied in RFC5213.

I think there are multiple things here.  I think the following:

The Mobile Node Id option is defined in RFC4283, not RFC5213.  The draft 
hpnrenum should relate to it.  Further, there is work ongoing to update 
the MNId definition with more cases.  The draft is 
draft-perkins-mext-4283mnids-01.txt.  It is not yet a WG item, but anyways.

> Has this message been prototyped, is there a packet dump?
>
> ***The procedure used for HNP renumbering in this draft follows the
> RFC7077, we did not introduce new security risk and failure.

I am asking whether it has been prototyped (implemented), not whether it 
introduces new risks.  I wanted to see a packet dump of wireshark.

For example, one can take the scapy open source tool and simply generate 
a UPN message for the HNP-renum draft.  This can be very straightforward.

I am asking because you are saying that there are two HNPs in the RA, 
but only one HNP in the UPN.  Maybe this is normal.

I am asking also because I wonder whether the order of appearance of 
MNID and HNP is important in the UPN message.  Maybe the order is not 
important.

>> In the first Prefix Information option, the old HNP is carried but
>> both the related Valid Lifetime and Preferred Lifetime are set to
>> 0. In the second Prefix Information option, the new HNP is carried
>> with the Valid Lifetime and Preferred Lifetime set to larger than
>> 0.
> This reads smart: a unique message to tell the Host to delete the old
>  prefix and use the new one.  I agree.
>
> ***Yep.
>
>> (3) DHCP Message
>>
>> When the DHCP is used in PMIPv6 to configure the HoA for the MN, a
>> new IPv6 HoA is generated based on the new HNP.  Trigged by the
>> UPN message, the MAG will request the new HoA from the DHCP server
>> first and then the MAG updates the allocated HoA to the MN through
>> the DHCP server-initiated configuration exchange [RFC3315].
> I think this is too specific.  It says MAG should request the new HoA
>  (but what if MAG is Relay?).  Second it says that the MAG requests
> an address and then the server does server-initiated configuration -
> this is also very specific. Maybe we can formulate in a different
> way, in which these specificities are just examples in the DHCP
> behaviour.  Because there are other ways in which DHCP can act to
> achieve the same - e.g. use Prefix Delegation, use Relays, and
> others.
>
> ***Agree, then the description will be revised as "When the DHCP is
> used in PMIPv6 to configure the addresses for the MN, new IPv6
> addresses (e.g., HoA) will be generated based on the new HNP and the
> related DHCP procedure is also trigged by the reception of UPN
> message."

triggered... yes, I agree.

>
>> 7.  Security considerations
>>
>> This extension causes no further security problem.  The security
>> considerations in [RFC5213] and [RFC7077] are enough for the basic
>> operation of this draft.
> Maybe we should be specific to say that the security of the UPN
> message is ensured by... (something from RFC5213 and/or 5077).
>
> ***Because we did not specify new signaling messages in this draft,
> the suggestions to protect UPN/UNA messages are illustrated in
> RFC7077, which also follow the security considerations in RFC5213.
> Then we describe this part as "This extension causes no further
> security problem. The protection of UPN and UNA messages follow
> [RFC5213] and [RFC7077]."

Sounds good.

But now that you mention UNA: the UNA message does not appear in the 
section 5 "Message format".

So I digged further and I discover that "Update Notification Ack" is 
defined in RFC7077 and it's actually abbreviated "UPA", not "UNA" - 
which name is right?

I am not am implementor tester of this, but I think, since this is a 
specific operation (delete routing info based on old HNP, add new 
routing INFO based on new HNP), I think it could make sense to define a 
new "Status Code" in UNA/UPA to reflect specific error to that specific 
operation.

For example, the value could be decimal 127, and the meaning could be 
"FAILED-TO-RENUMBER-HNP".

Of course, if the implementer does not find value or no reason in this 
new Status Code, then I will not insist.

Yours,

Alexandre Petrescu

>
>
> Alex Le 23/05/2016 à 19:17, Jouni.nosmap a écrit :
>> Folks,
>>
>> Friendly nudge to do reviews on drafts we got now in WGLC.
>>
>> Jouni
>>
>> Sent from a smart phone.. Mind the typos..
>>
>> _______________________________________________ dmm mailing list
>> dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
>>
> _______________________________________________ dmm mailing list
> dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm