Subject: Re: [DMM] Alexey Melnikov's No Objection on draft-ietf-dmm-lma-controlled-mag-params-04: (with COMMENT)

From: "Dhananjay Patki (dhpatki)" <[email-masked]>
Date: Tue, 9 May 2017 16:09:08 +0000

Hi Mirja/Alexey/Ben,

Thanks for your respective reviews. Please find below responses to your comments. The comments are addressed in the new version 05 that is attached to this email (not uploaded yet). Please review the rework and let me know if you have any further comments.

----------------------------------------------------------------------
Mirja Kühlewind
----------------------------------------------------------------------
 
Minor comments:
 
1) Please add a reference to rfc5213 right at the beginning of the
intro:
s/A large Proxy Mobile IPv6 (PMIPv6) deployment/A large Proxy Mobile IPv6
(PMIPv6) [RFC5213] deployment/
 
[Dhananjay] Added
 
2) Section 3.1 says: "The alignment of the sub-option MUST be 4n."
Is that actually (still) important? Is this also the reason for the
reserved field in the option or is there an expectation that any flags
will be needed in future? Could you remove the reserved field and require
6n then (given you anyway at least need the LCMP Type and Length fields)?
No strong need to change anything, just asking...
 
[Dhananjay] The alignment of the top-level LCMP is changed to 4n+2 and that of the sub-options is changed to 4n. The alignment is used for consistency with other PMIPv6 RFCs.
 
3) Given that section 4 only has one subsection, I guess the subsection
heading for 4.1 can simply be removed.
 
[Dhananjay] Done
 
4)  Are sections 4 and 5 updates to RFC5213? I find the use of normative
language at the beginning of each section a little weird, e.g.:
"The LMA MUST allow the following variables to be configured by the
system management."
Isn't it implicit that these things have to be configurable to implement
this option? I would just not use normative language here...
 
[Dhananjay] Rephrased
 
5) Also section 4: I would recommend to use normative language rather to
define the used values itself than what they should be configured to,
e.g.
OLD
"It SHOULD NOT be set to less than 30 seconds or more than 3600
seconds."
NEW
"The delay time SHOULD NOT be less than 30 seconds or more than 3600
seconds."
Maybe even use a MUST here?
 
[Dhananjay] Changed as suggested. I have retained SHOULD NOT to follows the same language as in RFC  5847.
 
6) Security consideration: Aren't there security implications if an
external node can influence the number of message and therefore the
network load?
 
[Dhananjay] Authentication option defined in RFC 4285 will protect against influence from external nodes. In general this extension inherits the security considerations from RFC 5213 and does not require any additional security considerations. The section is updated to reflect this.

----------------------------------------------------------------------
Alexey Melnikov
----------------------------------------------------------------------
 
In 3.1.1 and 3.1.2: I assume all 16-bit values are in Network byte order,
but it would be good if the document said so.
 
[Dhananjay] Network byte order is an implicit requirement. RFC 2360 talks about this.
 
In response to Mirja's point 4: I think specifying requirements on
management interfaces is appropriate using RFC 2119 language. And yes, if
an option is sent on the wire, it should be configurable. But I think
drawing implementor's attention to this is important.
 
[Dhananjay] I believe this is no AI on this.

----------------------------------------------------------------------
Ben Campbell
----------------------------------------------------------------------
 
Substantive:
 
Security Considerations: Seems like more is needed here. Do you mean to
say that none of these parameters add any security considerations that
were not there for existing headers? If that's the case, please say so,
and why people believe that to be the case.
 
[Dhananjay] Rephrased
 
Editorial:
- Abstract: Can you mention what sort of parameters this contemplates?
(At a very high level.)
 
[Dhananjay] Rephrased
 
- 5, 2nd paragraph: "MUST be extended " seens like a statement of fact.
-- "parameters MUST be defined" Doesn't this document define them?
 
[Dhananjay] Rephrased

--
Regards,
Dhananjay

