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

Hi, Alex,

:

发件人： Alexandre Petrescu 
发送时间： 2016-06-08  16:06:30 
收件人： Z.W. Yan; Jouni.nosmap 
抄送： dmm 
主题： Re: [DMM] WGLC reminder - draft-ietf-dmm-hnprenum-02 

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.

***Because we strictly follow the RFC5213 about the HNP option and Mobile Node Identifier option, 
I am not sure whether we need to relate to the  Mobile Node Id option related documents.

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

***No, Alex, we did not implement the related procedure in the scenario we focus on.

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.

***This is OK, because UPN is sent from LMA to MAG and RA is sent from MAG to the MN, the two messages are sent seperately. 

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.

***Yes, 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?

***Wow, it is a mistake, it should be UPA.

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.

***Your statement is reasonable, we will discuss whether it is necessary before we add it in the new version.

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