[Mip6] [issue42] bootstrap-ps: Review comments by Jari Arkko
Basavaraj Patil <tracker-mip6@mip4.org> Fri, 16 September 2005 15:37 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGIH6-0006ZR-LY; Fri, 16 Sep 2005 11:37:16 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGIH5-0006Ya-AL for mip6@megatron.ietf.org; Fri, 16 Sep 2005 11:37:15 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24541 for <mip6@ietf.org>; Fri, 16 Sep 2005 11:37:12 -0400 (EDT)
Received: from av12-2-sn2.hy.skanova.net ([81.228.8.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGIM5-0001K7-5G for mip6@ietf.org; Fri, 16 Sep 2005 11:42:27 -0400
Received: by av12-2-sn2.hy.skanova.net (Postfix, from userid 502) id 9C5B43812A; Fri, 16 Sep 2005 17:36:56 +0200 (CEST)
Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av12-2-sn2.hy.skanova.net (Postfix) with ESMTP id 8792037E73 for <mip6@ietf.org>; Fri, 16 Sep 2005 17:36:56 +0200 (CEST)
Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com [81.224.201.50]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id 756A837E48 for <mip6@ietf.org>; Fri, 16 Sep 2005 17:36:56 +0200 (CEST)
Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=81-224-201-50-no45.tbcn.telia.com) by shiraz.levkowetz.com with esmtp (Exim 4.52) id 1EGIGk-0006rB-TR for mip6@ietf.org; Fri, 16 Sep 2005 17:36:56 +0200
Content-Type: text/plain; charset="utf-8"
To: mip6@ietf.org
From: Basavaraj Patil <tracker-mip6@mip4.org>
Date: Fri, 16 Sep 2005 15:36:53 +0000
MIME-Version: 1.0
Message-Id: <1126885013.25.0.481895830842.issue42@mip4.org>
X-Roundup-Name: Mip6 issue tracker
X-Roundup-Loop: hello
Content-Transfer-Encoding: quoted-printable
X-Helo-Check-Failed: Verification failed for HELO 81-224-201-50-no45.tbcn.telia.com
X-SA-Exim-Connect-IP: 192.168.3.14
X-SA-Exim-Mail-From: roundup-admin@mip4.org
X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on shiraz.levkowetz.com
X-Spam-Status: No, score=-103.8 required=2.5 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST,X_HELO_CHECK_FAILED autolearn=ham version=3.0.4
X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100)
X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com)
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196
Content-Transfer-Encoding: quoted-printable
Subject: [Mip6] [issue42] bootstrap-ps: Review comments by Jari Arkko
X-BeenThere: mip6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Mip6 issue tracker <tracker-mip6@mip4.org>
List-Id: mip6.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mip6>, <mailto:mip6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:mip6@ietf.org>
List-Help: <mailto:mip6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mip6>, <mailto:mip6-request@ietf.org?subject=subscribe>
Sender: mip6-bounces@ietf.org
Errors-To: mip6-bounces@ietf.org
New submission from Basavaraj Patil <basavaraj.patil@nokia.com>: Hi, I have read the latest version of this draft. Some comments below. Overall: This is a well written document, ready to be published. It covers the issues well. Some nits and a few technical issues are noted below, however. Technical: > o A basic assumption in the Mobile IPv6 RFC [RFC3775] is that there > is a trust relationship between the mobile node and MSP. This > trust relationship can be direct, or indirect through, for > instance, an ASP that has a contract with the MSP. This trust > relationship can be used to bootstrap the MN. Actually, in RFC 3775 there's an assumption about a relationship between the mobile node and its home agent. The concept of an MSP is rather defined in the reviewed document. I understand that the concepts are very close, but the distinction may be important, because it implies the difference between operating directly with a home agent vs. through supporting infrastructure such as AAA. Suggest s/and MSP/and its home agent(s)/. Same issue also 9.1. > o Yet another assumption is that some identifier, such as NAI, as > defined in [I-D.ietf-mip6-mn-ident-option-02] or [RFC2794] is > provisioned on the MN which permits the MN to identify itself to > the ASP and ASP. This assumption that may not have to be true if you consider all possible solutions - though its certainly true in the solutions that are being designed right now. (A bare bones bootstrapping scheme would allocate a local home agent via DHCP and generate a limited-lifetime SA using leap-of-faith. This would need to be supported with a return routability check on every home registration.) Also, s/ASP and ASP/ASP and MSP/ ? > 6. Network Access and Mobility services This is a good section, but it appears to make the assumption that current access network and bootstrapping go together. I think we should retain a degree of independence between the mobility and access service, even if we use it for bootstrapping. One aspect of this independence is the ability to get the mobility service from somewhere and keep on using it afterwards. For instance, you probably want to visit your private home network once in a while, and that network runs typically on a bare DSL service that isn't likely to offer a lot of service, let alone mobility on top of it. > 3. Design Goals I liked the goals. > 4. Non-Goals I was involved in the work of the design team in its early phases, and probably agreed with these at the time. However, I've recently started to wonder whether a zero-config model (i.e. no trust relationship at all) would actually be something that we should do as well. Technically, this is possible. Provider input points to the direction of always having a trust relationship, but I have a feeling that we are developing a lot of complicated technology, and the zero-config model would actually allow us to reduce complexity instead, perhaps leading to wider deployement. Editorial > The serving network accesss provider may or may not additionally s/accesss/access/ > legitimate home agent address or boostrapping for the IPsec SAs s/boostrapping/bootstrapping/ > dependent. For instance, the MN may bootstrap everytime it boots, s/everytime/every time/ > relevent IPsec RFCs must be quite strong. Provisioning of keys and s/relevent/relevant/ Maybe also "... we have to place a lot of trust to these security associations: Provisioning of keys ..." --Jari ---------- category: Editorial draft: draft-ietf-mip6-bootstrap-ps messages: 161 nosy: bpatil priority: Should fix status: Pending title: bootstrap-ps: Review comments by Jari Arkko _________________________________________________ Mip6 issue tracker <tracker-mip6@mip4.org> <http://www.mip4.org/issues/tracker/mip6/issue42> _________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6
- [Mip6] [issue42] bootstrap-ps: Review comments by… Basavaraj Patil