-----Original Message-----
From: Alexey Melnikov <[email-masked]>
Date: Wednesday, 12 April 2017 at 4:08 PM
To: The IESG <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Dapeng Liu <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Alexey Melnikov's No Objection on draft-ietf-dmm-lma-controlled-mag-params-04: (with COMMENT)
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Resent-Date: Wednesday, 12 April 2017 at 4:08 PM

Alexey Melnikov has entered the following ballot position for
draft-ietf-dmm-lma-controlled-mag-params-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dmm-lma-controlled-mag-params/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

In 3.1.1 and 3.1.2: I assume all 16-bit values are in Network byte order,
but it would be good if the document said so.

In response to Mirja's point 4: I think specifying requirements on
management interfaces is appropriate using RFC 2119 language. And yes, if
an option is sent on the wire, it should be configurable. But I think
drawing implementor's attention to this is important.

---

From: "Dhananjay Patki (dhpatki)" <[email-masked]>
Date: Tue, 9 May 2017 16:14:21 +0000

[Resending with some formatting changes]

Hi Mirja/Alexey/Ben,

 
Minor comments:

[Dhananjay] Added

[Dhananjay] Done

[Dhananjay] Rephrased

 

 
Substantive:

[Dhananjay] Rephrased

Editorial:

[Dhananjay] Rephrased

[Dhananjay] Rephrased

--
Regards,
Dhananjay

---

From: "Dhananjay Patki (dhpatki)" <[email-masked]>
Date: Fri, 12 May 2017 18:57:11 +0000

Hi Mirja/Alexey/Ben,

Please let me know if there are further comments on the rework (changed draft re-attached to this email).
--
Regards,
Dhananjay

-----Original Message-----
From: "Dhananjay Patki (dhpatki)" <[email-masked]>
Date: Tuesday, 9 May 2017 at 9:44 PM
To: Mirja Kühlewind <[email-masked]>, Alexey Melnikov <[email-masked]>, Ben Campbell <[email-masked]>, The IESG <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Dapeng Liu <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Alexey Melnikov's No Objection on draft-ietf-dmm-lma-controlled-mag-params-04: (with COMMENT)

Hi Mirja/Alexey/Ben,

 
Minor comments:

[Dhananjay] Added

[Dhananjay] Done

[Dhananjay] Rephrased

 

 
Substantive:

[Dhananjay] Rephrased

Editorial:

[Dhananjay] Rephrased

[Dhananjay] Rephrased

--
Regards,
Dhananjay

---

From: Ben Campbell <[email-masked]>
Date: Fri, 12 May 2017 17:11:08 -0500

The latest attached version resolves my editorial comments. However, it does not resolve my one substantive comment.

> On May 9, 2017, at 11:09 AM, Dhananjay Patki (dhpatki) <[email-masked]> wrote:
> 

The attached version modifies the text to say that the new parameters here inherit the guidelines from RFC5213.

My point was to say that this draft creates a way to send new kinds of options. Is the content of these new parameters similar enough to those from RFC 5213 that those guidelines still apply? Does the ability to change the re-registration and heartbeat frequencies fall sufficiently into those existing guidelines that nothing else needs to be said? If so, then it would be helpful to say that. But if those new capabilities are materially different than previous ones, then some text that describes how they are different, ways they could be abused, and any mechanisms that can mitigate that abuse.

For the record, I am not saying that I believe that these new capabilities create new vulnerabilities. But the security considerations should help the reader understand whether that is true or not.

Thanks!

Ben.

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Mon, 15 May 2017 02:57:10 +0000

Hi Ben,

>and why people believe that to be the case.

The option defined in this draft, ³LMA Controlled MAG Parameters² option
and its sub-options) are standard mobility options. The base specification
(RFC5213) provides the security framework for carrying any mobility
options securely in the PMIPv6 signaling messages and hence does not
require any additional security consideration from the point of the
transport security. Now, with respect to the content carried in these
options and their privacy, these are configuration timers with no privacy
tags. Exposing the content of these mobility options to an intruder does
not introduce any new security threats. Furthermore, the base PMIPv6
document specifies the use of IPSec for security the signaling message.
Operators can potentially use ESP with integrity and with privacy
protection for security the messages. So,  I tend to think the text in the
security consideration and in conjunction with the text in RFC5213
adequately cover all the security aspects.

