Re: [DMM] Mirja Kühlewind's Discuss on draft-ietf-dmm-4283mnids-04: (with DISCUSS)

Charlie Perkins <charles.perkins@earthlink.net> Thu, 16 February 2017 00:08 UTC

Return-Path: <charles.perkins@earthlink.net>
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 153B2129C0A; Wed, 15 Feb 2017 16:08:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.22
X-Spam-Level:
X-Spam-Status: No, score=-2.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=earthlink.net; domainkeys=pass (2048-bit key) header.from=charles.perkins@earthlink.net header.d=earthlink.net
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 KijG5uVnF8wJ; Wed, 15 Feb 2017 16:08:50 -0800 (PST)
Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C23B12997E; Wed, 15 Feb 2017 16:08:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=earthlink.net; s=dk12062016; t=1487203729; bh=TWgJj2iHDWXuU/BlH+PmG2yUxOSTK1fbmFas zHGwQTs=; h=Received:Subject:To:References:Cc:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type: Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; b=AGGjEdI UhIZSGpIM0pfUGRhiYj3mzIJHkUmQf36qYcZvKGJq7JHGMWTMUBO0uKOL2ynUPl9XzY KtvFddwbyv7NDM4ABxk23yUwa6NyYi8kDt4MEicDxAQqGlwcHvE4psUO0FRh38uOv8C hIv+cxGGvZ/loFsQUTuOnO8YfjYvFzsaBEKzAb9Xo2YwCA0YSjquKPYV72ESAKzAhBN +58veBDSZ7xf7yr28oxAVRBtEe/Wn+Q/vWlGRXshLJW+OHTWbkDt+YAJAu3OtHdDuwB yDBFm6mRvObuz1HPzFhSfEDq8Ad9yxGVmBwHYlqHC7p1/GKmwvOdh+Z9NhfAGrLkLvw ==
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=earthlink.net; b=OCu+taZu31qd8DRWetmtkLZgIykeqszA60+z5bvQ4JFc2wLfpj6rMpRaD2wBb9QClQAsLxvjiKXBdI3lcC1TG7E045e2STkyHCU2jzwqeRxkVY+EPwToCSf0Y/Z+vtDks8wzO+o3Uxej4G3z5wWYD4xEKieBjFSb2dd0rNwCi6XpoTusaKapzcbw5J9LjghwBYlkZ8elutHBzcgI+ruNcLYX/rXQdBCddDu/7aZGQmFQh27xUfrkduY55Z70hBRefhdY77PRiZ3Qs2z+gp7INg8WUFZcTN9MbeUmcrqSnFNgZxKsWsVpoconzoUbBsAUD+OPXC6H6B6TwnagaRCdxQ==; h=Received:Subject:To:References:Cc:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP;
Received: from [99.51.72.196] (helo=[192.168.1.82]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from <charles.perkins@earthlink.net>) id 1ce9ch-0006dG-Q0; Wed, 15 Feb 2017 19:08:35 -0500
To: Mirja Kühlewind <ietf@kuehlewind.net>, Suresh Krishnan <suresh.krishnan@ericsson.com>
References: <148674648728.29247.8373715746303934157.idtracker@ietfa.amsl.com> <D8A9FEC1-6A1D-4AA8-BF42-E6FD3157BB70@ericsson.com> <C2C2AFB9-99D5-459A-AAF5-1613ABAF4716@kuehlewind.net> <a3ec3108-65e7-ef5b-59de-981376b8f232@earthlink.net> <6a8360d0-f214-3b41-1529-b767e545793c@kuehlewind.net>
From: Charlie Perkins <charles.perkins@earthlink.net>
Message-ID: <69ea2b13-de60-a8f7-ac48-62280dd93c69@earthlink.net>
Date: Wed, 15 Feb 2017 16:08:28 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <6a8360d0-f214-3b41-1529-b767e545793c@kuehlewind.net>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac7367dccfe1b9c8747516719a905a6a761350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 99.51.72.196
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmm/4JXCXjktxkFisIvMr14auEmGMgo>
Cc: "max.ldp@alibaba-inc.com" <max.ldp@alibaba-inc.com>, "draft-ietf-dmm-4283mnids@ietf.org" <draft-ietf-dmm-4283mnids@ietf.org>, "dmm-chairs@ietf.org" <dmm-chairs@ietf.org>, The IESG <iesg@ietf.org>, "dmm@ietf.org" <dmm@ietf.org>
Subject: Re: [DMM] Mirja Kühlewind's Discuss on draft-ietf-dmm-4283mnids-04: (with DISCUSS)
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.17
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: Thu, 16 Feb 2017 00:08:52 -0000

