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,


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


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