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

["Sri Gundavelli (sgundave)" <[e-mail]>]

Hi Ben,



On 5/15/17, 7:57 AM, "Ben Campbell" <[e-mail]> wrote:

>
>> On May 14, 2017, at 9:57 PM, Sri Gundavelli (sgundave)
>><[e-mail]> wrote:
>> 
>> Hi Ben,
>> 
>> 
>>> 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.
>> 
>> 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.
>
>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


>
>Ben.
>
>
>> 
>> 
>> Regards
>> Sri
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> On 5/12/17, 3:11 PM, "Ben Campbell" <[e-mail]> wrote:
>> 
>>> 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)
>>>> <[e-mail]> wrote:
>>>> 
>>>> ----------------------------------------------------------------------
>>>> 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.
>>> 
>>> 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.
>>> 
>>> 
>> 
>