Hello Mirja,

My previous answer was intended to mean that I would change to MUST.

Would you be willing to suggest some text about the non-leakage? I 
thought that the point of strengthening to MUST was to ensure that 
sensitive identifier information was not leaked.  If there is something 
more to be said, I'll be happy to say it.

Regards,
Charlie P.



On 2/15/2017 4:46 AM, Mirja Kühlewind wrote:
> Hi Charlie,
>
> can you please also answer the question below on SHOULD vs. MUST? Thanks!
>
> Also, does it maybe make sense to then add something in the security 
> section that information should/must not be leaked to other networks?
>
> Thanks!
> Mirja
>
>
> On 13.02.2017 22:06, Charlie Perkins wrote:
>> Hello Mirja and Suresh,
>>
>> I am happy to make the proposed changes as agreed below.
>>
>> Regards,
>> Charlie P.
>>
>>
>> On 2/11/2017 1:00 AM, Mirja Kuehlewind (IETF) wrote:
>>> Hi Suresh,
>>>
>>> sounds all good! I’m happy to quickly resolve my discuss if the 
>>> authors agree!
>>>
>>> Mirja
>>>
>>>
>>>> Am 11.02.2017 um 05:05 schrieb Suresh Krishnan 
>>>> <suresh.krishnan@ericsson.com>:
>>>>
>>>> HI Mirja,
>>>>
>>>>> On Feb 10, 2017, at 12:08 PM, Mirja Kuehlewind 
>>>>> <ietf@kuehlewind.net> wrote:
>>>>>
>>>>> Mirja Kühlewind has entered the following ballot position for
>>>>> draft-ietf-dmm-4283mnids-04: Discuss
>>>>>
>>>>> 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-dmm-4283mnids/
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------- 
>>>>>
>>>>> DISCUSS:
>>>>> ---------------------------------------------------------------------- 
>>>>>
>>>>>
>>>>> I would realy like to see the following changes in the security
>>>>> considerations section:
>>>>> OLD
>>>>> "If used in the MNID extension as defined in this
>>>>>   document, the packet including the MNID extension should be
>>>>> encrypted
>>>>>   so that personal information or trackable identifiers would not be
>>>>>   inadvertently disclosed to passive observers."
>>>>> NEW
>>>>> "If used in the MNID extension as defined in this
>>>>>   document, the packet including the MNID extension SHOULD be
>>>>> encrypted
>>>>>   so that personal information or trackable identifiers would not be
>>>>>   inadvertently disclosed to passive observers.”
>>>> Is this just for changing the "should" to upper case? I think that 
>>>> makes sense.
>>>>
>>>>> Or even better make it a MUST? Is there a reason for only having a
>>>>> SHOULD?
>>>> Authors, any specific reason for this to be a SHOULD?
>>>>
>>>>> as well as the following change:
>>>>> OLD
>>>>> "Moreover, MNIDs containing sensitive identifiers might only be used
>>>>>   for signaling during initial network entry. "
>>>>> NEW
>>>>> "Moreover, MNIDs containing sensitive identifiers MUST only be used
>>>>>   for signaling during initial network entry and MUST NOT be 
>>>>> leaked to
>>>>>   other networks.”
>>>> The statement in OLD: is just a statement of fact that in some 
>>>> networks use temporary identifiers for reattachment and they use 
>>>> long term (and hence sensitive) identifiers only at initial attach. 
>>>> I don’t think it makes sense to change this to 2119 language.
>>>>
>>>> Thanks
>>>> Suresh
>>>>
>>>
>>
>