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

[Ben Campbell <[e-mail]>]

> On May 16, 2017, at 2:01 AM, Sri Gundavelli (sgundave) <[e-mail]> wrote:
> 
> 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.

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.