[Mobopts] Fwd: RG Last Call for Media-independent Pre-Authentication Document
"Rajeev Koodli" <rajeev.koodli@gmail.com> Wed, 04 June 2008 18:33 UTC
Return-Path: <mobopts-bounces@ietf.org>
X-Original-To: mobopts-archive@megatron.ietf.org
Delivered-To: ietfarch-mobopts-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A26E93A6CFF; Wed, 4 Jun 2008 11:33:24 -0700 (PDT)
X-Original-To: mobopts@core3.amsl.com
Delivered-To: mobopts@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E91E43A6CFA for <mobopts@core3.amsl.com>; Wed, 4 Jun 2008 11:33:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J1A-MqWNlQJ1 for <mobopts@core3.amsl.com>; Wed, 4 Jun 2008 11:33:19 -0700 (PDT)
Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by core3.amsl.com (Postfix) with ESMTP id D79F83A6CFB for <mobopts@irtf.org>; Wed, 4 Jun 2008 11:33:19 -0700 (PDT)
Received: by wf-out-1314.google.com with SMTP id 24so160208wfg.7 for <mobopts@irtf.org>; Wed, 04 Jun 2008 11:33:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=l4wPQAr7G/2RUW/5EnsobdgN7bhY5RSUW/SzyVonltg=; b=L165GC9iFHQz3Ln2lLVw3bLcoXhQ00GGcdbnGYcLw6iaOTUaqiWW+2F//8PkpLKXx4 ZXdt35H4sD0xxv2Lh8pBMjLAlBzGVhg5WHYxtKF49upDLJoVdcRFuyNguWaRjXmc884X R+3uC2kNvZIcRKHylK4UNY/6JO2NGWxRxzbkg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=rkrQ2YfB0Ma9KsQDuL9F7mNlI+z/2/9Q9p9Y5FTeDNeNk9bR+NGAKS6BowAw3N18xY /6NiBT0RlTEihBS6m1TpwgvTtDCl4/eMVe8XTOp25MbKDRN/B3pRPOo2ZsE/thBL4R+B WIuFDZNp2gP1PGiTQHn26a8jN+ZJVz251f3l4=
Received: by 10.143.33.12 with SMTP id l12mr93992wfj.272.1212604404250; Wed, 04 Jun 2008 11:33:24 -0700 (PDT)
Received: by 10.142.166.13 with HTTP; Wed, 4 Jun 2008 11:33:24 -0700 (PDT)
Message-ID: <3d57679a0806041133w671823cqee16d3294b87c768@mail.gmail.com>
Date: Wed, 04 Jun 2008 11:33:24 -0700
From: Rajeev Koodli <rajeev.koodli@gmail.com>
To: "mobopts@irtf.org" <mobopts@irtf.org>
In-Reply-To: <13E2E485D9AA7240A1C55B0B464198B201E46202@ct11exm63.ds.mot.com>
MIME-Version: 1.0
Content-Disposition: inline
References: <4D35478224365146822AE9E3AD4A266602706812@exchtewks3.starentnetworks.com> <3d57679a0805161455l60264f1as95047174ebd0b0ed@mail.gmail.com> <13E2E485D9AA7240A1C55B0B464198B201DF500C@ct11exm63.ds.mot.com> <3d57679a0805221945r4d43416bwbf560b46ecc41749@mail.gmail.com> <3d57679a0805291124p2bb61609je8b3a3a89428e907@mail.gmail.com> <13E2E485D9AA7240A1C55B0B464198B201E46202@ct11exm63.ds.mot.com>
Cc: Nakhjiri Madjid-VXT746 <Madjid.Nakhjiri@motorola.com>
Subject: [Mobopts] Fwd: RG Last Call for Media-independent Pre-Authentication Document
X-BeenThere: mobopts@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobility Optimizations <mobopts.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mobopts>, <mailto:mobopts-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/mobopts>
List-Post: <mailto:mobopts@ietf.org>
List-Help: <mailto:mobopts-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mobopts>, <mailto:mobopts-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: mobopts-bounces@ietf.org
Errors-To: mobopts-bounces@ietf.org
A Review. Thanks Madjid. ---------- Forwarded message ---------- From: Nakhjiri Madjid-VXT746 <madjid.nakhjiri@motorola.com> Date: Thu, May 29, 2008 at 5:24 PM Subject: RE: [Mobopts] RG Last Call for Media-independent Pre-Authentication Document To: Rajeev Koodli <rajeev.koodli@gmail.com> Cc: Nakhjiri Madjid-VXT746 <madjid.nakhjiri@motorola.com> ........................... I unfortunately think the doc has too much background material and abstraction that takes the user through a lot of text (15 pages) before it introduces any of its framework concepts and that makes reviewing very tough if you are time constraint, sorry I think one of the strong points that any doc about Pre-auth needs to make is that many of the procedures such as handover keying and reauthentication deal with cases where there is a single source of trust at the top and all underlying AAA domains trust that top source of trust and any keys it generates and distributes. In cases of multiple operators without roaming relationship, or without agreement to participate in a key management scheme, you do have to perform a pre-auth function to establish the security mechanisms without assuming a common source of trust. the first paragraph of the intro can be toned down a bit with respect to ordering of the challenges. Is this expects to solve the seamless mobility problem even when there is a single L2 interface? (intro) As much as this being a noble goal, I think with the advances in Silicon and wireless devices, this is overcomplication of the requirements. I do agree that the multi-interface assumption has been one of the barriers for 802.21 though. I am wondering how a mobile performs pre-auth with an authentication agent of a new access technology, while still connected to the old one if it is single interface, also not clear how the mobile acquires the IP address of this agent, as section 6.3 states if it is not tuned to the new technology, sorry if I have not gone to end of the document and not being far. Third, a mobility optimization mechanism needs to support not only multi-interface terminals where multiple simultaneous connectivity through multiple interfaces can be expected, but also single-interface terminals. section 1.1. I am not sure if the document needs to go into a serial analysis of every source of delay in the system. Since this is about pre-auth and IP address acquisition, etc, it could simply just talk about those things. so section 1.1 can undergo a serious diet. A QoS style description of delay would not be needed either, IMO. On the other hand, what that section really is missing is a description of issues around reestablishing link security (authentication, link key management, access authorization) in conjunction to network access and handovers (inter or intra domain), because that is really the focus of a pre-auth framework. section 2 This type of Inter-technology handover is often called as Vertical Handover since the mobile makes movement between two different cell sizes. I don't think Vertical handover is defined based on cell size, it is defined based on the type of access technology (as listed). I think an important point about Inter-domain, is not just where the mobile is authenticated, but also where his user profile, credentials are stored and where his payment is associated to. Because that will define the difference between home and visited domains from the security standpoint, the mobile has an initial and permanent trust relationship with its home and any interaction with a visited domain is based on a temporary and transitive trust established based on a mobile-home trust and a home-visited domain roaming relationship. I know it is a sticky subject, but probably AA (authentication agent) needs to provide some IETF or other wireless examples (EAP authenticator, ASN GW, etc) and also how the Authentication signaling is to traverse over the new network if there is only one interface. The parts with pre-configuration are ok from 802.21 perspective, however I don't think this doc or framework should get into decisions of which network to use is a network discover issue that assumes a general broadcasting broker (I think 802.21 calls it information server). Decision regarding which candidate network the mobile needs to pre-authenticate with will depend upon several policies, such as signaling overhead, bandwidth requirement (QoS), mobile's location, communication cost, and handover robustness etc. This just makes the framework for this protocol too large, and academic, specially if things like specific server (that nobody would take ownership of in a inter-domain scenario) come in. ....................... _______________________________________________ Mobopts mailing list Mobopts@ietf.org https://www.ietf.org/mailman/listinfo/mobopts
- [Mobopts] RG Last Call for Media-independent Pre-… Koodli, Rajeev
- [Mobopts] Fwd: RG Last Call for Media-independent… Rajeev Koodli
- [Mobopts] Revised version of Media Independent Pr… Ashutosh Dutta