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

Ben Campbell <ben@nostrum.com> Fri, 12 May 2017 22:15 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 653E6129451; Fri, 12 May 2017 15:15:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Level:
X-Spam-Status: No, score=-1.88 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, URIBL_BLOCKED=0.001] 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 RVIeoDzSeNky; Fri, 12 May 2017 15:15:21 -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 3B8FA12EC10; Fri, 12 May 2017 15:11:22 -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 v4CMB7fM033115 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 12 May 2017 17:11:07 -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="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <7D444A20-2C3B-46FE-BB25-79BE67018A8F@cisco.com>
Date: Fri, 12 May 2017 17:11:08 -0500
Cc: Mirja Kühlewind <ietf@kuehlewind.net>, Alexey Melnikov <aamelnikov@fastmail.fm>, The IESG <iesg@ietf.org>, "draft-ietf-dmm-lma-controlled-mag-params@ietf.org" <draft-ietf-dmm-lma-controlled-mag-params@ietf.org>, Dapeng Liu <max.ldp@alibaba-inc.com>, "dmm-chairs@ietf.org" <dmm-chairs@ietf.org>, "dmm@ietf.org" <dmm@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <646D4962-4826-450C-9F85-AFA4576C315A@nostrum.com>
References: <149199352865.15645.2318473152126054699.idtracker@ietfa.amsl.com> <7D444A20-2C3B-46FE-BB25-79BE67018A8F@cisco.com>
To: "Dhananjay Patki (dhpatki)" <dhpatki@cisco.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmm/dwYiHeH-nqqlkS7-56OBFU96TFY>
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: Fri, 12 May 2017 22:15:24 -0000

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.