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

Ben Campbell <ben@nostrum.com> Mon, 15 May 2017 15:02 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8AC129467; Mon, 15 May 2017 08:02:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.881
X-Spam-Level:
X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RehwLwvA2vLj; Mon, 15 May 2017 08:02:15 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C3C6129B8B; Mon, 15 May 2017 07:58:00 -0700 (PDT)
Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v4FEvoYT056475 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 15 May 2017 09:57:51 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63]
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <D53E6302.276F94%sgundave@cisco.com>
Date: Mon, 15 May 2017 09:57:58 -0500
Cc: "Dhananjay Patki (dhpatki)" <dhpatki@cisco.com>, Alexey Melnikov <aamelnikov@fastmail.fm>, Dapeng Liu <max.ldp@alibaba-inc.com>, "dmm-chairs@ietf.org" <dmm-chairs@ietf.org>, The IESG <iesg@ietf.org>, "dmm@ietf.org" <dmm@ietf.org>, Mirja Kühlewind <ietf@kuehlewind.net>, "draft-ietf-dmm-lma-controlled-mag-params@ietf.org" <draft-ietf-dmm-lma-controlled-mag-params@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <90F78EB5-3E57-4D63-A971-CB3B5F66B128@nostrum.com>
References: <149199352865.15645.2318473152126054699.idtracker@ietfa.amsl.com> <7D444A20-2C3B-46FE-BB25-79BE67018A8F@cisco.com> <646D4962-4826-450C-9F85-AFA4576C315A@nostrum.com> <D53E6302.276F94%sgundave@cisco.com>
To: "Sri Gundavelli (sgundave)" <sgundave@cisco.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmm/bYfhNrO9rdWCBkUd8rmF8sfKeBU>
Subject: Re: [DMM] Alexey Melnikov's No Objection on draft-ietf-dmm-lma-controlled-mag-params-04: (with COMMENT)
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 May 2017 15:02:17 -0000

> On May 14, 2017, at 9:57 PM, Sri Gundavelli (sgundave) <sgundave@cisco.com> 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.

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.


> 
> 
> Regards
> Sri
> 
> 
> 
> 
> 
> 
> 
> On 5/12/17, 3:11 PM, "Ben Campbell" <ben@nostrum.com> 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)
>>> <dhpatki@cisco.com> 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.
>> 
>> 
>