Re: [IPFIX] Review of draft-irtf-nmrg-location-ipfix-07.txt
Stewart Bryant <stewart.bryant@gmail.com> Thu, 24 November 2016 15:36 UTC
Return-Path: <stewart.bryant@gmail.com>
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCD2D1297E8; Thu, 24 Nov 2016 07:36:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 cgKqeFwN3_rt; Thu, 24 Nov 2016 07:36:09 -0800 (PST)
Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 A2D651297DE; Thu, 24 Nov 2016 07:36:08 -0800 (PST)
Received: by mail-wm0-x22f.google.com with SMTP id a197so118215408wmd.0; Thu, 24 Nov 2016 07:36:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=0mVfJAJ3NBLmc3lDiRtO9tARF206Pm8VDbF48XL0Vsc=; b=GRfN7renpOJFCjOh6YsjKsmm/v5djc7g0GpcqCFzTh2n3jasdlZmXIeZUtn/tdJ0uJ rX04DLJfKghgCrhweqVmmgUbWnuAf24rMrs9EZp0l7xsbAMMNBuaLUIlHPRlyAPerbrD P2tQQpSHyiehHrIs99TU3Cr35ed+VQeS1NrQC8penARXpZSiQEqSkOiKGCO6U3GLPEqI HLWPfuU9E/I7CuaCb0PH6rwB0elLKx3bk+h47d1iu6bOR2EQraIASutTNMDkHKQq/v2f Ae3z720PbS9BA2T/f3/djMs4bTbOGSnWkufNE+LBWUX8GrzBp7HGTU5hYu4KCZX7i74A lqxA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=0mVfJAJ3NBLmc3lDiRtO9tARF206Pm8VDbF48XL0Vsc=; b=IUAFvFVOMY08VDqAcQ5rNPOgLR/pkPAVe1S2pGTsuEfc5NkFC2/gHSC1sPsAcCIff3 yISMUQuJRwNc++gRA1G6IGCMzPapU9akQuLdj+g7pz4plv9eqGcZheGJ9wewVTuNdAuX MmwrtJONhJUOJkP5Wgp8aaRQS4AcHWneCXllpBLVbbzDsnioOJ6bDtz22pmzB2cRpwXc YyYECSYmLfgi5vcEG4UM6OZk7+iYgkegDofHz6IVKOgT4o8J7CbZalJNav2cyLvKL1g+ n532hIxOsRQo8dwlXi6elFlYG03WMmNsDqmNjAD7sGTI1mipDly8WORSNBS1B2Gh6Ovq B2Tw==
X-Gm-Message-State: AKaTC00HITGJ0GBiKuTZSmTUtsnOR5ZdXddw+uRQqTymeKtnRLbwM2YBL1D5FVMIPOyl9A==
X-Received: by 10.28.161.67 with SMTP id k64mr3087976wme.69.1480001767121; Thu, 24 Nov 2016 07:36:07 -0800 (PST)
Received: from [192.168.2.131] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id t84sm8780131wmt.7.2016.11.24.07.36.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 24 Nov 2016 07:36:06 -0800 (PST)
To: Abdelkader Lahmadi <abdelkader.lahmadi@loria.fr>
References: <BBA82579FD347748BEADC4C445EA0F21A2260FE9@NKGEML515-MBX.china.huawei.com> <318bf874-2700-640e-e0c1-0ea7953b448f@gmail.com> <64CC7F98-8868-4BE5-ABE3-F6F01BF2FFF6@loria.fr>
From: Stewart Bryant <stewart.bryant@gmail.com>
Message-ID: <cbc29c8a-5e11-7918-0afe-dfebafe0cd2c@gmail.com>
Date: Thu, 24 Nov 2016 15:36:04 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0
MIME-Version: 1.0
In-Reply-To: <64CC7F98-8868-4BE5-ABE3-F6F01BF2FFF6@loria.fr>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipfix/4YRr0aLebwz8mlWXo1wwCfLDuF8>
Cc: "draft-irtf-nmrg-location-ipfix.authors@ietf.org" <draft-irtf-nmrg-location-ipfix.authors@ietf.org>, "opsawg-chairs@ietf.org" <opsawg-chairs@ietf.org>, "IPFIX@ietf.org" <IPFIX@ietf.org>, "nmrg-chairs@ietf.org" <nmrg-chairs@ietf.org>
Subject: Re: [IPFIX] Review of draft-irtf-nmrg-location-ipfix-07.txt
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IPFIX WG discussion list <ipfix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipfix>, <mailto:ipfix-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipfix/>
List-Post: <mailto:ipfix@ietf.org>
List-Help: <mailto:ipfix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Nov 2016 15:36:11 -0000
On 24/11/2016 14:43, Abdelkader Lahmadi wrote: > Hi, > 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 <stewart.bryant@gmail.com> 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]. I guess we will see what happens during the review process. >> 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. If you just want to know where the kit is, I am sure there are better way that than put it in IPFIX records. I am however wary of providing such detailed information on where an equipment is other than on a need to know basis. We live in very turbulent times and physical security is just as important as information security. > >> 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]. That text does not go beyond saying use industry best practice. > >> 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, Maybe. My point was that different users of the information have a right to different degrees of precision. So for example whilst many people might be satisfied with "London", and others might need to know "Westminister", few would need to know "in the top right draw of the Prime Minister's desk", but you can imagine why some people might be worried. My example is of course fanciful, but serves to illustrate that we need to be very sensitive to need-to-know when it comes to precision location of infrastructure, and the operator of the metering process may not fully appreciate the sensitivity. - Stewart > > >> - 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? >>> https://datatracker.ietf.org/doc/draft-irtf-nmrg-location-ipfix >>> >>> It seems this work has a long history. Your help will push this work a step forward. >>> >>> >>> Thanks, >>> Tianran >>> >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix
- [IPFIX] Review of draft-irtf-nmrg-location-ipfix-… Zhoutianran
- Re: [IPFIX] Review of draft-irtf-nmrg-location-ip… Stewart Bryant
- Re: [IPFIX] Review of draft-irtf-nmrg-location-ip… Abdelkader Lahmadi
- Re: [IPFIX] Review of draft-irtf-nmrg-location-ip… Stewart Bryant
- Re: [IPFIX] Review of draft-irtf-nmrg-location-ip… PJ Aitken
- Re: [IPFIX] Review of draft-irtf-nmrg-location-ip… Abdelkader Lahmadi
- Re: [IPFIX] Review of draft-irtf-nmrg-location-ip… PJ Aitken
- Re: [IPFIX] Review of draft-irtf-nmrg-location-ip… Abdelkader Lahmadi
- Re: [IPFIX] Review of draft-irtf-nmrg-location-ip… PJ Aitken
- Re: [IPFIX] Review of draft-irtf-nmrg-location-ip… Eggert, Lars
- Re: [IPFIX] Review of draft-irtf-nmrg-location-ip… Abdelkader Lahmadi
- Re: [IPFIX] Review of draft-irtf-nmrg-location-ip… Abdelkader Lahmadi
- Re: [IPFIX] Review of draft-irtf-nmrg-location-ip… Eggert, Lars
- Re: [IPFIX] Review of draft-irtf-nmrg-location-ip… Abdelkader Lahmadi
- Re: [IPFIX] [irsg] Review of draft-irtf-nmrg-loca… Eggert, Lars