Re: [IPFIX] Review of draft-irtf-nmrg-location-ipfix-07.txt

Abdelkader Lahmadi <> Thu, 24 November 2016 14:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 098B3129428; Thu, 24 Nov 2016 06:43:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QNmXKqfzsCiU; Thu, 24 Nov 2016 06:43:25 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DD1BB1294E6; Thu, 24 Nov 2016 06:43:24 -0800 (PST)
From: Abdelkader Lahmadi <>
X-IronPort-AV: E=Sophos;i="5.31,543,1473112800"; d="asc'?scan'208";a="201563690"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Nov 2016 15:43:22 +0100
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
Content-Type: multipart/signed; boundary="Apple-Mail=_5F31D5C6-F96D-4491-93BB-22E15365282E"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail 2.5.2
In-Reply-To: <>
Date: Thu, 24 Nov 2016 15:43:22 +0100
Message-Id: <>
References: <> <>
To: Stewart Bryant <>
X-Mailer: Apple Mail (2.1993)
Archived-At: <>
Cc: "" <>, "" <>, "" <>, "" <>
Subject: Re: [IPFIX] Review of draft-irtf-nmrg-location-ipfix-07.txt
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IPFIX WG discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 24 Nov 2016 14:43:28 -0000

Thank you for the feedback. please see comments inline, I hope that they help make things clear.
> On 23 Nov 2016, at 12:02, Stewart Bryant <> wrote:
> Collecting this data is not particularly difficult, but protecting the privacy is much harder and will, I imagine be subject to significant scrutiny as the draft progresses.

The core subject of the draft is far from providing solutions of privacy issues when collecting sensitive data. We have clearly mentioned the privacy issue in our draft in section ’Security and Privacy Considerations’. In the section we have referenced existing RFCs that have addressed this issue for location information : [RFC3694], [RFC3693] and also Flow record anonymization [RFC6235].

> It seems to me that there are security and privacy issues concerning both the traffic and the collector itself. The privacy of the user is a widely understood concept and will I am sure be thoroughly examined in review. In the case of the collector I am not convinced that it is wise to reveal the precise location of the network infrastructure since this could result in it being subject to physical attack.

In my opinion, we can also imagine another scenario where location information will help operators to identify that their equipments have not be moved or stolen, so associating IP flows to the location of the device is helpful in this case.

> An approach that you do not seem to explore is encrypting the location record so that this can only be understood by those that are authorised to see it.

We have mentioned in the section ’Security and privacy Consideration’ that location information SHOULD be signed and encrypted as specified in [RFC7011].

> Indeed there is a case for something analogous to the selective availability system in GPS whereby the location is provided with different degrees of precision depending on the authority of the user.
In section ‘Enabling Location Extensions’, we have mentioned that the metering process selects a location method when many are available with different degrees of precision. Yes, we can make it more clear by also mentioning that the selection depends on the authority of the user.
Best regards,

> - Stewart
> On 23/11/2016 02:33, Zhoutianran wrote:
>> Hi,
>> Though IPFIX is concluded, could the IPFIX experts in this mailing list please help to provide comments for this I-D?
>> It seems this work has a long history. Your help will push this work a step forward.
>> Thanks,
>> Tianran
>> _______________________________________________
>> IPFIX mailing list
> _______________________________________________
> IPFIX mailing list