> On May 16, 2017, at 2:01 AM, Sri Gundavelli (sgundave) <[email protected]> > wrote: > > Hi Ben, > > > >> On 5/15/17, 7:57 AM, "Ben Campbell" <[email protected]> wrote: >> >> >>> On May 14, 2017, at 9:57 PM, Sri Gundavelli (sgundave) >>> <[email protected]> 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. _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
