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

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 7 Jun 2016 12:02:32 +0200

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.

>    (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?

Has this message been prototyped, is there a packet dump?

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

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

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

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmm
>

---

From: "Z.W. Yan" <[email-masked]>
Date: Wed, 8 Jun 2016 13:26:01 +0800

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

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

***The procedure used for HNP renumbering in this draft follows the RFC7077, we did not introduce new security risk and failure.

***Yep.

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

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

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 8 Jun 2016 10:06:17 +0200

Hi Z. W. Yan,

Le 08/06/2016 à 07:26, Z.W. Yan a écrit :
> ------------------------------------------------------------------------
>
>
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:
> 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.
>
> 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.

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

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

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

> Maybe we should be specific to say that the security of the UPN
> message is ensured by... (something from RFC5213 and/or 5077).
>
> 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,
>>
>> _______________________________________________ dmm mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/dmm
>>
> _______________________________________________ dmm mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/dmm

---

From: "Z.W. Yan" <[email-masked]>
Date: Wed, 8 Jun 2016 16:47:34 +0800

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,
Z.W. Yan
I agree, thanks.

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

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

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

***Yes, the order is not important.

Sounds good.

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

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

Yours,
Alexandre Petrescu