Re: [lmap] AD evaluation: draft-ietf-lmap-information-model-16

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Wed, 08 February 2017 20:42 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: lmap@ietfa.amsl.com
Delivered-To: lmap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDDC9129491 for <lmap@ietfa.amsl.com>; Wed, 8 Feb 2017 12:42:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 trzNTJj7Iq8a for <lmap@ietfa.amsl.com>; Wed, 8 Feb 2017 12:42:06 -0800 (PST)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35F1B12947F for <lmap@ietf.org>; Wed, 8 Feb 2017 12:42:06 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 031EF66D; Wed, 8 Feb 2017 21:42:05 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 8lv4Y0D-japC; Wed, 8 Feb 2017 21:42:02 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 8 Feb 2017 21:42:04 +0100 (CET)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 76475200BE; Wed, 8 Feb 2017 21:42:04 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Fmp7Jf4_i5Xi; Wed, 8 Feb 2017 21:42:03 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E7150200BD; Wed, 8 Feb 2017 21:42:03 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id C2EA93E6D565; Wed, 8 Feb 2017 21:42:07 +0100 (CET)
Date: Wed, 8 Feb 2017 21:42:07 +0100
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Alissa Cooper <alissa@cooperw.in>
Message-ID: <20170208204207.GB99261@elstar.local>
Mail-Followup-To: Alissa Cooper <alissa@cooperw.in>, lmap@ietf.org
References: <20170124160720.GB36955@elstar.local> <31441568-4107-4D08-9D7C-99C6A71F0FE0@cooperw.in> <20170126085354.GA43055@elstar.local> <80A34C5F-7E20-41CF-99DF-2222399CFF07@cooperw.in> <20170131094427.GA59387@elstar.local> <8456A767-C0A1-447D-959C-9E090AB4B50B@cooperw.in> <20170131194757.GA78531@elstar.local> <B05AB715-8270-4F89-92A2-0EB810E07A8C@cooperw.in> <20170208152353.GI98457@elstar.local> <2297A61C-1C13-4C28-AD7E-6C6ABE4CD074@cooperw.in>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: <2297A61C-1C13-4C28-AD7E-6C6ABE4CD074@cooperw.in>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lmap/2zKPOWF2-litqbiNehjlWS9RNHU>
Cc: lmap@ietf.org
Subject: Re: [lmap] AD evaluation: draft-ietf-lmap-information-model-16
X-BeenThere: lmap@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: Large Scale Measurement of Access network Performance <lmap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lmap>, <mailto:lmap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lmap/>
List-Post: <mailto:lmap@ietf.org>
List-Help: <mailto:lmap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lmap>, <mailto:lmap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Feb 2017 20:42:08 -0000

On Wed, Feb 08, 2017 at 02:38:37PM -0500, Alissa Cooper wrote:
> 
> > On Feb 8, 2017, at 10:23 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> > 
> > On Tue, Feb 07, 2017 at 10:26:30AM -0500, Alissa Cooper wrote:
> >> 
> >>> On Jan 31, 2017, at 2:47 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> >>> 
> >>> On Tue, Jan 31, 2017 at 09:15:52AM -0500, Alissa Cooper wrote:
> >>>> 
> >>>>> On Jan 31, 2017, at 4:44 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> >>>>>> 
> >>>>> 
> >>>>> The status reports go to the LMAP controller, so I do not really see
> >>>>> why there is a specific risk since the controller has access to the
> >>>>> device ID anyway.
> >>>> 
> >>>> I still am missing what is the rationale for sending the device ID in the status reports. I thought the agent ID was meant to uniquely identify the MA.
> >>>> 
> >>> 
> >>> So here we go. I propose the following change:
> >>> 
> >>> - The ma-status-agent-id becomes optional.
> >>> - The ma-status-device-id becomes mandatory again.
> >>> 
> >>> Rationale:
> >>> 
> >>> If a device does not yet have an MA-ID, then the device-id must be
> >>> accessible such that the controller can configure an MA-ID.
> >> 
> >> Section 3.1 says:
> >> 
> >> "The MA may be pre-configured with an MA ID, or may use a Device ID in
> >>   the first Controller contact before it is assigned an MA ID.  The
> >>   Device ID may be a MAC address or some other device identifier
> >>   expressed as a URI.  If the MA ID is not provided at this stage then
> >>   it must be provided by the Controller during Configuration.”
> >> 
> >> Why would an MA be sending a status report before configuration?
> >> 
> > 
> > The ma-status-obj models status information, it is not modeling a
> > status report. I think the reason for having the device-id in the
> > status information is that this is the only way to obtain it if it is
> > not configured.
> 
> Ok. But in a setup where the controller doesn’t actually need the device-id (because the agent-id is pre-configured and the controller uses that to uniquely identify the MA), this requires the device-id to be divulged to the controller unnecessarily. That case could be accommodated by making both the agent-id and the device-id optional and specifying that the device-id should be provided if it was not provided in pre-configuration.
> 

I remain unconvinced. We do not have a notion of 'conditionally
optional' in the information model and I do not want to introduce
one.

In the YANG data mode, the device-id is not present because such an id
is covered by other YANG models and those models and we have an access
control model to control access, i.e., access control policies are
detached from the data definitions. I am fine with a statement that
people should be careful about exposing device-ids when this is not
needed in the security considerations but I am against changing the
information model.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>