Regards
Sri

On 5/12/17, 3:11 PM, "Ben Campbell" <[email-masked]> wrote:

>The latest attached version resolves my editorial comments. However, it
>does not resolve my one substantive comment.
>
>The attached version modifies the text to say that the new parameters
>here inherit the guidelines from RFC5213.
>
>My point was to say that this draft creates a way to send new kinds of
>options. Is the content of these new parameters similar enough to those
>from RFC 5213 that those guidelines still apply? Does the ability to
>change the re-registration and heartbeat frequencies fall sufficiently
>into those existing guidelines that nothing else needs to be said? If so,
>then it would be helpful to say that. But if those new capabilities are
>materially different than previous ones, then some text that describes
>how they are different, ways they could be abused, and any mechanisms
>that can mitigate that abuse.
>
>For the record, I am not saying that I believe that these new
>capabilities create new vulnerabilities. But the security considerations
>should help the reader understand whether that is true or not.
>
>Thanks!
>
>Ben.
>
>

---

From: Ben Campbell <[email-masked]>
Date: Mon, 15 May 2017 09:57:58 -0500

> On May 14, 2017, at 9:57 PM, Sri Gundavelli (sgundave) <[email-masked]> wrote:
> 
> Hi Ben,
> 
> 

It would help to summarize those thoughts in the draft.

But, you responded to my original comments, but not my latest from the most recent text version. In particular, the question: "Does the ability to change the re-registration and heartbeat frequencies fall sufficiently into those existing guidelines that nothing else needs to be said?” Do these really fit into the category of “standard mobility options” as contemplated by RFC 5213?

Ben.

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 16 May 2017 06:01:05 +0000

Hi Ben,

>It would help to summarize those thoughts in the draft.

Ack. Some additional text capturing the above comments can go into the
draft.

>
>But, you responded to my original comments, but not my latest from the
>most recent text version. In particular, the question: "Does the ability
>to change the re-registration and heartbeat frequencies fall sufficiently
>into those existing guidelines that nothing else needs to be said?” Do
>these really fit into the category of “standard mobility options” as
>contemplated by RFC 5213?

Yes, I do believe these options for indicating the registration/heartbeat
timers do fall under the category of “standard mobility options". Case and
Point, RFC5847 defines an option for carrying “RestartCounter” in a MIPv6
signaling message, which the protocol peer stores and uses that counter.
In this example and as well in the current draft, the information elements
carried in the option are in similar in nature, both are config parameters
and these are elements that have influence on the protocol state machine.

Regards
Sri

---

From: Ben Campbell <[email-masked]>
Date: Tue, 16 May 2017 11:52:03 -0400

> On May 16, 2017, at 2:01 AM, Sri Gundavelli (sgundave) <[email-masked]> wrote:
> 
> Hi Ben,
> 
> 
> 

Thanks, that's helpful information. I think a sentence or two to that effect would be useful in the draft. It probably doesn't need as much detail as you gave here. I envision something to the effect of "The options defined in this draft allow the configuration of re-registration and heartbeat frequencies. These security considerations in [RFC5213] apply."

Thanks!

Ben.

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 17 May 2017 01:06:46 +0000

Hi Ben,

On 5/16/17, 8:52 AM, "Ben Campbell" <[email-masked]> wrote:

>> timers do fall under the category of ³standard mobility options". Case
>>and
>> Point, RFC5847 defines an option for carrying ³RestartCounter² in a
>>MIPv6
>Thanks, that's helpful information. I think a sentence or two to that
>effect would be useful in the draft. It probably doesn't need as much
>detail as you gave here. I envision something to the effect of "The
>options defined in this draft allow the configuration of re-registration
>and heartbeat frequencies. These security considerations in [RFC5213]
>apply."

Sure, we will add couple of sentences and resolve this. Thanks for the
review.

Regards
Sri