Re: [Lsr] Benjamin Kaduk's No Objection on draft-ietf-ospf-lls-interface-id-08: (with COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Wed, 31 October 2018 01:09 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46B2F130DCB; Tue, 30 Oct 2018 18:09:34 -0700 (PDT)
X-Quarantine-ID: <5mclCw97jGqB>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char 9C hex): Received: ...s kaduk@ATHENA.MIT.EDU)\n\t\234by outgoing.mit[...]
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, 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 5mclCw97jGqB; Tue, 30 Oct 2018 18:09:32 -0700 (PDT)
Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B6091277CC; Tue, 30 Oct 2018 18:09:32 -0700 (PDT)
X-AuditID: 1209190d-e79ff7000000728b-b2-5bd900c90a18
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 96.A5.29323.AC009DB5; Tue, 30 Oct 2018 21:09:30 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.14.7/8.9.2) with ESMTP id w9V19Oth032284; Tue, 30 Oct 2018 21:09:25 -0400
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) �by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id w9V19JqQ014177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 30 Oct 2018 21:09:22 -0400
Date: Tue, 30 Oct 2018 20:09:19 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: "Acee Lindem (acee)" <acee@cisco.com>
Cc: The IESG <iesg@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>, "lsr-chairs@ietf.org" <lsr-chairs@ietf.org>, "draft-ietf-ospf-lls-interface-id@ietf.org" <draft-ietf-ospf-lls-interface-id@ietf.org>, Yingzhen Qu <yingzhen.ietf@gmail.com>, "aretana.ietf@gmail.com" <aretana.ietf@gmail.com>
Message-ID: <20181031010919.GZ45914@kduck.kaduk.org>
References: <154047014077.16281.149253858167058600.idtracker@ietfa.amsl.com> <58B0C6F5-6153-4117-B214-176A9B68189C@cisco.com> <20181030140824.GS45914@kduck.kaduk.org> <3D68100D-578B-416D-A7B7-AAE9DC3E9D40@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <3D68100D-578B-416D-A7B7-AAE9DC3E9D40@cisco.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrEKsWRmVeSWpSXmKPExsUixG6nrnuK4Wa0wd3PUhaT385jtrhxaAOT xbXv99ksZvyZyGyx/upJFosTT1awWtxaf4zZgd1jyu+NrB47Z91l91iy5CdTAHMUl01Kak5m WWqRvl0CV8bb82/ZC36LV5x+cY65gXGbYBcjJ4eEgInEhDenWboYuTiEBNYwSVx7MRHK2cgo sffXN3YI5y6TxPpvK9hAWlgEVCVm79rIDmKzCahINHRfZu5i5OAQEdCU2PIerJlZYD+TxPWj G8DqhQWSJR4tOssEYvMCrZu39zkT1FBGiUs7PrNBJAQlTs58wgJiMwuoS/yZdwlsKLOAtMTy fxwQYXmJ5q2zmUFsTgFbiSn9C8BmigooS+ztO8Q+gVFwFpJJs5BMmoUwaRaSSQsYWVYxyqbk VunmJmbmFKcm6xYnJ+blpRbpGunlZpbopaaUbmIERQWnJO8Oxn93vQ4xCnAwKvHwWqTdiBZi TSwrrsw9xCjJwaQkynv+4/VoIb6k/JTKjMTijPii0pzU4kOMEhzMSiK8UyuAynlTEiurUovy YVLSHCxK4rwTWhZHCwmkJ5akZqemFqQWwWRlODiUJHiX/gdqFCxKTU+tSMvMKUFIM3Fwggzn ARreCFLDW1yQmFucmQ6RP8WoKCXO+xAkIQCSyCjNg+sFJS2J7P01rxjFgV4R5v0EUsUDTHhw 3a+ABjMBDeZiBxtckoiQkmpgXMhzT89RRkvMSE3iS9xk/edGHNG2UhLbGrgkvry8x65reKhK JOTpsVYmx8lRfC8v+69b/v2YT+VO0/i01AL+W1/kHAzYjC/5/Fuyry4/KypaJtd/WTqjbpzO +++qSiWs+9m6JqyOjuqffFB9z/foi9tz5x4sWpGZcXzt80PNG2aXKLhf0LJRYinOSDTUYi4q TgQAJ4I7ljUDAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/UccS4SaqLr9iOqozXDZCFC3ubFU>
Subject: Re: [Lsr] Benjamin Kaduk's No Objection on draft-ietf-ospf-lls-interface-id-08: (with COMMENT)
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 Oct 2018 01:09:34 -0000

On Tue, Oct 30, 2018 at 02:28:12PM +0000, Acee Lindem (acee) wrote:
> Hi Ben,
> 
> On 10/30/18, 10:08 AM, "Benjamin Kaduk" <kaduk@mit.edu> wrote:
> 
>     Hi Acee,
>     
>     On Thu, Oct 25, 2018 at 01:51:42PM +0000, Acee Lindem (acee) wrote:
>     > Hi Ben, 
>     > 
>     > On 10/25/18, 8:22 AM, "Benjamin Kaduk" <kaduk@mit.edu> wrote:
>     > 
>     >     Benjamin Kaduk has entered the following ballot position for
>     >     draft-ietf-ospf-lls-interface-id-08: No Objection
>     >     
>     >     When responding, please keep the subject line intact and reply to all
>     >     email addresses included in the To and CC lines. (Feel free to cut this
>     >     introductory paragraph, however.)
>     >     
>     >     
>     >     Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>     >     for more information about IESG DISCUSS and COMMENT positions.
>     >     
>     >     
>     >     The document, along with other ballot positions, can be found here:
>     >     https://datatracker.ietf.org/doc/draft-ietf-ospf-lls-interface-id/
>     >     
>     >     
>     >     
>     >     ----------------------------------------------------------------------
>     >     COMMENT:
>     >     ----------------------------------------------------------------------
>     >     
>     >     Sending a new type of information to the peer usually involves a privacy
>     >     considerations analysis.  I don't expect there to be anything worrisome
>     >     here, but some text in the document indicating that the analysis has been
>     >     done would be reassuring.
>     > 
>     > Can you suggest some text? I was thinking:
>     
>     I'm not sure that I could -- I don't have confidence that I understand the
>     system well enough to frame something in a complete and correct way.
>     
>     >    Since the scope of the interface ID is limited to the advertising OSPF router 
>     >    uniquely identifying links, there are no privacy concerns associated with its
>     >    advertisement.
>     
>     I wonder if there is a step missing to link these together -- that the
>     links are generally fixed and immobile, or that the scope of distribution
>     is limited to a set of trusted peers, perhaps?
> 
> The point I'm making is that since the interface ID is only unique for the network device, it doesn't provide any clue as to the identity of the device owner or traffic transiting the device. Hence, there are no privacy considerations associated with extension. It is also true that routing peers are trusted but that is a moot point for this extension In the context of privacy. 

Ah, I see; thanks.  How does "The interface ID is locally assigned by the
advertising OSPF router as a uniquifier and need not be unique in any
broader context; it is not expected to contain any information about the
device owner or traffic transiting the device, so there are no privacy
concerns associated with its advertisement." sound?

-Benjamin