Re: [netext] Review of draft-ietf-netext-access-network-option-00

jouni korhonen <jouni.nospam@gmail.com> Wed, 02 November 2011 09:46 UTC

Return-Path: <jouni.nospam@gmail.com>
X-Original-To: netext@ietfa.amsl.com
Delivered-To: netext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4F7A1F0CA2 for <netext@ietfa.amsl.com>; Wed, 2 Nov 2011 02:46:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.239
X-Spam-Level:
X-Spam-Status: No, score=-3.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id We4fgbupgCRb for <netext@ietfa.amsl.com>; Wed, 2 Nov 2011 02:46:35 -0700 (PDT)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5E68C11E80D9 for <netext@ietf.org>; Wed, 2 Nov 2011 02:46:27 -0700 (PDT)
Received: by eyg24 with SMTP id 24so7523645eyg.31 for <netext@ietf.org>; Wed, 02 Nov 2011 02:46:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=qK79M7K8J9i63o3sspLyOTigJXIdnVzhNqt8WoOfvlI=; b=o0zZh5Ni6NEal7aNWYnvSLuZtS5tQEQ3tHjla7vldaKUdZYm3afDse93EB23GxC8vJ 1UkGhNCtsKfPdN7S3ByIizIHv2SC19uF+NHjB1xDZHLD2mgIL+xieK9BP/ItPSxvH59b DiXo66MF9PKk3u8mmVudPvvdJx0Iyj/F+eTEY=
Received: by 10.213.2.75 with SMTP id 11mr1629031ebi.25.1320227186501; Wed, 02 Nov 2011 02:46:26 -0700 (PDT)
Received: from dhcp-27-53.ripemtg.ripe.net (dhcp-27-53.ripemtg.ripe.net. [193.0.27.53]) by mx.google.com with ESMTPS id q28sm4965129eea.6.2011.11.02.02.46.23 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 02 Nov 2011 02:46:25 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: jouni korhonen <jouni.nospam@gmail.com>
In-Reply-To: <4EB10549.805@gmail.com>
Date: Wed, 2 Nov 2011 11:46:16 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <8FED80E1-F25F-4079-812C-1921FD3F4746@gmail.com>
References: <1320004272.3313.118.camel@acorde.it.uc3m.es> <40378106-C231-4FE2-8CC3-5798F5A96841@gmail.com> <1320191140.19191.19.camel@acorde.it.uc3m.es> <4EB10549.805@gmail.com>
To: Jong-Hyouk Lee <hurryon@gmail.com>
X-Mailer: Apple Mail (2.1084)
Cc: netext@ietf.org
Subject: Re: [netext] Review of draft-ietf-netext-access-network-option-00
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:netext@ietf.org>
List-Help: <mailto:netext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Nov 2011 09:46:36 -0000

Hi,

On Nov 2, 2011, at 10:54 AM, Jong-Hyouk Lee wrote:

> Dear all.
> 
> Regarding location privacy, I agree with Carlos. As I mentioned it before and Carlos also noticed, it should be mentioned at least at the security consideration section at the document.

Ok. Thou shalt be done.

- JOuni

> 
> Thanks.
> 
> On Wed 02 Nov 2011 12:45:40 AM CET, Carlos Jesús Bernardos Cano wrote:
>> 
>> Hi Jouni,
>> 
>> Thanks for your comments. Some additional ones from my side below.
>> 
>> On Tue, 2011-11-01 at 15:29 +0200, jouni korhonen wrote:
>>> 
>>> Carlos,
>>> 
>>> Thanks for the review. See some responses inline.
>>> 
>>> On Oct 30, 2011, at 9:51 PM, Carlos Jesús Bernardos Cano wrote:
>>> 
>>>> 
>>>> Hi all,
>>>> 
>>>> I've read draft-ietf-netext-access-network-option-00 and I have some
>>>> comments:
>>>> 
>>>> - I think the document is OK in general.
>>>> - The normative text of Section 3 needs to be revised. For example,
>>>> there are lots of normative words in lowercase.
>>> 
>>> 
>>> Ok.
>>> 
>>>> 
>>>> - Can a PBU carry more than one ANI option? It is not clearly mentioned,
>>>> though Figure 1 may indicate it is possible (as there is both BSSID and
>>>> Geo-Loc shown as part of the identification of the access network.
>>> 
>>> 
>>> There can be one ANI option.. as you can access only one operator network at once.
>>> 
>>> The option structure is still in flux so it is likely to change a bit in the future. For example there might be cases where multiple network identifiers are useful (e.g. SSID accompanied with geo-location etc).
>> 
>> 
>> This is exactly what I was referring to. In the current draft, it seems
>> that multiple network identifiers can be conveyed, but this seems not
>> possible to be done with a single ANI option (as currently defined).
>> 
>>> 
>>> 
>>>> 
>>>> - Figure 3 is not referred in the document.
>>>> - I think there should be text dealing with the case in which an LMA not
>>>> supporting/understanding the ANI option receives a PBU carrying one.
>>> 
>>> 
>>> Ok. You mean a simple capability confirmation like echoing the ANI option back in the PBA? Or something else?
>> 
>> 
>> Well, just some text explaining what an LMA will do in that case. Maybe
>> just ignore the ANI option, but this needs to be mentioned in the draft,
>> IMHO.
>> 
>>> 
>>> 
>>>> 
>>>> - It seems that included Nw-ID types are 802.11 related. Is there no
>>>> other case (e.g., 3GPP related) worth including?
>>> 
>>> 
>>> This is the initial set. If you have additional Nw-IDs to propose with a good use case, go ahead :)
>> 
>> 
>> OK, I'll try that exercise :)
>> 
>>> 
>>> 
>>>> 
>>>> - Does the ANI option introduce privacy issues? In case an attacker was
>>>> able to overhear PBUs, it could be able to know where a particular MN is
>>>> geographically located. Not sure this is a realistic concern in a real
>>>> deployment, but authors might want to mention that IPsec encryption
>>>> could be used to mitigate this problem.
>>> 
>>> 
>>> I think we do not need to go beyond existing RFC5213 security.. Even MN-ID option introduces a privacy issue more or less.
>> 
>> 
>> Well, I'm not an expert but I think this deserves at least a second
>> look. Jong-Hyouk also expressed some concerns about this. At least, I
>> think this should be mentioned on the Security Considerations section,
>> IMHO.
>> 
>> Thanks,
>> 
>> Carlos
>> 
>>> 
>>> 
>>> - Jouni
>>> 
>>> 
>>> 
>>>> 
>>>> 
>>>> Thanks,
>>>> 
>>>> Carlos
>>>> 
>>>> -- 
>>>> Carlos Jesús Bernardos Cano http://www.netcom.it.uc3m.es/
>>>> GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67
>>>> _______________________________________________
>>>> netext mailing list
>>>> netext@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netext
>>> 
>>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> netext mailing list
>> netext@ietf.org
>> https://www.ietf.org/mailman/listinfo/netext
>> -- 
>> IMARA Team, INRIA, France
>> Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random
>> 
>> #email: hurryon (at) gmail.com || jong-hyouk.lee (at) inria.fr
>> #webpage: http://sites.google.com/site/hurryon/