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

Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es> Tue, 01 November 2011 23:45 UTC

Return-Path: <cjbc@it.uc3m.es>
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 EE2D51F0C7D for <netext@ietfa.amsl.com>; Tue, 1 Nov 2011 16:45:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.699
X-Spam-Level:
X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
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 FPlFI-Y+wmx7 for <netext@ietfa.amsl.com>; Tue, 1 Nov 2011 16:45:43 -0700 (PDT)
Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id D20BF1F0C55 for <netext@ietf.org>; Tue, 1 Nov 2011 16:45:42 -0700 (PDT)
X-uc3m-safe: yes
Received: from [192.168.1.3] (82.158.121.177.dyn.user.ono.com [82.158.121.177]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id EAD21BFA89B; Wed, 2 Nov 2011 00:45:40 +0100 (CET)
Message-ID: <1320191140.19191.19.camel@acorde.it.uc3m.es>
From: Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es>
To: jouni korhonen <jouni.nospam@gmail.com>
Date: Wed, 02 Nov 2011 00:45:40 +0100
In-Reply-To: <40378106-C231-4FE2-8CC3-5798F5A96841@gmail.com>
References: <1320004272.3313.118.camel@acorde.it.uc3m.es> <40378106-C231-4FE2-8CC3-5798F5A96841@gmail.com>
Organization: Universidad Carlos III de Madrid
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-Paz+pTeZklJ6FFGpa4hv"
X-Mailer: Evolution 3.0.3-2
Mime-Version: 1.0
X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.8.0.1017-18486.002
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
Reply-To: cjbc@it.uc3m.es
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: Tue, 01 Nov 2011 23:45:44 -0000

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
> 

-- 
Carlos Jesús Bernardos Cano  http://www.netcom.it.uc3m.es/
GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67