From mailman-admin@ietf.org Wed Jan 1 11:02:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08459 for ; Wed, 1 Jan 2003 11:02:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h01GAAJ14632 for ; Wed, 1 Jan 2003 11:10:10 -0500 Date: Wed, 01 Jan 2003 11:10:10 -0500 Message-ID: <20030101161010.32165.62588.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: seamoby-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, seamoby-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for seamoby-archive@lists.ietf.org: List Password // URL ---- -------- seamoby@ietf.org Zzch https://www1.ietf.org/mailman/options/seamoby/seamoby-archive%40lists.ietf.org From seamoby-admin@ietf.org Sun Jan 5 17:46:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11722 for ; Sun, 5 Jan 2003 17:46:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h05MtRJ25273; Sun, 5 Jan 2003 17:55:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h05MrJJ25209 for ; Sun, 5 Jan 2003 17:53:19 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11668 for ; Sun, 5 Jan 2003 17:42:51 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h05MkK811883 for ; Sun, 5 Jan 2003 16:46:20 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Sun, 5 Jan 2003 16:46:04 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 5 Jan 2003 16:45:53 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sun, 5 Jan 2003 17:45:52 -0500 Message-ID: Thread-Topic: [Seamoby] CARD - FMIPv6 protocol interworking Thread-Index: AcKoT0ZdXsyHiZM7R8ysV301KTlYUAMvXrtQ To: X-OriginalArrivalTime: 05 Jan 2003 22:45:53.0150 (UTC) FILETIME=[33B489E0:01C2B50C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h05MrJJ25210 Subject: [Seamoby] CARD feeding TAR selection issue Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi all: In order to proceed with next version of CARD draft, the design team would like to seek WG consensus on the following way of CARD operation, so that it can be used for TAR selection. TAR selection is defined as selecting a unique AR for handoff from a set of CARs. For this, TAR selection module needs access to CAR identities and their capabilities. TAR selection module resides in the MN. Base protocol: -------------- Step 1: MN collects the identities of CARs (after listening to AP beacons from them) and their capabilities using CARD protocol. For this, MN queries either current AR or new AR (depending upon whether is it doing CARD in MN orchestrated or network assisted mode) and receives this information. For a given CAR, its entire capability set is provided to MN. Step 2: MN runs TAR selection algorithm to choose TAR at the time of handoff. Optional optimizations to the base protocol: -------------------------------------------- Capability pre-filtering: Step 1A: To avoid sending whole capability set of any CAR to MN, especially if MN is not interested in all those capabilities, in the CARD query MN can specify the capabilities that it is interested in receiving (by specifying capability attributes). Step 1B: Even when capabilities of interest are specified by MN in query, to avoid sending information on CARs that MN is not obviously going to like, MN can also specify in the query to send CAR information if the capability of interest is above a threshold (attribute being greater than some value). Network policies: Network policies (in network assisted CARD) can be implemented indirectly by current AR. In other words, current AR may not send information about certain CARs to MN, if network policy in unfavorable to those CARs. In an extreme case, if network sends to MN information about only one CAR, it is tantamount to performing TAR selection on current AR. Please provide your feedback on this. Thanks, Hemant _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Sun Jan 5 17:46:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11739 for ; Sun, 5 Jan 2003 17:46:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h05Mum425322 for seamoby-archive@odin.ietf.org; Sun, 5 Jan 2003 17:56:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h05MumJ25319 for ; Sun, 5 Jan 2003 17:56:48 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11725 for ; Sun, 5 Jan 2003 17:46:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h05MtRJ25273; Sun, 5 Jan 2003 17:55:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h05MrJJ25209 for ; Sun, 5 Jan 2003 17:53:19 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11668 for ; Sun, 5 Jan 2003 17:42:51 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h05MkK811883 for ; Sun, 5 Jan 2003 16:46:20 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Sun, 5 Jan 2003 16:46:04 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 5 Jan 2003 16:45:53 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sun, 5 Jan 2003 17:45:52 -0500 Message-ID: Thread-Topic: [Seamoby] CARD - FMIPv6 protocol interworking Thread-Index: AcKoT0ZdXsyHiZM7R8ysV301KTlYUAMvXrtQ To: X-OriginalArrivalTime: 05 Jan 2003 22:45:53.0150 (UTC) FILETIME=[33B489E0:01C2B50C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h05MrJJ25210 Subject: [Seamoby] CARD feeding TAR selection issue Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi all: In order to proceed with next version of CARD draft, the design team would like to seek WG consensus on the following way of CARD operation, so that it can be used for TAR selection. TAR selection is defined as selecting a unique AR for handoff from a set of CARs. For this, TAR selection module needs access to CAR identities and their capabilities. TAR selection module resides in the MN. Base protocol: -------------- Step 1: MN collects the identities of CARs (after listening to AP beacons from them) and their capabilities using CARD protocol. For this, MN queries either current AR or new AR (depending upon whether is it doing CARD in MN orchestrated or network assisted mode) and receives this information. For a given CAR, its entire capability set is provided to MN. Step 2: MN runs TAR selection algorithm to choose TAR at the time of handoff. Optional optimizations to the base protocol: -------------------------------------------- Capability pre-filtering: Step 1A: To avoid sending whole capability set of any CAR to MN, especially if MN is not interested in all those capabilities, in the CARD query MN can specify the capabilities that it is interested in receiving (by specifying capability attributes). Step 1B: Even when capabilities of interest are specified by MN in query, to avoid sending information on CARs that MN is not obviously going to like, MN can also specify in the query to send CAR information if the capability of interest is above a threshold (attribute being greater than some value). Network policies: Network policies (in network assisted CARD) can be implemented indirectly by current AR. In other words, current AR may not send information about certain CARs to MN, if network policy in unfavorable to those CARs. In an extreme case, if network sends to MN information about only one CAR, it is tantamount to performing TAR selection on current AR. Please provide your feedback on this. Thanks, Hemant _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Jan 5 19:13:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12433 for ; Sun, 5 Jan 2003 19:13:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h060MIJ28995; Sun, 5 Jan 2003 19:22:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h060LdJ28965 for ; Sun, 5 Jan 2003 19:21:39 -0500 Received: from ns.sait.samsung.co.kr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12408 for ; Sun, 5 Jan 2003 19:11:09 -0500 (EST) Received: from bright (localhost [127.0.0.1]) by ns.sait.samsung.co.kr (8.12.1/8.12.1) with SMTP id h060EHHS025355; Mon, 6 Jan 2003 09:14:18 +0900 (KST) Message-ID: <002b01c2b518$7ff5e860$9429024b@bright> From: "Xiaoming Wang" To: , References: Subject: Re: [Seamoby] CARD feeding TAR selection issue Date: Mon, 6 Jan 2003 09:13:53 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Network policies: > > Network policies (in network assisted CARD) can be implemented indirectly by current AR. In other words, current AR may not send information about certain CARs to MN, if network policy in unfavorable to those CARs. In an extreme case, if network sends to MN information about only one CAR, it is tantamount to performing TAR selection on current AR. > This optimization doesn't work when MN queries new ARs directly. Therefore these policies should not be depended on by current AR in order to filter unfavorable CARs. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Sun Jan 5 19:13:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12450 for ; Sun, 5 Jan 2003 19:13:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h060Nds29087 for seamoby-archive@odin.ietf.org; Sun, 5 Jan 2003 19:23:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h060NdJ29084 for ; Sun, 5 Jan 2003 19:23:39 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12437 for ; Sun, 5 Jan 2003 19:13:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h060MIJ28995; Sun, 5 Jan 2003 19:22:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h060LdJ28965 for ; Sun, 5 Jan 2003 19:21:39 -0500 Received: from ns.sait.samsung.co.kr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12408 for ; Sun, 5 Jan 2003 19:11:09 -0500 (EST) Received: from bright (localhost [127.0.0.1]) by ns.sait.samsung.co.kr (8.12.1/8.12.1) with SMTP id h060EHHS025355; Mon, 6 Jan 2003 09:14:18 +0900 (KST) Message-ID: <002b01c2b518$7ff5e860$9429024b@bright> From: "Xiaoming Wang" To: , References: Subject: Re: [Seamoby] CARD feeding TAR selection issue Date: Mon, 6 Jan 2003 09:13:53 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Network policies: > > Network policies (in network assisted CARD) can be implemented indirectly by current AR. In other words, current AR may not send information about certain CARs to MN, if network policy in unfavorable to those CARs. In an extreme case, if network sends to MN information about only one CAR, it is tantamount to performing TAR selection on current AR. > This optimization doesn't work when MN queries new ARs directly. Therefore these policies should not be depended on by current AR in order to filter unfavorable CARs. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Jan 5 22:23:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14545 for ; Sun, 5 Jan 2003 22:23:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h063XNJ05701; Sun, 5 Jan 2003 22:33:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h063WLJ05639 for ; Sun, 5 Jan 2003 22:32:21 -0500 Received: from hotmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14517 for ; Sun, 5 Jan 2003 22:21:48 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 5 Jan 2003 19:25:02 -0800 Received: from 66.30.240.206 by lw7fd.law7.hotmail.msn.com with HTTP; Mon, 06 Jan 2003 03:25:01 GMT X-Originating-IP: [66.30.240.206] From: "Hemant Chaskar" To: xmwang@sait.samsung.co.kr, Seamoby@ietf.org Subject: Re: [Seamoby] CARD feeding TAR selection issue Date: Mon, 06 Jan 2003 03:25:01 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 06 Jan 2003 03:25:02.0114 (UTC) FILETIME=[32DDA020:01C2B533] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Hi Xiaoming: If MN can query new AR directly, the question of network policy does not come into picture at all, I guess! If MN can directly communicate with new AR, why should it care if current AR favors it going there or not. Hemant >From: "Xiaoming Wang" >To: , >Subject: Re: [Seamoby] CARD feeding TAR selection issue >Date: Mon, 6 Jan 2003 09:13:53 +0900 > > > Network policies: > > > > Network policies (in network assisted CARD) can be implemented >indirectly >by current AR. In other words, current AR may not send information about >certain CARs to MN, if network policy in unfavorable to those CARs. In an >extreme case, if network sends to MN information about only one CAR, it is >tantamount to performing TAR selection on current AR. > > > >This optimization doesn't work when MN queries new ARs directly. Therefore >these policies should not be depended on by current AR in order to filter >unfavorable CARs. > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Sun Jan 5 22:24:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14575 for ; Sun, 5 Jan 2003 22:24:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h063YTE05749 for seamoby-archive@odin.ietf.org; Sun, 5 Jan 2003 22:34:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h063YTJ05746 for ; Sun, 5 Jan 2003 22:34:29 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14555 for ; Sun, 5 Jan 2003 22:23:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h063XNJ05701; Sun, 5 Jan 2003 22:33:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h063WLJ05639 for ; Sun, 5 Jan 2003 22:32:21 -0500 Received: from hotmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14517 for ; Sun, 5 Jan 2003 22:21:48 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 5 Jan 2003 19:25:02 -0800 Received: from 66.30.240.206 by lw7fd.law7.hotmail.msn.com with HTTP; Mon, 06 Jan 2003 03:25:01 GMT X-Originating-IP: [66.30.240.206] From: "Hemant Chaskar" To: xmwang@sait.samsung.co.kr, Seamoby@ietf.org Subject: Re: [Seamoby] CARD feeding TAR selection issue Date: Mon, 06 Jan 2003 03:25:01 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 06 Jan 2003 03:25:02.0114 (UTC) FILETIME=[32DDA020:01C2B533] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Hi Xiaoming: If MN can query new AR directly, the question of network policy does not come into picture at all, I guess! If MN can directly communicate with new AR, why should it care if current AR favors it going there or not. Hemant >From: "Xiaoming Wang" >To: , >Subject: Re: [Seamoby] CARD feeding TAR selection issue >Date: Mon, 6 Jan 2003 09:13:53 +0900 > > > Network policies: > > > > Network policies (in network assisted CARD) can be implemented >indirectly >by current AR. In other words, current AR may not send information about >certain CARs to MN, if network policy in unfavorable to those CARs. In an >extreme case, if network sends to MN information about only one CAR, it is >tantamount to performing TAR selection on current AR. > > > >This optimization doesn't work when MN queries new ARs directly. Therefore >these policies should not be depended on by current AR in order to filter >unfavorable CARs. > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Jan 6 08:36:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03252 for ; Mon, 6 Jan 2003 08:36:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06DjpJ17526; Mon, 6 Jan 2003 08:45:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06DihJ17487 for ; Mon, 6 Jan 2003 08:44:43 -0500 Received: from bsn-mail-01.bstormnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03177 for ; Mon, 6 Jan 2003 08:33:57 -0500 (EST) Subject: Re: [Seamoby] CARD feeding TAR selection issue From: Pat Calhoun To: Hemant.Chaskar@nokia.com Cc: Seamoby@ietf.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1041773752.2840.6.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 05 Jan 2003 05:36:01 -0800 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Step 1: MN collects the identities of CARs (after listening to AP beacons from them) and their capabilities using CARD protocol. For this, MN queries either current AR or new AR (depending upon whether is it doing CARD in MN orchestrated or network assisted mode) and receives this information. For a given CAR, its entire capability set is provided to MN. There are link layers that do not allow more than one link layer connection at any given time, and although the beacons could be received, as they are on a special channel. In these conditions, how would the mobile receive CARD packets? PatC _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Jan 6 08:36:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03277 for ; Mon, 6 Jan 2003 08:36:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h06DkuY17566 for seamoby-archive@odin.ietf.org; Mon, 6 Jan 2003 08:46:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06DkuJ17563 for ; Mon, 6 Jan 2003 08:46:56 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03255 for ; Mon, 6 Jan 2003 08:36:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06DjpJ17526; Mon, 6 Jan 2003 08:45:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06DihJ17487 for ; Mon, 6 Jan 2003 08:44:43 -0500 Received: from bsn-mail-01.bstormnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03177 for ; Mon, 6 Jan 2003 08:33:57 -0500 (EST) Subject: Re: [Seamoby] CARD feeding TAR selection issue From: Pat Calhoun To: Hemant.Chaskar@nokia.com Cc: Seamoby@ietf.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1041773752.2840.6.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 05 Jan 2003 05:36:01 -0800 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Step 1: MN collects the identities of CARs (after listening to AP beacons from them) and their capabilities using CARD protocol. For this, MN queries either current AR or new AR (depending upon whether is it doing CARD in MN orchestrated or network assisted mode) and receives this information. For a given CAR, its entire capability set is provided to MN. There are link layers that do not allow more than one link layer connection at any given time, and although the beacons could be received, as they are on a special channel. In these conditions, how would the mobile receive CARD packets? PatC _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Jan 6 09:55:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04650 for ; Mon, 6 Jan 2003 09:55:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06F4wJ21913; Mon, 6 Jan 2003 10:04:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06F1lJ21723 for ; Mon, 6 Jan 2003 10:01:47 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04521 for ; Mon, 6 Jan 2003 09:50:59 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h06EsGE05986 for ; Mon, 6 Jan 2003 08:54:16 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 6 Jan 2003 08:54:11 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 6 Jan 2003 08:53:22 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CARD feeding TAR selection issue Date: Mon, 6 Jan 2003 09:53:21 -0500 Message-ID: Thread-Topic: [Seamoby] CARD feeding TAR selection issue Thread-Index: AcK1iPGD/sOHe0h8Sxm8xV+iqIErpAACZoyw To: , Cc: X-OriginalArrivalTime: 06 Jan 2003 14:53:22.0241 (UTC) FILETIME=[5BA8E310:01C2B593] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h06F1lJ21724 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Pat, In the case that you illustrate, the current AR has to be involved.The MN forwards the L2 Id to the current AR. The current AR, then, maps the beacon information to the IP address of the associated AR and forwards the capabilities of the AR to the MN. Also, I don't think we should prevent TAR selection at the AR altogether now. I don't think allowing it makes CARD any more complicated. CARD should be allowed to push its output to the TAR module irrespective of where it resides. For some cases such as load balancing, that is presented in the issues draft, this mode of operation may be quite useful. Regards, Govind. -----Original Message----- From: ext Pat Calhoun [mailto:pcalhoun@bstormnetworks.com] Sent: Sunday, January 05, 2003 8:36 AM To: Chaskar Hemant (NRC/Boston) Cc: Seamoby@ietf.org Subject: Re: [Seamoby] CARD feeding TAR selection issue > Step 1: MN collects the identities of CARs (after listening to AP beacons from them) and their capabilities using CARD protocol. For this, MN queries either current AR or new AR (depending upon whether is it doing CARD in MN orchestrated or network assisted mode) and receives this information. For a given CAR, its entire capability set is provided to MN. There are link layers that do not allow more than one link layer connection at any given time, and although the beacons could be received, as they are on a special channel. In these conditions, how would the mobile receive CARD packets? PatC _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Jan 6 09:56:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04682 for ; Mon, 6 Jan 2003 09:56:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h06F6NV22070 for seamoby-archive@odin.ietf.org; Mon, 6 Jan 2003 10:06:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06F6NJ22067 for ; Mon, 6 Jan 2003 10:06:23 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04661 for ; Mon, 6 Jan 2003 09:55:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06F4wJ21913; Mon, 6 Jan 2003 10:04:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06F1lJ21723 for ; Mon, 6 Jan 2003 10:01:47 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04521 for ; Mon, 6 Jan 2003 09:50:59 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h06EsGE05986 for ; Mon, 6 Jan 2003 08:54:16 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 6 Jan 2003 08:54:11 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 6 Jan 2003 08:53:22 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CARD feeding TAR selection issue Date: Mon, 6 Jan 2003 09:53:21 -0500 Message-ID: Thread-Topic: [Seamoby] CARD feeding TAR selection issue Thread-Index: AcK1iPGD/sOHe0h8Sxm8xV+iqIErpAACZoyw To: , Cc: X-OriginalArrivalTime: 06 Jan 2003 14:53:22.0241 (UTC) FILETIME=[5BA8E310:01C2B593] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h06F1lJ21724 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Pat, In the case that you illustrate, the current AR has to be involved.The MN forwards the L2 Id to the current AR. The current AR, then, maps the beacon information to the IP address of the associated AR and forwards the capabilities of the AR to the MN. Also, I don't think we should prevent TAR selection at the AR altogether now. I don't think allowing it makes CARD any more complicated. CARD should be allowed to push its output to the TAR module irrespective of where it resides. For some cases such as load balancing, that is presented in the issues draft, this mode of operation may be quite useful. Regards, Govind. -----Original Message----- From: ext Pat Calhoun [mailto:pcalhoun@bstormnetworks.com] Sent: Sunday, January 05, 2003 8:36 AM To: Chaskar Hemant (NRC/Boston) Cc: Seamoby@ietf.org Subject: Re: [Seamoby] CARD feeding TAR selection issue > Step 1: MN collects the identities of CARs (after listening to AP beacons from them) and their capabilities using CARD protocol. For this, MN queries either current AR or new AR (depending upon whether is it doing CARD in MN orchestrated or network assisted mode) and receives this information. For a given CAR, its entire capability set is provided to MN. There are link layers that do not allow more than one link layer connection at any given time, and although the beacons could be received, as they are on a special channel. In these conditions, how would the mobile receive CARD packets? PatC _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Jan 6 10:51:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05882 for ; Mon, 6 Jan 2003 10:51:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06G1SJ25905; Mon, 6 Jan 2003 11:01:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06G0YJ25843 for ; Mon, 6 Jan 2003 11:00:34 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05870 for ; Mon, 6 Jan 2003 10:49:45 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h06Fr3E13714 for ; Mon, 6 Jan 2003 09:53:03 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 6 Jan 2003 09:52:58 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 6 Jan 2003 09:52:58 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CARD feeding TAR selection issue Date: Mon, 6 Jan 2003 10:52:56 -0500 Message-ID: Thread-Topic: [Seamoby] CARD feeding TAR selection issue Thread-Index: AcK1iLy+XoUwHtoRQDSRcExWNGfAlAAEoYPw To: Cc: X-OriginalArrivalTime: 06 Jan 2003 15:52:58.0552 (UTC) FILETIME=[AF4EA380:01C2B59B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h06G0YJ25844 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Pat: One possible application scenario for MN-Orchestrated CARD is for MN having multiple NICs (say cellular and WLAN). In this case, with active cellular connection, it would be possible to collect CARD packets over WLAN interface. However, if more than one link layer connection is not allowed (either because both current and new AR use the same radio technology or because MN front end radio is software programmable) then MN needs to take help of current AR, i.e., it has to perform network-assisted CARD. Regards, Hemant -----Original Message----- From: ext Pat Calhoun [mailto:pcalhoun@bstormnetworks.com] Sent: Sunday, January 05, 2003 8:36 AM To: Chaskar Hemant (NRC/Boston) Cc: Seamoby@ietf.org Subject: Re: [Seamoby] CARD feeding TAR selection issue > Step 1: MN collects the identities of CARs (after listening to AP beacons from them) and their capabilities using CARD protocol. For this, MN queries either current AR or new AR (depending upon whether is it doing CARD in MN orchestrated or network assisted mode) and receives this information. For a given CAR, its entire capability set is provided to MN. There are link layers that do not allow more than one link layer connection at any given time, and although the beacons could be received, as they are on a special channel. In these conditions, how would the mobile receive CARD packets? PatC _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Jan 6 10:52:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05905 for ; Mon, 6 Jan 2003 10:52:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h06G2kq25944 for seamoby-archive@odin.ietf.org; Mon, 6 Jan 2003 11:02:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06G2kJ25941 for ; Mon, 6 Jan 2003 11:02:46 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05885 for ; Mon, 6 Jan 2003 10:51:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06G1SJ25905; Mon, 6 Jan 2003 11:01:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06G0YJ25843 for ; Mon, 6 Jan 2003 11:00:34 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05870 for ; Mon, 6 Jan 2003 10:49:45 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h06Fr3E13714 for ; Mon, 6 Jan 2003 09:53:03 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 6 Jan 2003 09:52:58 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 6 Jan 2003 09:52:58 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CARD feeding TAR selection issue Date: Mon, 6 Jan 2003 10:52:56 -0500 Message-ID: Thread-Topic: [Seamoby] CARD feeding TAR selection issue Thread-Index: AcK1iLy+XoUwHtoRQDSRcExWNGfAlAAEoYPw To: Cc: X-OriginalArrivalTime: 06 Jan 2003 15:52:58.0552 (UTC) FILETIME=[AF4EA380:01C2B59B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h06G0YJ25844 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Pat: One possible application scenario for MN-Orchestrated CARD is for MN having multiple NICs (say cellular and WLAN). In this case, with active cellular connection, it would be possible to collect CARD packets over WLAN interface. However, if more than one link layer connection is not allowed (either because both current and new AR use the same radio technology or because MN front end radio is software programmable) then MN needs to take help of current AR, i.e., it has to perform network-assisted CARD. Regards, Hemant -----Original Message----- From: ext Pat Calhoun [mailto:pcalhoun@bstormnetworks.com] Sent: Sunday, January 05, 2003 8:36 AM To: Chaskar Hemant (NRC/Boston) Cc: Seamoby@ietf.org Subject: Re: [Seamoby] CARD feeding TAR selection issue > Step 1: MN collects the identities of CARs (after listening to AP beacons from them) and their capabilities using CARD protocol. For this, MN queries either current AR or new AR (depending upon whether is it doing CARD in MN orchestrated or network assisted mode) and receives this information. For a given CAR, its entire capability set is provided to MN. There are link layers that do not allow more than one link layer connection at any given time, and although the beacons could be received, as they are on a special channel. In these conditions, how would the mobile receive CARD packets? PatC _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Jan 6 10:56:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05937 for ; Mon, 6 Jan 2003 10:56:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06G5hJ26073; Mon, 6 Jan 2003 11:05:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06G4HJ26005 for ; Mon, 6 Jan 2003 11:04:17 -0500 Received: from bsn-mail-01.bstormnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05924 for ; Mon, 6 Jan 2003 10:53:29 -0500 (EST) Subject: RE: [Seamoby] CARD feeding TAR selection issue From: Pat Calhoun To: Hemant.Chaskar@nokia.com Cc: Seamoby@ietf.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1041868529.2826.44.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 06 Jan 2003 07:55:30 -0800 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Thanks PatC On Mon, 2003-01-06 at 07:52, Hemant.Chaskar@nokia.com wrote: > Hi Pat: > > One possible application scenario for MN-Orchestrated CARD is for MN having multiple NICs (say cellular and WLAN). In this case, with active cellular connection, it would be possible to collect CARD packets over WLAN interface. > > However, if more than one link layer connection is not allowed (either because both current and new AR use the same radio technology or because MN front end radio is software programmable) then MN needs to take help of current AR, i.e., it has to perform network-assisted CARD. > > Regards, > Hemant > > -----Original Message----- > From: ext Pat Calhoun [mailto:pcalhoun@bstormnetworks.com] > Sent: Sunday, January 05, 2003 8:36 AM > To: Chaskar Hemant (NRC/Boston) > Cc: Seamoby@ietf.org > Subject: Re: [Seamoby] CARD feeding TAR selection issue > > > > Step 1: MN collects the identities of CARs (after listening to AP beacons from them) and their capabilities using CARD protocol. For this, MN queries either current AR or new AR (depending upon whether is it doing CARD in MN orchestrated or network assisted mode) and receives this information. For a given CAR, its entire capability set is provided to MN. > > There are link layers that do not allow more than one link layer > connection at any given time, and although the beacons could be > received, as they are on a special channel. In these conditions, how > would the mobile receive CARD packets? > > PatC _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Jan 6 10:56:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05964 for ; Mon, 6 Jan 2003 10:56:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h06G6xY26145 for seamoby-archive@odin.ietf.org; Mon, 6 Jan 2003 11:06:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06G6xJ26142 for ; Mon, 6 Jan 2003 11:06:59 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05951 for ; Mon, 6 Jan 2003 10:56:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06G5hJ26073; Mon, 6 Jan 2003 11:05:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06G4HJ26005 for ; Mon, 6 Jan 2003 11:04:17 -0500 Received: from bsn-mail-01.bstormnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05924 for ; Mon, 6 Jan 2003 10:53:29 -0500 (EST) Subject: RE: [Seamoby] CARD feeding TAR selection issue From: Pat Calhoun To: Hemant.Chaskar@nokia.com Cc: Seamoby@ietf.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1041868529.2826.44.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 06 Jan 2003 07:55:30 -0800 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thanks PatC On Mon, 2003-01-06 at 07:52, Hemant.Chaskar@nokia.com wrote: > Hi Pat: > > One possible application scenario for MN-Orchestrated CARD is for MN having multiple NICs (say cellular and WLAN). In this case, with active cellular connection, it would be possible to collect CARD packets over WLAN interface. > > However, if more than one link layer connection is not allowed (either because both current and new AR use the same radio technology or because MN front end radio is software programmable) then MN needs to take help of current AR, i.e., it has to perform network-assisted CARD. > > Regards, > Hemant > > -----Original Message----- > From: ext Pat Calhoun [mailto:pcalhoun@bstormnetworks.com] > Sent: Sunday, January 05, 2003 8:36 AM > To: Chaskar Hemant (NRC/Boston) > Cc: Seamoby@ietf.org > Subject: Re: [Seamoby] CARD feeding TAR selection issue > > > > Step 1: MN collects the identities of CARs (after listening to AP beacons from them) and their capabilities using CARD protocol. For this, MN queries either current AR or new AR (depending upon whether is it doing CARD in MN orchestrated or network assisted mode) and receives this information. For a given CAR, its entire capability set is provided to MN. > > There are link layers that do not allow more than one link layer > connection at any given time, and although the beacons could be > received, as they are on a special channel. In these conditions, how > would the mobile receive CARD packets? > > PatC _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Jan 6 11:59:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07282 for ; Mon, 6 Jan 2003 11:59:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06H9HJ30837; Mon, 6 Jan 2003 12:09:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06H8JJ30807 for ; Mon, 6 Jan 2003 12:08:19 -0500 Received: from ftpbox.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07258 for ; Mon, 6 Jan 2003 11:57:28 -0500 (EST) Received: from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h06H0hHP014636 for ; Mon, 6 Jan 2003 10:00:43 -0700 (MST) Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id KAA23056 for ; Mon, 6 Jan 2003 10:00:42 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Mon, 6 Jan 2003 11:00:42 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BD64@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'James Kempf'" , Seamoby@ietf.org Subject: RE: [Seamoby] CARD - FMIPv6 protocol interworking Date: Mon, 6 Jan 2003 11:00:31 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Hello James, Sorry for late reply. I got back from vacation recently. Please find my inline reply. Regards, ajoy -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Friday, December 20, 2002 11:40 AM To: Singh Ajoy-ASINGH1; Seamoby@ietf.org Subject: Re: [Seamoby] CARD - FMIPv6 protocol interworking > > PROS: Enables inter-working of CARD and FMIPv6. Probably this will make > CARD and FMIPv6 implementation less complicated. > I favor this approach, for router to mobile communication, at least. AJOY-> I am not against piggybacking the CARD signaling over FMIPv6 message. I was just asking if we need to make CARD ICMP options tightly coupled with PRoxyRtSol or ProxyRtAdv messages or let be optinal so that any ICMP messages can be used to piggyback these options. It looks like from others' response that quite a few of WG members are against the idea of tight coupling. What you think? > CONS: This approach restricts the deployment of CARD to FMIpv6 only. > This approach may also require modification to the present FMIPv6 protocol. > I don't see why this should restrict CARD To FMIPv6. FMIPv6 defines some additional ICMP messages. If the CARD messages are extensions too, the difference between the loose approach and tight approach isn't so great in my view. The new ICMP messages can be used with or without handover. AJOY-> The difference is cosmetic. If someone is not implementing CARD along with FMIPv6, it may not be cleaner to use FMIPv6 messages for CARD signaling. Actually the CARD ICMP messages will be similar to FMIPv6 message, but it will have different type. Those designed to be used with handover are FMIPv6, those designed to be used without are CARD. There has been a discussion in the MIP group about whether the FMIPv6 prehandover signaling should be completely decoupled from handover, but the discussion has not reached any clear conclusion. One issue is whether decoupling the signaling would also decouple any signaling between the mobile's current access router and other access routers (i.e. HI/HAck). If no signaling occurs between access routers when the FMIPv6 signaling occurs (that is, it is for information only), then that would be the equivalent of CARD. If signaling does occur, perhaps to pre-configure a care of address on the new subnet, then it would be different. I think a more pressing issue for CARD is whether the same protocol can be used to exchange CARD information between routers. AJOY-> I agree and this will also be addressed. First, we would like WG to agree upon MN-AR messaging. The current FMIPv6 approach isn't defined for this, and there are some good arguments why this should be done using a reliable transport, such as SCTP or TCP, rather than UDP, which came up during the CT discussion. AJOY-> Since this discussion has already taken place in context of CT protocol, do we really need to get WG consensus about this? Won't the same conclusion apply in this case also? > Intermediate Approach: In this approach, we can define CARD signaling as > generic ICMP options. These ICMP options can be piggybacked upon any ICMP > message including FMIPv6 signaling messages. Additionally, we can also define > new CARD ICMP messages, which can be used when no outgoing ICMP messages are > pending. > > The following are the PROS and CONS of this approach: > > PROS: This approach enables the deployment of CARD along with any protocol > including FMIPv6. This also provides opportunity for additional optimization > when deployed with FMIPv6 by exploiting the possibility of piggybacking CARD > signaling over the FMIPv6 messages. > > CONS: The CARD protocol will be slightly more complex compared to the other > approaches. > I am opposed to this. It seems the least clean of all the approaches, both architecturally and implementationally. AJOY-> Why do you think so? Is it because this approach allows the piggybacking of CARD messages over any ICMP messages? If this is your concern, we can state that CARD signaling can only be piggybacked upon FMIPv6 as well as some explicit CARD messages. The new CARD messages will be used when CARD is not deployed along with FMIPv6. > Loose Coupling Approach: We can define CARD signaling as new set of messages > and prohibit the possibility of piggybacking upon any FMIPv6 messages. > > The following are the PROS and CONS of this approach: > > PROS:De-couples CARD from any other protocol including FMIPv6. Probably this > is simpler to implement. > I'm not sure I follow why. While implementing the protocol might be easier, since FMIPv6 will be the principle consumer, it might be more complicated to integrate the two. AJOY-> I agree, if we assume CARD will only be deployed with FMIPv6. > CONS: Adds extra over the air messages during critical path of handoff which > may not be desirable for the most wireless link. > Again, why would this be so? The CARD information can be exchanged between the AR and MN at any time prior to the handover. AJOY-> Not all CARD information will be exchanged long before the handoff. Some of the dynamic capabilities may only be exchanged just prior to handoff. BTW, I think that the Loose Coupling approach might be appropriate for the inter-router exchange protocol, presuming we want to tackle that. However, I believe we would need to look at alternatives, such as including CARD information in the IGP (though that might be messy, given the IETF has three "standard" IGPs). AJOY-> OK, probably we can ignore this approach for now. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Jan 6 12:00:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07319 for ; Mon, 6 Jan 2003 12:00:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h06HAZ030892 for seamoby-archive@odin.ietf.org; Mon, 6 Jan 2003 12:10:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06HAZJ30889 for ; Mon, 6 Jan 2003 12:10:35 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07285 for ; Mon, 6 Jan 2003 11:59:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06H9HJ30837; Mon, 6 Jan 2003 12:09:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06H8JJ30807 for ; Mon, 6 Jan 2003 12:08:19 -0500 Received: from ftpbox.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07258 for ; Mon, 6 Jan 2003 11:57:28 -0500 (EST) Received: from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h06H0hHP014636 for ; Mon, 6 Jan 2003 10:00:43 -0700 (MST) Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id KAA23056 for ; Mon, 6 Jan 2003 10:00:42 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Mon, 6 Jan 2003 11:00:42 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BD64@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'James Kempf'" , Seamoby@ietf.org Subject: RE: [Seamoby] CARD - FMIPv6 protocol interworking Date: Mon, 6 Jan 2003 11:00:31 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Hello James, Sorry for late reply. I got back from vacation recently. Please find my inline reply. Regards, ajoy -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Friday, December 20, 2002 11:40 AM To: Singh Ajoy-ASINGH1; Seamoby@ietf.org Subject: Re: [Seamoby] CARD - FMIPv6 protocol interworking > > PROS: Enables inter-working of CARD and FMIPv6. Probably this will make > CARD and FMIPv6 implementation less complicated. > I favor this approach, for router to mobile communication, at least. AJOY-> I am not against piggybacking the CARD signaling over FMIPv6 message. I was just asking if we need to make CARD ICMP options tightly coupled with PRoxyRtSol or ProxyRtAdv messages or let be optinal so that any ICMP messages can be used to piggyback these options. It looks like from others' response that quite a few of WG members are against the idea of tight coupling. What you think? > CONS: This approach restricts the deployment of CARD to FMIpv6 only. > This approach may also require modification to the present FMIPv6 protocol. > I don't see why this should restrict CARD To FMIPv6. FMIPv6 defines some additional ICMP messages. If the CARD messages are extensions too, the difference between the loose approach and tight approach isn't so great in my view. The new ICMP messages can be used with or without handover. AJOY-> The difference is cosmetic. If someone is not implementing CARD along with FMIPv6, it may not be cleaner to use FMIPv6 messages for CARD signaling. Actually the CARD ICMP messages will be similar to FMIPv6 message, but it will have different type. Those designed to be used with handover are FMIPv6, those designed to be used without are CARD. There has been a discussion in the MIP group about whether the FMIPv6 prehandover signaling should be completely decoupled from handover, but the discussion has not reached any clear conclusion. One issue is whether decoupling the signaling would also decouple any signaling between the mobile's current access router and other access routers (i.e. HI/HAck). If no signaling occurs between access routers when the FMIPv6 signaling occurs (that is, it is for information only), then that would be the equivalent of CARD. If signaling does occur, perhaps to pre-configure a care of address on the new subnet, then it would be different. I think a more pressing issue for CARD is whether the same protocol can be used to exchange CARD information between routers. AJOY-> I agree and this will also be addressed. First, we would like WG to agree upon MN-AR messaging. The current FMIPv6 approach isn't defined for this, and there are some good arguments why this should be done using a reliable transport, such as SCTP or TCP, rather than UDP, which came up during the CT discussion. AJOY-> Since this discussion has already taken place in context of CT protocol, do we really need to get WG consensus about this? Won't the same conclusion apply in this case also? > Intermediate Approach: In this approach, we can define CARD signaling as > generic ICMP options. These ICMP options can be piggybacked upon any ICMP > message including FMIPv6 signaling messages. Additionally, we can also define > new CARD ICMP messages, which can be used when no outgoing ICMP messages are > pending. > > The following are the PROS and CONS of this approach: > > PROS: This approach enables the deployment of CARD along with any protocol > including FMIPv6. This also provides opportunity for additional optimization > when deployed with FMIPv6 by exploiting the possibility of piggybacking CARD > signaling over the FMIPv6 messages. > > CONS: The CARD protocol will be slightly more complex compared to the other > approaches. > I am opposed to this. It seems the least clean of all the approaches, both architecturally and implementationally. AJOY-> Why do you think so? Is it because this approach allows the piggybacking of CARD messages over any ICMP messages? If this is your concern, we can state that CARD signaling can only be piggybacked upon FMIPv6 as well as some explicit CARD messages. The new CARD messages will be used when CARD is not deployed along with FMIPv6. > Loose Coupling Approach: We can define CARD signaling as new set of messages > and prohibit the possibility of piggybacking upon any FMIPv6 messages. > > The following are the PROS and CONS of this approach: > > PROS:De-couples CARD from any other protocol including FMIPv6. Probably this > is simpler to implement. > I'm not sure I follow why. While implementing the protocol might be easier, since FMIPv6 will be the principle consumer, it might be more complicated to integrate the two. AJOY-> I agree, if we assume CARD will only be deployed with FMIPv6. > CONS: Adds extra over the air messages during critical path of handoff which > may not be desirable for the most wireless link. > Again, why would this be so? The CARD information can be exchanged between the AR and MN at any time prior to the handover. AJOY-> Not all CARD information will be exchanged long before the handoff. Some of the dynamic capabilities may only be exchanged just prior to handoff. BTW, I think that the Loose Coupling approach might be appropriate for the inter-router exchange protocol, presuming we want to tackle that. However, I believe we would need to look at alternatives, such as including CARD information in the IGP (though that might be messy, given the IETF has three "standard" IGPs). AJOY-> OK, probably we can ignore this approach for now. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Jan 6 12:09:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07518 for ; Mon, 6 Jan 2003 12:09:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06HJ4J31316; Mon, 6 Jan 2003 12:19:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06HIpJ31284 for ; Mon, 6 Jan 2003 12:18:51 -0500 Received: from idcpa4.pa.interdigital.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07498 for ; Mon, 6 Jan 2003 12:08:00 -0500 (EST) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Mon, 6 Jan 2003 12:09:59 -0500 Message-ID: <5238EB1F9A88D8499B8610F4BEEF46F726A9BD@PAEX2000.InterDigital.com> From: "Shaheen, Kamel M." To: "'Hemant.Chaskar@nokia.com'" , pcalhoun@bstormnetworks.com Cc: Seamoby@ietf.org Subject: RE: [Seamoby] CARD feeding TAR selection issue Date: Mon, 6 Jan 2003 12:11:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Hi Pat and Hemant, I have a question regarding the way the MIP would apply to the case of MN with multiple NICs of different technologies. To be more specific, if the MN has two NICs one is UMTS and the other is WLAN. If the MN has a session running on top of WLAN and would like to continue this session on the UMTS side. How MIP will be triggered in this case? Best Regards, Kamel -----Original Message----- From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] Sent: Mon, January 06, 2003 10:53 AM To: pcalhoun@bstormnetworks.com Cc: Seamoby@ietf.org Subject: RE: [Seamoby] CARD feeding TAR selection issue Hi Pat: One possible application scenario for MN-Orchestrated CARD is for MN having multiple NICs (say cellular and WLAN). In this case, with active cellular connection, it would be possible to collect CARD packets over WLAN interface. However, if more than one link layer connection is not allowed (either because both current and new AR use the same radio technology or because MN front end radio is software programmable) then MN needs to take help of current AR, i.e., it has to perform network-assisted CARD. Regards, Hemant -----Original Message----- From: ext Pat Calhoun [mailto:pcalhoun@bstormnetworks.com] Sent: Sunday, January 05, 2003 8:36 AM To: Chaskar Hemant (NRC/Boston) Cc: Seamoby@ietf.org Subject: Re: [Seamoby] CARD feeding TAR selection issue > Step 1: MN collects the identities of CARs (after listening to AP beacons from them) and their capabilities using CARD protocol. For this, MN queries either current AR or new AR (depending upon whether is it doing CARD in MN orchestrated or network assisted mode) and receives this information. For a given CAR, its entire capability set is provided to MN. There are link layers that do not allow more than one link layer connection at any given time, and although the beacons could be received, as they are on a special channel. In these conditions, how would the mobile receive CARD packets? PatC _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Jan 6 12:09:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07538 for ; Mon, 6 Jan 2003 12:09:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h06HKHe31377 for seamoby-archive@odin.ietf.org; Mon, 6 Jan 2003 12:20:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06HKGJ31374 for ; Mon, 6 Jan 2003 12:20:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07521 for ; Mon, 6 Jan 2003 12:09:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06HJ4J31316; Mon, 6 Jan 2003 12:19:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06HIpJ31284 for ; Mon, 6 Jan 2003 12:18:51 -0500 Received: from idcpa4.pa.interdigital.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07498 for ; Mon, 6 Jan 2003 12:08:00 -0500 (EST) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Mon, 6 Jan 2003 12:09:59 -0500 Message-ID: <5238EB1F9A88D8499B8610F4BEEF46F726A9BD@PAEX2000.InterDigital.com> From: "Shaheen, Kamel M." To: "'Hemant.Chaskar@nokia.com'" , pcalhoun@bstormnetworks.com Cc: Seamoby@ietf.org Subject: RE: [Seamoby] CARD feeding TAR selection issue Date: Mon, 6 Jan 2003 12:11:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Hi Pat and Hemant, I have a question regarding the way the MIP would apply to the case of MN with multiple NICs of different technologies. To be more specific, if the MN has two NICs one is UMTS and the other is WLAN. If the MN has a session running on top of WLAN and would like to continue this session on the UMTS side. How MIP will be triggered in this case? Best Regards, Kamel -----Original Message----- From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] Sent: Mon, January 06, 2003 10:53 AM To: pcalhoun@bstormnetworks.com Cc: Seamoby@ietf.org Subject: RE: [Seamoby] CARD feeding TAR selection issue Hi Pat: One possible application scenario for MN-Orchestrated CARD is for MN having multiple NICs (say cellular and WLAN). In this case, with active cellular connection, it would be possible to collect CARD packets over WLAN interface. However, if more than one link layer connection is not allowed (either because both current and new AR use the same radio technology or because MN front end radio is software programmable) then MN needs to take help of current AR, i.e., it has to perform network-assisted CARD. Regards, Hemant -----Original Message----- From: ext Pat Calhoun [mailto:pcalhoun@bstormnetworks.com] Sent: Sunday, January 05, 2003 8:36 AM To: Chaskar Hemant (NRC/Boston) Cc: Seamoby@ietf.org Subject: Re: [Seamoby] CARD feeding TAR selection issue > Step 1: MN collects the identities of CARs (after listening to AP beacons from them) and their capabilities using CARD protocol. For this, MN queries either current AR or new AR (depending upon whether is it doing CARD in MN orchestrated or network assisted mode) and receives this information. For a given CAR, its entire capability set is provided to MN. There are link layers that do not allow more than one link layer connection at any given time, and although the beacons could be received, as they are on a special channel. In these conditions, how would the mobile receive CARD packets? PatC _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Jan 6 12:21:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07895 for ; Mon, 6 Jan 2003 12:21:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06HV9J31882; Mon, 6 Jan 2003 12:31:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06HUUJ31836 for ; Mon, 6 Jan 2003 12:30:30 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07859 for ; Mon, 6 Jan 2003 12:19:39 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h06HM0008766 for ; Mon, 6 Jan 2003 19:22:00 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 6 Jan 2003 19:22:45 +0200 Received: from daebh002.NOE.Nokia.com ([172.18.242.232]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 6 Jan 2003 19:22:45 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 6 Jan 2003 11:22:42 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CARD feeding TAR selection issue Date: Mon, 6 Jan 2003 12:22:40 -0500 Message-ID: Thread-Topic: [Seamoby] CARD feeding TAR selection issue Thread-Index: AcK1pqPaImWZ3VvZRh2x1gMsulN6wAAAM9IQ To: , Cc: X-OriginalArrivalTime: 06 Jan 2003 17:22:42.0184 (UTC) FILETIME=[3833B080:01C2B5A8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h06HUUJ31837 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Kamel: One can think of number of scenarios. For cellular to WLAN handoff, if MN can simultaneously maintain two IP-level connections, I think MIP can be used in most basic form (without fast HO/CT etc.). In the reverse direction, due to time constraint (WLAN coverage disappearing as you move out of hot-spot) as well as to save cellular bandwidth, it may be efficient to use fast HO and CT signaling along with mobile IP. Hemant -----Original Message----- From: ext Shaheen, Kamel M. [mailto:Kamel.Shaheen@InterDigital.com] Sent: Monday, January 06, 2003 12:11 PM To: Chaskar Hemant (NRC/Boston); pcalhoun@bstormnetworks.com Cc: Seamoby@ietf.org Subject: RE: [Seamoby] CARD feeding TAR selection issue Hi Pat and Hemant, I have a question regarding the way the MIP would apply to the case of MN with multiple NICs of different technologies. To be more specific, if the MN has two NICs one is UMTS and the other is WLAN. If the MN has a session running on top of WLAN and would like to continue this session on the UMTS side. How MIP will be triggered in this case? Best Regards, Kamel -----Original Message----- From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] Sent: Mon, January 06, 2003 10:53 AM To: pcalhoun@bstormnetworks.com Cc: Seamoby@ietf.org Subject: RE: [Seamoby] CARD feeding TAR selection issue Hi Pat: One possible application scenario for MN-Orchestrated CARD is for MN having multiple NICs (say cellular and WLAN). In this case, with active cellular connection, it would be possible to collect CARD packets over WLAN interface. However, if more than one link layer connection is not allowed (either because both current and new AR use the same radio technology or because MN front end radio is software programmable) then MN needs to take help of current AR, i.e., it has to perform network-assisted CARD. Regards, Hemant -----Original Message----- From: ext Pat Calhoun [mailto:pcalhoun@bstormnetworks.com] Sent: Sunday, January 05, 2003 8:36 AM To: Chaskar Hemant (NRC/Boston) Cc: Seamoby@ietf.org Subject: Re: [Seamoby] CARD feeding TAR selection issue > Step 1: MN collects the identities of CARs (after listening to AP beacons from them) and their capabilities using CARD protocol. For this, MN queries either current AR or new AR (depending upon whether is it doing CARD in MN orchestrated or network assisted mode) and receives this information. For a given CAR, its entire capability set is provided to MN. There are link layers that do not allow more than one link layer connection at any given time, and although the beacons could be received, as they are on a special channel. In these conditions, how would the mobile receive CARD packets? PatC _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Jan 6 12:22:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07931 for ; Mon, 6 Jan 2003 12:22:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h06HWKs31939 for seamoby-archive@odin.ietf.org; Mon, 6 Jan 2003 12:32:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06HWKJ31936 for ; Mon, 6 Jan 2003 12:32:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07909 for ; Mon, 6 Jan 2003 12:21:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06HV9J31882; Mon, 6 Jan 2003 12:31:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06HUUJ31836 for ; Mon, 6 Jan 2003 12:30:30 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07859 for ; Mon, 6 Jan 2003 12:19:39 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h06HM0008766 for ; Mon, 6 Jan 2003 19:22:00 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 6 Jan 2003 19:22:45 +0200 Received: from daebh002.NOE.Nokia.com ([172.18.242.232]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 6 Jan 2003 19:22:45 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 6 Jan 2003 11:22:42 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CARD feeding TAR selection issue Date: Mon, 6 Jan 2003 12:22:40 -0500 Message-ID: Thread-Topic: [Seamoby] CARD feeding TAR selection issue Thread-Index: AcK1pqPaImWZ3VvZRh2x1gMsulN6wAAAM9IQ To: , Cc: X-OriginalArrivalTime: 06 Jan 2003 17:22:42.0184 (UTC) FILETIME=[3833B080:01C2B5A8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h06HUUJ31837 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Kamel: One can think of number of scenarios. For cellular to WLAN handoff, if MN can simultaneously maintain two IP-level connections, I think MIP can be used in most basic form (without fast HO/CT etc.). In the reverse direction, due to time constraint (WLAN coverage disappearing as you move out of hot-spot) as well as to save cellular bandwidth, it may be efficient to use fast HO and CT signaling along with mobile IP. Hemant -----Original Message----- From: ext Shaheen, Kamel M. [mailto:Kamel.Shaheen@InterDigital.com] Sent: Monday, January 06, 2003 12:11 PM To: Chaskar Hemant (NRC/Boston); pcalhoun@bstormnetworks.com Cc: Seamoby@ietf.org Subject: RE: [Seamoby] CARD feeding TAR selection issue Hi Pat and Hemant, I have a question regarding the way the MIP would apply to the case of MN with multiple NICs of different technologies. To be more specific, if the MN has two NICs one is UMTS and the other is WLAN. If the MN has a session running on top of WLAN and would like to continue this session on the UMTS side. How MIP will be triggered in this case? Best Regards, Kamel -----Original Message----- From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] Sent: Mon, January 06, 2003 10:53 AM To: pcalhoun@bstormnetworks.com Cc: Seamoby@ietf.org Subject: RE: [Seamoby] CARD feeding TAR selection issue Hi Pat: One possible application scenario for MN-Orchestrated CARD is for MN having multiple NICs (say cellular and WLAN). In this case, with active cellular connection, it would be possible to collect CARD packets over WLAN interface. However, if more than one link layer connection is not allowed (either because both current and new AR use the same radio technology or because MN front end radio is software programmable) then MN needs to take help of current AR, i.e., it has to perform network-assisted CARD. Regards, Hemant -----Original Message----- From: ext Pat Calhoun [mailto:pcalhoun@bstormnetworks.com] Sent: Sunday, January 05, 2003 8:36 AM To: Chaskar Hemant (NRC/Boston) Cc: Seamoby@ietf.org Subject: Re: [Seamoby] CARD feeding TAR selection issue > Step 1: MN collects the identities of CARs (after listening to AP beacons from them) and their capabilities using CARD protocol. For this, MN queries either current AR or new AR (depending upon whether is it doing CARD in MN orchestrated or network assisted mode) and receives this information. For a given CAR, its entire capability set is provided to MN. There are link layers that do not allow more than one link layer connection at any given time, and although the beacons could be received, as they are on a special channel. In these conditions, how would the mobile receive CARD packets? PatC _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Jan 6 12:38:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08381 for ; Mon, 6 Jan 2003 12:38:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06HmDJ00781; Mon, 6 Jan 2003 12:48:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06HlRJ00728 for ; Mon, 6 Jan 2003 12:47:27 -0500 Received: from idcpa4.pa.interdigital.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08301 for ; Mon, 6 Jan 2003 12:36:36 -0500 (EST) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Mon, 6 Jan 2003 12:38:35 -0500 Message-ID: <5238EB1F9A88D8499B8610F4BEEF46F726A9BE@PAEX2000.InterDigital.com> From: "Shaheen, Kamel M." To: "'Hemant.Chaskar@nokia.com'" , "Shaheen, Kamel M." , pcalhoun@bstormnetworks.com Cc: Seamoby@ietf.org Subject: RE: [Seamoby] CARD feeding TAR selection issue Date: Mon, 6 Jan 2003 12:39:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Hi Hemant, I see your point of view, however, how the target system be identified to the source system in either case specially with two IP connections. I would think that if the mobility factor were taken off the picture, the same issue would still persist. Kamel -----Original Message----- From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] Sent: Mon, January 06, 2003 12:23 PM To: Kamel.Shaheen@interdigital.com; pcalhoun@bstormnetworks.com Cc: Seamoby@ietf.org Subject: RE: [Seamoby] CARD feeding TAR selection issue Hi Kamel: One can think of number of scenarios. For cellular to WLAN handoff, if MN can simultaneously maintain two IP-level connections, I think MIP can be used in most basic form (without fast HO/CT etc.). In the reverse direction, due to time constraint (WLAN coverage disappearing as you move out of hot-spot) as well as to save cellular bandwidth, it may be efficient to use fast HO and CT signaling along with mobile IP. Hemant -----Original Message----- From: ext Shaheen, Kamel M. [mailto:Kamel.Shaheen@InterDigital.com] Sent: Monday, January 06, 2003 12:11 PM To: Chaskar Hemant (NRC/Boston); pcalhoun@bstormnetworks.com Cc: Seamoby@ietf.org Subject: RE: [Seamoby] CARD feeding TAR selection issue Hi Pat and Hemant, I have a question regarding the way the MIP would apply to the case of MN with multiple NICs of different technologies. To be more specific, if the MN has two NICs one is UMTS and the other is WLAN. If the MN has a session running on top of WLAN and would like to continue this session on the UMTS side. How MIP will be triggered in this case? Best Regards, Kamel -----Original Message----- From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] Sent: Mon, January 06, 2003 10:53 AM To: pcalhoun@bstormnetworks.com Cc: Seamoby@ietf.org Subject: RE: [Seamoby] CARD feeding TAR selection issue Hi Pat: One possible application scenario for MN-Orchestrated CARD is for MN having multiple NICs (say cellular and WLAN). In this case, with active cellular connection, it would be possible to collect CARD packets over WLAN interface. However, if more than one link layer connection is not allowed (either because both current and new AR use the same radio technology or because MN front end radio is software programmable) then MN needs to take help of current AR, i.e., it has to perform network-assisted CARD. Regards, Hemant -----Original Message----- From: ext Pat Calhoun [mailto:pcalhoun@bstormnetworks.com] Sent: Sunday, January 05, 2003 8:36 AM To: Chaskar Hemant (NRC/Boston) Cc: Seamoby@ietf.org Subject: Re: [Seamoby] CARD feeding TAR selection issue > Step 1: MN collects the identities of CARs (after listening to AP beacons from them) and their capabilities using CARD protocol. For this, MN queries either current AR or new AR (depending upon whether is it doing CARD in MN orchestrated or network assisted mode) and receives this information. For a given CAR, its entire capability set is provided to MN. There are link layers that do not allow more than one link layer connection at any given time, and although the beacons could be received, as they are on a special channel. In these conditions, how would the mobile receive CARD packets? PatC _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Jan 6 12:39:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08408 for ; Mon, 6 Jan 2003 12:39:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h06HnLI00842 for seamoby-archive@odin.ietf.org; Mon, 6 Jan 2003 12:49:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06HnLJ00839 for ; Mon, 6 Jan 2003 12:49:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08384 for ; Mon, 6 Jan 2003 12:38:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06HmDJ00781; Mon, 6 Jan 2003 12:48:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06HlRJ00728 for ; Mon, 6 Jan 2003 12:47:27 -0500 Received: from idcpa4.pa.interdigital.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08301 for ; Mon, 6 Jan 2003 12:36:36 -0500 (EST) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Mon, 6 Jan 2003 12:38:35 -0500 Message-ID: <5238EB1F9A88D8499B8610F4BEEF46F726A9BE@PAEX2000.InterDigital.com> From: "Shaheen, Kamel M." To: "'Hemant.Chaskar@nokia.com'" , "Shaheen, Kamel M." , pcalhoun@bstormnetworks.com Cc: Seamoby@ietf.org Subject: RE: [Seamoby] CARD feeding TAR selection issue Date: Mon, 6 Jan 2003 12:39:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Hi Hemant, I see your point of view, however, how the target system be identified to the source system in either case specially with two IP connections. I would think that if the mobility factor were taken off the picture, the same issue would still persist. Kamel -----Original Message----- From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] Sent: Mon, January 06, 2003 12:23 PM To: Kamel.Shaheen@interdigital.com; pcalhoun@bstormnetworks.com Cc: Seamoby@ietf.org Subject: RE: [Seamoby] CARD feeding TAR selection issue Hi Kamel: One can think of number of scenarios. For cellular to WLAN handoff, if MN can simultaneously maintain two IP-level connections, I think MIP can be used in most basic form (without fast HO/CT etc.). In the reverse direction, due to time constraint (WLAN coverage disappearing as you move out of hot-spot) as well as to save cellular bandwidth, it may be efficient to use fast HO and CT signaling along with mobile IP. Hemant -----Original Message----- From: ext Shaheen, Kamel M. [mailto:Kamel.Shaheen@InterDigital.com] Sent: Monday, January 06, 2003 12:11 PM To: Chaskar Hemant (NRC/Boston); pcalhoun@bstormnetworks.com Cc: Seamoby@ietf.org Subject: RE: [Seamoby] CARD feeding TAR selection issue Hi Pat and Hemant, I have a question regarding the way the MIP would apply to the case of MN with multiple NICs of different technologies. To be more specific, if the MN has two NICs one is UMTS and the other is WLAN. If the MN has a session running on top of WLAN and would like to continue this session on the UMTS side. How MIP will be triggered in this case? Best Regards, Kamel -----Original Message----- From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] Sent: Mon, January 06, 2003 10:53 AM To: pcalhoun@bstormnetworks.com Cc: Seamoby@ietf.org Subject: RE: [Seamoby] CARD feeding TAR selection issue Hi Pat: One possible application scenario for MN-Orchestrated CARD is for MN having multiple NICs (say cellular and WLAN). In this case, with active cellular connection, it would be possible to collect CARD packets over WLAN interface. However, if more than one link layer connection is not allowed (either because both current and new AR use the same radio technology or because MN front end radio is software programmable) then MN needs to take help of current AR, i.e., it has to perform network-assisted CARD. Regards, Hemant -----Original Message----- From: ext Pat Calhoun [mailto:pcalhoun@bstormnetworks.com] Sent: Sunday, January 05, 2003 8:36 AM To: Chaskar Hemant (NRC/Boston) Cc: Seamoby@ietf.org Subject: Re: [Seamoby] CARD feeding TAR selection issue > Step 1: MN collects the identities of CARs (after listening to AP beacons from them) and their capabilities using CARD protocol. For this, MN queries either current AR or new AR (depending upon whether is it doing CARD in MN orchestrated or network assisted mode) and receives this information. For a given CAR, its entire capability set is provided to MN. There are link layers that do not allow more than one link layer connection at any given time, and although the beacons could be received, as they are on a special channel. In these conditions, how would the mobile receive CARD packets? PatC _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Jan 6 12:58:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08852 for ; Mon, 6 Jan 2003 12:58:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06I8GJ02315; Mon, 6 Jan 2003 13:08:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06I7OJ02091 for ; Mon, 6 Jan 2003 13:07:24 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08832 for ; Mon, 6 Jan 2003 12:56:32 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h06I01824172 for ; Mon, 6 Jan 2003 12:00:01 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 6 Jan 2003 11:59:43 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 6 Jan 2003 09:59:21 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CARD feeding TAR selection issue Date: Mon, 6 Jan 2003 12:59:20 -0500 Message-ID: Thread-Topic: [Seamoby] CARD feeding TAR selection issue Thread-Index: AcK1qqBVKqg5XYSrRZSs3PAX9jOg9wAAjhGQ To: , Cc: X-OriginalArrivalTime: 06 Jan 2003 17:59:21.0837 (UTC) FILETIME=[574C19D0:01C2B5AD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h06I7OJ02092 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Kamel: In the first (simple) case, there is no need to identify target system to source system. There are two connections pivoted at MN. MN can send binding update over new connection and upon receiving BACK can switch to new connection and let go the old one. This is make before break case. In the second case, CARD will enable the mapping using AP ID of new system as the identifier sent to current AR. Hemant -----Original Message----- From: ext Shaheen, Kamel M. [mailto:Kamel.Shaheen@InterDigital.com] Sent: Monday, January 06, 2003 12:40 PM To: Chaskar Hemant (NRC/Boston); Shaheen, Kamel M.; pcalhoun@bstormnetworks.com Cc: Seamoby@ietf.org Subject: RE: [Seamoby] CARD feeding TAR selection issue Hi Hemant, I see your point of view, however, how the target system be identified to the source system in either case specially with two IP connections. I would think that if the mobility factor were taken off the picture, the same issue would still persist. Kamel -----Original Message----- From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] Sent: Mon, January 06, 2003 12:23 PM To: Kamel.Shaheen@interdigital.com; pcalhoun@bstormnetworks.com Cc: Seamoby@ietf.org Subject: RE: [Seamoby] CARD feeding TAR selection issue Hi Kamel: One can think of number of scenarios. For cellular to WLAN handoff, if MN can simultaneously maintain two IP-level connections, I think MIP can be used in most basic form (without fast HO/CT etc.). In the reverse direction, due to time constraint (WLAN coverage disappearing as you move out of hot-spot) as well as to save cellular bandwidth, it may be efficient to use fast HO and CT signaling along with mobile IP. Hemant -----Original Message----- From: ext Shaheen, Kamel M. [mailto:Kamel.Shaheen@InterDigital.com] Sent: Monday, January 06, 2003 12:11 PM To: Chaskar Hemant (NRC/Boston); pcalhoun@bstormnetworks.com Cc: Seamoby@ietf.org Subject: RE: [Seamoby] CARD feeding TAR selection issue Hi Pat and Hemant, I have a question regarding the way the MIP would apply to the case of MN with multiple NICs of different technologies. To be more specific, if the MN has two NICs one is UMTS and the other is WLAN. If the MN has a session running on top of WLAN and would like to continue this session on the UMTS side. How MIP will be triggered in this case? Best Regards, Kamel -----Original Message----- From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] Sent: Mon, January 06, 2003 10:53 AM To: pcalhoun@bstormnetworks.com Cc: Seamoby@ietf.org Subject: RE: [Seamoby] CARD feeding TAR selection issue Hi Pat: One possible application scenario for MN-Orchestrated CARD is for MN having multiple NICs (say cellular and WLAN). In this case, with active cellular connection, it would be possible to collect CARD packets over WLAN interface. However, if more than one link layer connection is not allowed (either because both current and new AR use the same radio technology or because MN front end radio is software programmable) then MN needs to take help of current AR, i.e., it has to perform network-assisted CARD. Regards, Hemant -----Original Message----- From: ext Pat Calhoun [mailto:pcalhoun@bstormnetworks.com] Sent: Sunday, January 05, 2003 8:36 AM To: Chaskar Hemant (NRC/Boston) Cc: Seamoby@ietf.org Subject: Re: [Seamoby] CARD feeding TAR selection issue > Step 1: MN collects the identities of CARs (after listening to AP beacons from them) and their capabilities using CARD protocol. For this, MN queries either current AR or new AR (depending upon whether is it doing CARD in MN orchestrated or network assisted mode) and receives this information. For a given CAR, its entire capability set is provided to MN. There are link layers that do not allow more than one link layer connection at any given time, and although the beacons could be received, as they are on a special channel. In these conditions, how would the mobile receive CARD packets? PatC _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Jan 6 12:59:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08879 for ; Mon, 6 Jan 2003 12:59:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h06I9UO02362 for seamoby-archive@odin.ietf.org; Mon, 6 Jan 2003 13:09:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06I9UJ02359 for ; Mon, 6 Jan 2003 13:09:30 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08855 for ; Mon, 6 Jan 2003 12:58:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06I8GJ02315; Mon, 6 Jan 2003 13:08:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06I7OJ02091 for ; Mon, 6 Jan 2003 13:07:24 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08832 for ; Mon, 6 Jan 2003 12:56:32 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h06I01824172 for ; Mon, 6 Jan 2003 12:00:01 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 6 Jan 2003 11:59:43 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 6 Jan 2003 09:59:21 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CARD feeding TAR selection issue Date: Mon, 6 Jan 2003 12:59:20 -0500 Message-ID: Thread-Topic: [Seamoby] CARD feeding TAR selection issue Thread-Index: AcK1qqBVKqg5XYSrRZSs3PAX9jOg9wAAjhGQ To: , Cc: X-OriginalArrivalTime: 06 Jan 2003 17:59:21.0837 (UTC) FILETIME=[574C19D0:01C2B5AD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h06I7OJ02092 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Kamel: In the first (simple) case, there is no need to identify target system to source system. There are two connections pivoted at MN. MN can send binding update over new connection and upon receiving BACK can switch to new connection and let go the old one. This is make before break case. In the second case, CARD will enable the mapping using AP ID of new system as the identifier sent to current AR. Hemant -----Original Message----- From: ext Shaheen, Kamel M. [mailto:Kamel.Shaheen@InterDigital.com] Sent: Monday, January 06, 2003 12:40 PM To: Chaskar Hemant (NRC/Boston); Shaheen, Kamel M.; pcalhoun@bstormnetworks.com Cc: Seamoby@ietf.org Subject: RE: [Seamoby] CARD feeding TAR selection issue Hi Hemant, I see your point of view, however, how the target system be identified to the source system in either case specially with two IP connections. I would think that if the mobility factor were taken off the picture, the same issue would still persist. Kamel -----Original Message----- From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] Sent: Mon, January 06, 2003 12:23 PM To: Kamel.Shaheen@interdigital.com; pcalhoun@bstormnetworks.com Cc: Seamoby@ietf.org Subject: RE: [Seamoby] CARD feeding TAR selection issue Hi Kamel: One can think of number of scenarios. For cellular to WLAN handoff, if MN can simultaneously maintain two IP-level connections, I think MIP can be used in most basic form (without fast HO/CT etc.). In the reverse direction, due to time constraint (WLAN coverage disappearing as you move out of hot-spot) as well as to save cellular bandwidth, it may be efficient to use fast HO and CT signaling along with mobile IP. Hemant -----Original Message----- From: ext Shaheen, Kamel M. [mailto:Kamel.Shaheen@InterDigital.com] Sent: Monday, January 06, 2003 12:11 PM To: Chaskar Hemant (NRC/Boston); pcalhoun@bstormnetworks.com Cc: Seamoby@ietf.org Subject: RE: [Seamoby] CARD feeding TAR selection issue Hi Pat and Hemant, I have a question regarding the way the MIP would apply to the case of MN with multiple NICs of different technologies. To be more specific, if the MN has two NICs one is UMTS and the other is WLAN. If the MN has a session running on top of WLAN and would like to continue this session on the UMTS side. How MIP will be triggered in this case? Best Regards, Kamel -----Original Message----- From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] Sent: Mon, January 06, 2003 10:53 AM To: pcalhoun@bstormnetworks.com Cc: Seamoby@ietf.org Subject: RE: [Seamoby] CARD feeding TAR selection issue Hi Pat: One possible application scenario for MN-Orchestrated CARD is for MN having multiple NICs (say cellular and WLAN). In this case, with active cellular connection, it would be possible to collect CARD packets over WLAN interface. However, if more than one link layer connection is not allowed (either because both current and new AR use the same radio technology or because MN front end radio is software programmable) then MN needs to take help of current AR, i.e., it has to perform network-assisted CARD. Regards, Hemant -----Original Message----- From: ext Pat Calhoun [mailto:pcalhoun@bstormnetworks.com] Sent: Sunday, January 05, 2003 8:36 AM To: Chaskar Hemant (NRC/Boston) Cc: Seamoby@ietf.org Subject: Re: [Seamoby] CARD feeding TAR selection issue > Step 1: MN collects the identities of CARs (after listening to AP beacons from them) and their capabilities using CARD protocol. For this, MN queries either current AR or new AR (depending upon whether is it doing CARD in MN orchestrated or network assisted mode) and receives this information. For a given CAR, its entire capability set is provided to MN. There are link layers that do not allow more than one link layer connection at any given time, and although the beacons could be received, as they are on a special channel. In these conditions, how would the mobile receive CARD packets? PatC _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Jan 6 14:55:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12780 for ; Mon, 6 Jan 2003 14:55:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06K4uJ09584; Mon, 6 Jan 2003 15:04:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06JvaJ09208 for ; Mon, 6 Jan 2003 14:57:36 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12377 for ; Mon, 6 Jan 2003 14:46:44 -0500 (EST) Message-ID: <024501c2b5bc$901d3eb0$506015ac@T23KEMPF> From: "James Kempf" To: , References: Subject: Re: [Seamoby] CARD feeding TAR selection issue Date: Mon, 6 Jan 2003 11:48:18 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Step 1A: To avoid sending whole capability set of any CAR to MN, especially if MN is not interested in all those capabilities, in the CARD query MN can specify the capabilities that it is interested in receiving (by specifying capability attributes). > Agree. > Step 1B: Even when capabilities of interest are specified by MN in query, to avoid sending information on CARs that MN is not obviously going to like, MN can also specify in the query to send CAR information if the capability of interest is above a threshold (attribute being greater than some value). > My experience suggests that this is a slippery slope towards a generalized predicate grammer. I can't see this saving the MN much, and the complexity in code more than overwhelms any advantage. > Network policies (in network assisted CARD) can be implemented indirectly by current AR. In other words, current AR may not send information about certain CARs to MN, if network policy in unfavorable to those CARs. In an extreme case, if network sends to MN information about only one CAR, it is tantamount to performing TAR selection on current AR. > Hmm, I'm not sure I understand the motivation for this requirement. Could you clarify? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Jan 6 14:55:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12800 for ; Mon, 6 Jan 2003 14:55:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h06K67P09661 for seamoby-archive@odin.ietf.org; Mon, 6 Jan 2003 15:06:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06K67J09658 for ; Mon, 6 Jan 2003 15:06:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12794 for ; Mon, 6 Jan 2003 14:55:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06K4uJ09584; Mon, 6 Jan 2003 15:04:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06JvaJ09208 for ; Mon, 6 Jan 2003 14:57:36 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12377 for ; Mon, 6 Jan 2003 14:46:44 -0500 (EST) Message-ID: <024501c2b5bc$901d3eb0$506015ac@T23KEMPF> From: "James Kempf" To: , References: Subject: Re: [Seamoby] CARD feeding TAR selection issue Date: Mon, 6 Jan 2003 11:48:18 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Step 1A: To avoid sending whole capability set of any CAR to MN, especially if MN is not interested in all those capabilities, in the CARD query MN can specify the capabilities that it is interested in receiving (by specifying capability attributes). > Agree. > Step 1B: Even when capabilities of interest are specified by MN in query, to avoid sending information on CARs that MN is not obviously going to like, MN can also specify in the query to send CAR information if the capability of interest is above a threshold (attribute being greater than some value). > My experience suggests that this is a slippery slope towards a generalized predicate grammer. I can't see this saving the MN much, and the complexity in code more than overwhelms any advantage. > Network policies (in network assisted CARD) can be implemented indirectly by current AR. In other words, current AR may not send information about certain CARs to MN, if network policy in unfavorable to those CARs. In an extreme case, if network sends to MN information about only one CAR, it is tantamount to performing TAR selection on current AR. > Hmm, I'm not sure I understand the motivation for this requirement. Could you clarify? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Jan 6 14:57:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12823 for ; Mon, 6 Jan 2003 14:57:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06K7JJ10053; Mon, 6 Jan 2003 15:07:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06JwxJ09245 for ; Mon, 6 Jan 2003 14:58:59 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12449 for ; Mon, 6 Jan 2003 14:48:07 -0500 (EST) Message-ID: <025301c2b5bc$c1854150$506015ac@T23KEMPF> From: "James Kempf" To: , , Cc: References: Subject: Re: [Seamoby] CARD feeding TAR selection issue Date: Mon, 6 Jan 2003 11:49:42 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Also, I don't think we should prevent TAR selection at the AR altogether now. I don't think allowing it makes CARD any more complicated. CARD should be allowed to push its output to the TAR module > irrespective of where it resides. For some cases such as load balancing, that is presented in the > issues draft, this mode of operation may be quite useful. > So the protocol for both cases (i.e. mobile does TAR selection v.s. router) is the same? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Jan 6 14:58:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12850 for ; Mon, 6 Jan 2003 14:58:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h06K8UT10400 for seamoby-archive@odin.ietf.org; Mon, 6 Jan 2003 15:08:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06K8UJ10397 for ; Mon, 6 Jan 2003 15:08:30 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12836 for ; Mon, 6 Jan 2003 14:57:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06K7JJ10053; Mon, 6 Jan 2003 15:07:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06JwxJ09245 for ; Mon, 6 Jan 2003 14:58:59 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12449 for ; Mon, 6 Jan 2003 14:48:07 -0500 (EST) Message-ID: <025301c2b5bc$c1854150$506015ac@T23KEMPF> From: "James Kempf" To: , , Cc: References: Subject: Re: [Seamoby] CARD feeding TAR selection issue Date: Mon, 6 Jan 2003 11:49:42 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Also, I don't think we should prevent TAR selection at the AR altogether now. I don't think allowing it makes CARD any more complicated. CARD should be allowed to push its output to the TAR module > irrespective of where it resides. For some cases such as load balancing, that is presented in the > issues draft, this mode of operation may be quite useful. > So the protocol for both cases (i.e. mobile does TAR selection v.s. router) is the same? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Jan 6 15:01:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13183 for ; Mon, 6 Jan 2003 15:01:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06KB6J10678; Mon, 6 Jan 2003 15:11:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06K3SJ09528 for ; Mon, 6 Jan 2003 15:03:28 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12683 for ; Mon, 6 Jan 2003 14:52:35 -0500 (EST) Message-ID: <025d01c2b5bd$6279c8b0$506015ac@T23KEMPF> From: "James Kempf" To: "Singh Ajoy-ASINGH1" , References: <35DBB8B7AC89D4118E98009027B1009B0CD4BD64@IL27EXM10.cig.mot.com> Subject: Re: [Seamoby] CARD - FMIPv6 protocol interworking Date: Mon, 6 Jan 2003 11:54:12 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ajoy, I'm OK with option 2, having a general ICMP option, *provided* the ADs are. I seem to recall Erik Nordmark in the past having expressed some skepticism about certain types of extension mechanisms, and though I don't remember exactly what his criteria were for successful v.s. unsuccessful extension mechanisms, I do vaguely recall his mentioning something about an ICMP mechanism (it might not have been options) being not particularly successful. I think it might be a good idea to clear this decision with Allison and Erik so that we don't run into any last minute opposition from the IESG. jak ----- Original Message ----- From: "Singh Ajoy-ASINGH1" To: "'James Kempf'" ; Sent: Monday, January 06, 2003 9:00 AM Subject: RE: [Seamoby] CARD - FMIPv6 protocol interworking > Hello James, > Sorry for late reply. I got back from vacation recently. > Please find my inline reply. > Regards, > ajoy > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Friday, December 20, 2002 11:40 AM > To: Singh Ajoy-ASINGH1; Seamoby@ietf.org > Subject: Re: [Seamoby] CARD - FMIPv6 protocol interworking > > > > > > PROS: Enables inter-working of CARD and FMIPv6. Probably this will make > > CARD and FMIPv6 implementation less complicated. > > > > I favor this approach, for router to mobile communication, at least. > > AJOY-> I am not against piggybacking the CARD signaling over FMIPv6 > message. I was just asking if we need to make CARD ICMP options tightly > coupled with PRoxyRtSol or ProxyRtAdv messages or let be optinal > so that any ICMP messages can be used to piggyback these options. > It looks like from others' response that quite a few of WG members > are against the idea of tight coupling. > What you think? > > > CONS: This approach restricts the deployment of CARD to FMIpv6 only. > > This approach may also require modification to the present FMIPv6 > protocol. > > > > I don't see why this should restrict CARD To FMIPv6. FMIPv6 defines some > additional ICMP messages. If the CARD messages are extensions too, the > difference between the loose approach and tight approach isn't so great in > my > view. The new ICMP messages can be used with or without handover. > > AJOY-> The difference is cosmetic. If someone is not implementing > CARD along with FMIPv6, it may not be cleaner to use FMIPv6 > messages for CARD signaling. Actually the CARD ICMP messages will be similar > to > FMIPv6 message, but it will have different type. > > Those designed > to be used with handover are FMIPv6, those designed to be used without are > CARD. > > There has been a discussion in the MIP group about whether the FMIPv6 > prehandover signaling should be completely decoupled from handover, but the > discussion has not reached any clear conclusion. One issue is whether > decoupling > the signaling would also decouple any signaling between the mobile's current > access router and other access routers (i.e. HI/HAck). If no signaling > occurs > between access routers when the FMIPv6 signaling occurs (that is, it is for > information only), then that would be the equivalent of CARD. If signaling > does > occur, perhaps to pre-configure a care of address on the new subnet, then it > would be different. > > I think a more pressing issue for CARD is whether the same protocol can be > used > to exchange CARD information between routers. > > AJOY-> I agree and this will also be addressed. First, > we would like WG to agree upon MN-AR messaging. > > The current FMIPv6 approach isn't > defined for this, and there are some good arguments why this should be done > using a reliable transport, such as SCTP or TCP, rather than UDP, which came > up > during the CT discussion. > > AJOY-> Since this > discussion has already taken place in context of CT protocol, > do we really need to get WG consensus about this? Won't the same > conclusion apply in this case also? > > > Intermediate Approach: In this approach, we can define CARD signaling as > > generic ICMP options. These ICMP options can be piggybacked upon any ICMP > > message including FMIPv6 signaling messages. Additionally, we can also > define > > new CARD ICMP messages, which can be used when no outgoing ICMP messages > are > > pending. > > > > The following are the PROS and CONS of this approach: > > > > PROS: This approach enables the deployment of CARD along with any protocol > > including FMIPv6. This also provides opportunity for additional > optimization > > when deployed with FMIPv6 by exploiting the possibility of piggybacking > CARD > > signaling over the FMIPv6 messages. > > > > CONS: The CARD protocol will be slightly more complex compared to the > other > > approaches. > > > > I am opposed to this. It seems the least clean of all the approaches, both > architecturally and implementationally. > > AJOY-> Why do you think so? Is it because this approach allows the > piggybacking > of CARD messages over any ICMP messages? If this is your concern, we can > state that CARD signaling can only be piggybacked upon FMIPv6 as well as > some explicit CARD messages. The new CARD messages will be used > when CARD is not deployed along with FMIPv6. > > > Loose Coupling Approach: We can define CARD signaling as new set of > messages > > and prohibit the possibility of piggybacking upon any FMIPv6 messages. > > > > The following are the PROS and CONS of this approach: > > > > PROS:De-couples CARD from any other protocol including FMIPv6. Probably > this > > is simpler to implement. > > > > I'm not sure I follow why. While implementing the protocol might be easier, > since FMIPv6 will be the principle consumer, it might be more complicated to > integrate the two. > > AJOY-> I agree, if we assume CARD will only be deployed with FMIPv6. > > > CONS: Adds extra over the air messages during critical path of handoff > which > > may not be desirable for the most wireless link. > > > > Again, why would this be so? The CARD information can be exchanged between > the > AR and MN at any time prior to the handover. > > AJOY-> Not all CARD information will be exchanged long before the handoff. > Some of the dynamic capabilities may only be exchanged just prior to > handoff. > > BTW, I think that the Loose Coupling approach might be appropriate for the > inter-router exchange protocol, presuming we want to tackle that. However, I > believe we would need to look at alternatives, such as including CARD > information in the IGP (though that might be messy, given the IETF has three > "standard" IGPs). > > AJOY-> OK, probably we can ignore this approach for now. > > jak > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Jan 6 15:02:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13240 for ; Mon, 6 Jan 2003 15:02:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h06KCX410834 for seamoby-archive@odin.ietf.org; Mon, 6 Jan 2003 15:12:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06KCXJ10831 for ; Mon, 6 Jan 2003 15:12:33 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13201 for ; Mon, 6 Jan 2003 15:01:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06KB6J10678; Mon, 6 Jan 2003 15:11:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06K3SJ09528 for ; Mon, 6 Jan 2003 15:03:28 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12683 for ; Mon, 6 Jan 2003 14:52:35 -0500 (EST) Message-ID: <025d01c2b5bd$6279c8b0$506015ac@T23KEMPF> From: "James Kempf" To: "Singh Ajoy-ASINGH1" , References: <35DBB8B7AC89D4118E98009027B1009B0CD4BD64@IL27EXM10.cig.mot.com> Subject: Re: [Seamoby] CARD - FMIPv6 protocol interworking Date: Mon, 6 Jan 2003 11:54:12 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ajoy, I'm OK with option 2, having a general ICMP option, *provided* the ADs are. I seem to recall Erik Nordmark in the past having expressed some skepticism about certain types of extension mechanisms, and though I don't remember exactly what his criteria were for successful v.s. unsuccessful extension mechanisms, I do vaguely recall his mentioning something about an ICMP mechanism (it might not have been options) being not particularly successful. I think it might be a good idea to clear this decision with Allison and Erik so that we don't run into any last minute opposition from the IESG. jak ----- Original Message ----- From: "Singh Ajoy-ASINGH1" To: "'James Kempf'" ; Sent: Monday, January 06, 2003 9:00 AM Subject: RE: [Seamoby] CARD - FMIPv6 protocol interworking > Hello James, > Sorry for late reply. I got back from vacation recently. > Please find my inline reply. > Regards, > ajoy > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Friday, December 20, 2002 11:40 AM > To: Singh Ajoy-ASINGH1; Seamoby@ietf.org > Subject: Re: [Seamoby] CARD - FMIPv6 protocol interworking > > > > > > PROS: Enables inter-working of CARD and FMIPv6. Probably this will make > > CARD and FMIPv6 implementation less complicated. > > > > I favor this approach, for router to mobile communication, at least. > > AJOY-> I am not against piggybacking the CARD signaling over FMIPv6 > message. I was just asking if we need to make CARD ICMP options tightly > coupled with PRoxyRtSol or ProxyRtAdv messages or let be optinal > so that any ICMP messages can be used to piggyback these options. > It looks like from others' response that quite a few of WG members > are against the idea of tight coupling. > What you think? > > > CONS: This approach restricts the deployment of CARD to FMIpv6 only. > > This approach may also require modification to the present FMIPv6 > protocol. > > > > I don't see why this should restrict CARD To FMIPv6. FMIPv6 defines some > additional ICMP messages. If the CARD messages are extensions too, the > difference between the loose approach and tight approach isn't so great in > my > view. The new ICMP messages can be used with or without handover. > > AJOY-> The difference is cosmetic. If someone is not implementing > CARD along with FMIPv6, it may not be cleaner to use FMIPv6 > messages for CARD signaling. Actually the CARD ICMP messages will be similar > to > FMIPv6 message, but it will have different type. > > Those designed > to be used with handover are FMIPv6, those designed to be used without are > CARD. > > There has been a discussion in the MIP group about whether the FMIPv6 > prehandover signaling should be completely decoupled from handover, but the > discussion has not reached any clear conclusion. One issue is whether > decoupling > the signaling would also decouple any signaling between the mobile's current > access router and other access routers (i.e. HI/HAck). If no signaling > occurs > between access routers when the FMIPv6 signaling occurs (that is, it is for > information only), then that would be the equivalent of CARD. If signaling > does > occur, perhaps to pre-configure a care of address on the new subnet, then it > would be different. > > I think a more pressing issue for CARD is whether the same protocol can be > used > to exchange CARD information between routers. > > AJOY-> I agree and this will also be addressed. First, > we would like WG to agree upon MN-AR messaging. > > The current FMIPv6 approach isn't > defined for this, and there are some good arguments why this should be done > using a reliable transport, such as SCTP or TCP, rather than UDP, which came > up > during the CT discussion. > > AJOY-> Since this > discussion has already taken place in context of CT protocol, > do we really need to get WG consensus about this? Won't the same > conclusion apply in this case also? > > > Intermediate Approach: In this approach, we can define CARD signaling as > > generic ICMP options. These ICMP options can be piggybacked upon any ICMP > > message including FMIPv6 signaling messages. Additionally, we can also > define > > new CARD ICMP messages, which can be used when no outgoing ICMP messages > are > > pending. > > > > The following are the PROS and CONS of this approach: > > > > PROS: This approach enables the deployment of CARD along with any protocol > > including FMIPv6. This also provides opportunity for additional > optimization > > when deployed with FMIPv6 by exploiting the possibility of piggybacking > CARD > > signaling over the FMIPv6 messages. > > > > CONS: The CARD protocol will be slightly more complex compared to the > other > > approaches. > > > > I am opposed to this. It seems the least clean of all the approaches, both > architecturally and implementationally. > > AJOY-> Why do you think so? Is it because this approach allows the > piggybacking > of CARD messages over any ICMP messages? If this is your concern, we can > state that CARD signaling can only be piggybacked upon FMIPv6 as well as > some explicit CARD messages. The new CARD messages will be used > when CARD is not deployed along with FMIPv6. > > > Loose Coupling Approach: We can define CARD signaling as new set of > messages > > and prohibit the possibility of piggybacking upon any FMIPv6 messages. > > > > The following are the PROS and CONS of this approach: > > > > PROS:De-couples CARD from any other protocol including FMIPv6. Probably > this > > is simpler to implement. > > > > I'm not sure I follow why. While implementing the protocol might be easier, > since FMIPv6 will be the principle consumer, it might be more complicated to > integrate the two. > > AJOY-> I agree, if we assume CARD will only be deployed with FMIPv6. > > > CONS: Adds extra over the air messages during critical path of handoff > which > > may not be desirable for the most wireless link. > > > > Again, why would this be so? The CARD information can be exchanged between > the > AR and MN at any time prior to the handover. > > AJOY-> Not all CARD information will be exchanged long before the handoff. > Some of the dynamic capabilities may only be exchanged just prior to > handoff. > > BTW, I think that the Loose Coupling approach might be appropriate for the > inter-router exchange protocol, presuming we want to tackle that. However, I > believe we would need to look at alternatives, such as including CARD > information in the IGP (though that might be messy, given the IETF has three > "standard" IGPs). > > AJOY-> OK, probably we can ignore this approach for now. > > jak > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Jan 6 15:33:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14032 for ; Mon, 6 Jan 2003 15:33:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06KgDJ12766; Mon, 6 Jan 2003 15:42:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06KbLJ12296 for ; Mon, 6 Jan 2003 15:37:21 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13921 for ; Mon, 6 Jan 2003 15:26:27 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h06KTv816347 for ; Mon, 6 Jan 2003 14:29:57 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 6 Jan 2003 14:29:41 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 6 Jan 2003 12:29:29 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CARD feeding TAR selection issue Date: Mon, 6 Jan 2003 15:29:28 -0500 Message-ID: Thread-Topic: [Seamoby] CARD feeding TAR selection issue Thread-Index: AcK1vM92wu0Q5fn0Q2GC7OTT1F0xXQABMbTA To: , X-OriginalArrivalTime: 06 Jan 2003 20:29:29.0311 (UTC) FILETIME=[502B8EF0:01C2B5C2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h06KbLJ12303 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi James: -------------------------------------clip-------------------------------------- > Network policies (in network assisted CARD) can be implemented indirectly by current AR. In other words, current AR may not send information about certain CARs to MN, if network policy in unfavorable to those CARs. In an extreme case, if network sends to MN information about only one CAR, it is tantamount to performing TAR selection on current AR. > Hmm, I'm not sure I understand the motivation for this requirement. Could you clarify? jak [Hemant] Consider a scenario where MN hears two AP beacons, one from a domain favorable (due to business relationship, say) to current AR and another unfavorable to current AR. MN asks current AR to provide AR addresses and capabilities corresponding to both AP IDs. The issue is, do we want to provide an option to current AR to influence TAR selection in this case. For example, one of the two target AP IDs may be of OWLAN operated by the same operator and another one by different operator. Then, current AR may prefer (or sometimes require) MN handing over to the first OWLAN. Hemant _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Jan 6 15:37:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14170 for ; Mon, 6 Jan 2003 15:37:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h06KlRc13085 for seamoby-archive@odin.ietf.org; Mon, 6 Jan 2003 15:47:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06KlQJ13082 for ; Mon, 6 Jan 2003 15:47:26 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14035 for ; Mon, 6 Jan 2003 15:33:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06KgDJ12766; Mon, 6 Jan 2003 15:42:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06KbLJ12296 for ; Mon, 6 Jan 2003 15:37:21 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13921 for ; Mon, 6 Jan 2003 15:26:27 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h06KTv816347 for ; Mon, 6 Jan 2003 14:29:57 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 6 Jan 2003 14:29:41 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 6 Jan 2003 12:29:29 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CARD feeding TAR selection issue Date: Mon, 6 Jan 2003 15:29:28 -0500 Message-ID: Thread-Topic: [Seamoby] CARD feeding TAR selection issue Thread-Index: AcK1vM92wu0Q5fn0Q2GC7OTT1F0xXQABMbTA To: , X-OriginalArrivalTime: 06 Jan 2003 20:29:29.0311 (UTC) FILETIME=[502B8EF0:01C2B5C2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h06KbLJ12303 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi James: -------------------------------------clip-------------------------------------- > Network policies (in network assisted CARD) can be implemented indirectly by current AR. In other words, current AR may not send information about certain CARs to MN, if network policy in unfavorable to those CARs. In an extreme case, if network sends to MN information about only one CAR, it is tantamount to performing TAR selection on current AR. > Hmm, I'm not sure I understand the motivation for this requirement. Could you clarify? jak [Hemant] Consider a scenario where MN hears two AP beacons, one from a domain favorable (due to business relationship, say) to current AR and another unfavorable to current AR. MN asks current AR to provide AR addresses and capabilities corresponding to both AP IDs. The issue is, do we want to provide an option to current AR to influence TAR selection in this case. For example, one of the two target AP IDs may be of OWLAN operated by the same operator and another one by different operator. Then, current AR may prefer (or sometimes require) MN handing over to the first OWLAN. Hemant _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Jan 6 16:20:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15093 for ; Mon, 6 Jan 2003 16:20:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06LUMJ15337; Mon, 6 Jan 2003 16:30:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06LRjJ15261 for ; Mon, 6 Jan 2003 16:27:45 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15053 for ; Mon, 6 Jan 2003 16:16:51 -0500 (EST) Message-ID: <02bc01c2b5c9$27dc2cf0$506015ac@T23KEMPF> From: "James Kempf" To: , References: Subject: Re: [Seamoby] CARD feeding TAR selection issue Date: Mon, 6 Jan 2003 13:18:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I don't understand why the protocol document describing how CARD information is transferred from the AR to MN or between ARs needs to say anything about this kind of policy issue. What effect does it have on interoperability? In an analogous situation, I don't believe the IP routing protocol specifications say anything about whether or how a domain should expose particular transit routes. That is up to the policy of the ISP. They can treat transit routes like internal routes and not expose them, or they can expose them, depending on the business relationship. But the protocol specifications for BGP, IS-IS, OSPF, etc. don't say either way. At best, this would be an issue that would be taken up in a separate BCP about inter-operator use of CARD. jak ----- Original Message ----- From: To: ; Sent: Monday, January 06, 2003 12:29 PM Subject: RE: [Seamoby] CARD feeding TAR selection issue > Hi James: > > -------------------------------------clip------------------------------------- - > > Network policies (in network assisted CARD) can be implemented indirectly by > current AR. In other words, current AR may not send information about certain > CARs to MN, if network policy in unfavorable to those CARs. In an extreme case, > if network sends to MN information about only one CAR, it is tantamount to > performing TAR selection on current AR. > > > > Hmm, I'm not sure I understand the motivation for this requirement. Could you > clarify? > > jak > > [Hemant] Consider a scenario where MN hears two AP beacons, one from a domain favorable (due to business relationship, say) to current AR and another unfavorable to current AR. MN asks current AR to provide AR addresses and capabilities corresponding to both AP IDs. The issue is, do we want to provide an option to current AR to influence TAR selection in this case. For example, one of the two target AP IDs may be of OWLAN operated by the same operator and another one by different operator. Then, current AR may prefer (or sometimes require) MN handing over to the first OWLAN. > > Hemant > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Jan 6 16:21:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15130 for ; Mon, 6 Jan 2003 16:21:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h06LVSB15395 for seamoby-archive@odin.ietf.org; Mon, 6 Jan 2003 16:31:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06LVSJ15392 for ; Mon, 6 Jan 2003 16:31:28 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15096 for ; Mon, 6 Jan 2003 16:20:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06LUMJ15337; Mon, 6 Jan 2003 16:30:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06LRjJ15261 for ; Mon, 6 Jan 2003 16:27:45 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15053 for ; Mon, 6 Jan 2003 16:16:51 -0500 (EST) Message-ID: <02bc01c2b5c9$27dc2cf0$506015ac@T23KEMPF> From: "James Kempf" To: , References: Subject: Re: [Seamoby] CARD feeding TAR selection issue Date: Mon, 6 Jan 2003 13:18:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I don't understand why the protocol document describing how CARD information is transferred from the AR to MN or between ARs needs to say anything about this kind of policy issue. What effect does it have on interoperability? In an analogous situation, I don't believe the IP routing protocol specifications say anything about whether or how a domain should expose particular transit routes. That is up to the policy of the ISP. They can treat transit routes like internal routes and not expose them, or they can expose them, depending on the business relationship. But the protocol specifications for BGP, IS-IS, OSPF, etc. don't say either way. At best, this would be an issue that would be taken up in a separate BCP about inter-operator use of CARD. jak ----- Original Message ----- From: To: ; Sent: Monday, January 06, 2003 12:29 PM Subject: RE: [Seamoby] CARD feeding TAR selection issue > Hi James: > > -------------------------------------clip------------------------------------- - > > Network policies (in network assisted CARD) can be implemented indirectly by > current AR. In other words, current AR may not send information about certain > CARs to MN, if network policy in unfavorable to those CARs. In an extreme case, > if network sends to MN information about only one CAR, it is tantamount to > performing TAR selection on current AR. > > > > Hmm, I'm not sure I understand the motivation for this requirement. Could you > clarify? > > jak > > [Hemant] Consider a scenario where MN hears two AP beacons, one from a domain favorable (due to business relationship, say) to current AR and another unfavorable to current AR. MN asks current AR to provide AR addresses and capabilities corresponding to both AP IDs. The issue is, do we want to provide an option to current AR to influence TAR selection in this case. For example, one of the two target AP IDs may be of OWLAN operated by the same operator and another one by different operator. Then, current AR may prefer (or sometimes require) MN handing over to the first OWLAN. > > Hemant > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Jan 6 17:40:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17781 for ; Mon, 6 Jan 2003 17:40:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06ModJ21983; Mon, 6 Jan 2003 17:50:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06MnSJ21935 for ; Mon, 6 Jan 2003 17:49:28 -0500 Received: from ftpbox.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17731 for ; Mon, 6 Jan 2003 17:38:30 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h06MfiQ5003593 for ; Mon, 6 Jan 2003 15:41:45 -0700 (MST) Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id PAA28768 for ; Mon, 6 Jan 2003 15:41:44 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Mon, 6 Jan 2003 16:41:44 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BD67@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'mankin@psg.com'" , "'erik.nordmark@sun.com'" Cc: "'James Kempf'" , "'Seamoby@ietf.org'" Subject: RE: [Seamoby] CARD - FMIPv6 protocol interworking Date: Mon, 6 Jan 2003 16:41:25 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Allision/Erik, We have been discussion the possibility of defining CARD signaling as generic ICMP options. The idea is to allow piggybacking of the generic ICMP options over any ICMP messages including FMIPv6 messages (ProxyRouterSol and ProxyRouterAdv). Do you see any issue this approach? James, has indicated some potential issue in the attached email. I would appreciate your comments. Regards, Ajoy -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Monday, January 06, 2003 1:54 PM To: Singh Ajoy-ASINGH1; Seamoby@ietf.org Subject: Re: [Seamoby] CARD - FMIPv6 protocol interworking Ajoy, I'm OK with option 2, having a general ICMP option, *provided* the ADs are. I seem to recall Erik Nordmark in the past having expressed some skepticism about certain types of extension mechanisms, and though I don't remember exactly what his criteria were for successful v.s. unsuccessful extension mechanisms, I do vaguely recall his mentioning something about an ICMP mechanism (it might not have been options) being not particularly successful. I think it might be a good idea to clear this decision with Allison and Erik so that we don't run into any last minute opposition from the IESG. jak ----- Original Message ----- From: "Singh Ajoy-ASINGH1" To: "'James Kempf'" ; Sent: Monday, January 06, 2003 9:00 AM Subject: RE: [Seamoby] CARD - FMIPv6 protocol interworking > Hello James, > Sorry for late reply. I got back from vacation recently. > Please find my inline reply. > Regards, > ajoy > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Friday, December 20, 2002 11:40 AM > To: Singh Ajoy-ASINGH1; Seamoby@ietf.org > Subject: Re: [Seamoby] CARD - FMIPv6 protocol interworking > > > > > > PROS: Enables inter-working of CARD and FMIPv6. Probably this will make > > CARD and FMIPv6 implementation less complicated. > > > > I favor this approach, for router to mobile communication, at least. > > AJOY-> I am not against piggybacking the CARD signaling over FMIPv6 > message. I was just asking if we need to make CARD ICMP options tightly > coupled with PRoxyRtSol or ProxyRtAdv messages or let them be optinal > so that any ICMP messages can be used to piggyback these options. > It looks like from others' response that quite a few of WG members > are against the idea of tight coupling. > What do you think? > > > CONS: This approach restricts the deployment of CARD to FMIpv6 only. > > This approach may also require modification to the present FMIPv6 > protocol. > > > > I don't see why this should restrict CARD To FMIPv6. FMIPv6 defines some > additional ICMP messages. If the CARD messages are extensions too, the > difference between the loose approach and tight approach isn't so great in > my > view. The new ICMP messages can be used with or without handover. > > AJOY-> The difference is cosmetic. If someone is not implementing > CARD along with FMIPv6, it may not be cleaner to use FMIPv6 > messages for CARD signaling. Actually the CARD ICMP messages will be similar > to FMIPv6 message, but it will have different type. > > Those designed > to be used with handover are FMIPv6, those designed to be used without are > CARD. > > There has been a discussion in the MIP group about whether the FMIPv6 > prehandover signaling should be completely decoupled from handover, but the > discussion has not reached any clear conclusion. One issue is whether > decoupling > the signaling would also decouple any signaling between the mobile's current > access router and other access routers (i.e. HI/HAck). If no signaling > occurs > between access routers when the FMIPv6 signaling occurs (that is, it is for > information only), then that would be the equivalent of CARD. If signaling > does > occur, perhaps to pre-configure a care of address on the new subnet, then it > would be different. > > I think a more pressing issue for CARD is whether the same protocol can be > used > to exchange CARD information between routers. > > AJOY-> I agree and this will also be addressed. First > we would like WG to agree upon MN-AR messaging. > > The current FMIPv6 approach isn't > defined for this, and there are some good arguments why this should be done > using a reliable transport, such as SCTP or TCP, rather than UDP, which came > up > during the CT discussion. > > AJOY-> Since this > discussion has already taken place in context of CT protocol, > do we really need to get WG consensus about this? Won't the same > conclusion apply in this case also? > > > Intermediate Approach: In this approach, we can define CARD signaling as > > generic ICMP options. These ICMP options can be piggybacked upon any ICMP > > message including FMIPv6 signaling messages. Additionally, we can also > define > > new CARD ICMP messages, which can be used when no outgoing ICMP messages > are > > pending. > > > > The following are the PROS and CONS of this approach: > > > > PROS: This approach enables the deployment of CARD along with any protocol > > including FMIPv6. This also provides opportunity for additional > optimization > > when deployed with FMIPv6 by exploiting the possibility of piggybacking > CARD > > signaling over the FMIPv6 messages. > > > > CONS: The CARD protocol will be slightly more complex compared to the > other > > approaches. > > > > I am opposed to this. It seems the least clean of all the approaches, both > architecturally and implementationally. > > AJOY-> Why do you think so? Is it because this approach allows the > piggybacking > of CARD messages over any ICMP messages? If this is your concern, we can > state that CARD signaling can only be piggybacked upon FMIPv6 as well as > some explicit CARD messages. The new CARD messages will be used > when CARD is not deployed along with FMIPv6. > > > Loose Coupling Approach: We can define CARD signaling as new set of > messages > > and prohibit the possibility of piggybacking upon any FMIPv6 messages. > > > > The following are the PROS and CONS of this approach: > > > > PROS:De-couples CARD from any other protocol including FMIPv6. Probably > this > > is simpler to implement. > > > > I'm not sure I follow why. While implementing the protocol might be easier, > since FMIPv6 will be the principle consumer, it might be more complicated to > integrate the two. > > AJOY-> I agree, if we assume CARD will only be deployed with FMIPv6. > > > CONS: Adds extra over the air messages during critical path of handoff > which > > may not be desirable for the most wireless link. > > > > Again, why would this be so? The CARD information can be exchanged between > the > AR and MN at any time prior to the handover. > > AJOY-> Not all CARD information will be exchanged long before the handoff. > Some of the dynamic capabilities may only be exchanged just prior to > handoff. > > BTW, I think that the Loose Coupling approach might be appropriate for the > inter-router exchange protocol, presuming we want to tackle that. However, I > believe we would need to look at alternatives, such as including CARD > information in the IGP (though that might be messy, given the IETF has three > "standard" IGPs). > > AJOY-> OK, probably we can ignore this approach for now. > > jak > > >Hello All, > >The CARD design team would like to solicit WG consensus about CARD >and FMIPv6 protocol inter-working. The selection of anyone method >from the proposed list would help us to focus in the right direction >during the next phase of the protocol design. The high-level description >of the various approaches with their relative merits and de-merits is >listed below: >Tight Coupling Approach >Intermediate Approach >Loose Coupling Approach >Tight Coupling Approach: In this case, we can define CARD signaling as >an extension to the FMIPv6 messages. This makes the CARD protocol tightly >coupled with FMIv6 protocol. >The following are the PROS and CONS of this approach: >PROS: Enables inter-working of CARD and FMIPv6. Probably this will make >CARD and FMIPv6 implementation less complicated. >CONS: This approach restricts the deployment of CARD to FMIpv6 only. >This approach may also require modification to the present FMIPv6 protocol. >Intermediate Approach: In this approach, we can define CARD signaling as >generic ICMP options. These ICMP options can be piggybacked upon any ICMP >message including FMIPv6 signaling messages. Additionally, we can also define >new CARD ICMP messages, which can be used when no outgoing ICMP messages are >pending. > >The following are the PROS and CONS of this approach: > >PROS: This approach enables the deployment of CARD along with any protocol >including FMIPv6. This also provides opportunity for additional optimization >when deployed with FMIPv6 by exploiting the possibility of piggybacking CARD >signaling over the FMIPv6 messages. > >CONS: The CARD protocol will be slightly more complex compared to the other >approaches. > >Loose Coupling Approach: We can define CARD signaling as new set of messages >and prohibit the possibility of piggybacking upon any FMIPv6 messages. > >The following are the PROS and CONS of this approach: > >PROS:De-couples CARD from any other protocol including FMIPv6. Probably this >is simpler to implement. > >CONS: Adds extra over the air messages during critical path of handoff which >may not be desirable for the most wireless link. > >Please send your choice if any. > >Regards, >Ajoy _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Jan 6 17:43:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17852 for ; Mon, 6 Jan 2003 17:43:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h06Mrdt22066 for seamoby-archive@odin.ietf.org; Mon, 6 Jan 2003 17:53:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06MrdJ22063 for ; Mon, 6 Jan 2003 17:53:39 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17784 for ; Mon, 6 Jan 2003 17:40:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06ModJ21983; Mon, 6 Jan 2003 17:50:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h06MnSJ21935 for ; Mon, 6 Jan 2003 17:49:28 -0500 Received: from ftpbox.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17731 for ; Mon, 6 Jan 2003 17:38:30 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h06MfiQ5003593 for ; Mon, 6 Jan 2003 15:41:45 -0700 (MST) Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id PAA28768 for ; Mon, 6 Jan 2003 15:41:44 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Mon, 6 Jan 2003 16:41:44 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BD67@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'mankin@psg.com'" , "'erik.nordmark@sun.com'" Cc: "'James Kempf'" , "'Seamoby@ietf.org'" Subject: RE: [Seamoby] CARD - FMIPv6 protocol interworking Date: Mon, 6 Jan 2003 16:41:25 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Allision/Erik, We have been discussion the possibility of defining CARD signaling as generic ICMP options. The idea is to allow piggybacking of the generic ICMP options over any ICMP messages including FMIPv6 messages (ProxyRouterSol and ProxyRouterAdv). Do you see any issue this approach? James, has indicated some potential issue in the attached email. I would appreciate your comments. Regards, Ajoy -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Monday, January 06, 2003 1:54 PM To: Singh Ajoy-ASINGH1; Seamoby@ietf.org Subject: Re: [Seamoby] CARD - FMIPv6 protocol interworking Ajoy, I'm OK with option 2, having a general ICMP option, *provided* the ADs are. I seem to recall Erik Nordmark in the past having expressed some skepticism about certain types of extension mechanisms, and though I don't remember exactly what his criteria were for successful v.s. unsuccessful extension mechanisms, I do vaguely recall his mentioning something about an ICMP mechanism (it might not have been options) being not particularly successful. I think it might be a good idea to clear this decision with Allison and Erik so that we don't run into any last minute opposition from the IESG. jak ----- Original Message ----- From: "Singh Ajoy-ASINGH1" To: "'James Kempf'" ; Sent: Monday, January 06, 2003 9:00 AM Subject: RE: [Seamoby] CARD - FMIPv6 protocol interworking > Hello James, > Sorry for late reply. I got back from vacation recently. > Please find my inline reply. > Regards, > ajoy > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Friday, December 20, 2002 11:40 AM > To: Singh Ajoy-ASINGH1; Seamoby@ietf.org > Subject: Re: [Seamoby] CARD - FMIPv6 protocol interworking > > > > > > PROS: Enables inter-working of CARD and FMIPv6. Probably this will make > > CARD and FMIPv6 implementation less complicated. > > > > I favor this approach, for router to mobile communication, at least. > > AJOY-> I am not against piggybacking the CARD signaling over FMIPv6 > message. I was just asking if we need to make CARD ICMP options tightly > coupled with PRoxyRtSol or ProxyRtAdv messages or let them be optinal > so that any ICMP messages can be used to piggyback these options. > It looks like from others' response that quite a few of WG members > are against the idea of tight coupling. > What do you think? > > > CONS: This approach restricts the deployment of CARD to FMIpv6 only. > > This approach may also require modification to the present FMIPv6 > protocol. > > > > I don't see why this should restrict CARD To FMIPv6. FMIPv6 defines some > additional ICMP messages. If the CARD messages are extensions too, the > difference between the loose approach and tight approach isn't so great in > my > view. The new ICMP messages can be used with or without handover. > > AJOY-> The difference is cosmetic. If someone is not implementing > CARD along with FMIPv6, it may not be cleaner to use FMIPv6 > messages for CARD signaling. Actually the CARD ICMP messages will be similar > to FMIPv6 message, but it will have different type. > > Those designed > to be used with handover are FMIPv6, those designed to be used without are > CARD. > > There has been a discussion in the MIP group about whether the FMIPv6 > prehandover signaling should be completely decoupled from handover, but the > discussion has not reached any clear conclusion. One issue is whether > decoupling > the signaling would also decouple any signaling between the mobile's current > access router and other access routers (i.e. HI/HAck). If no signaling > occurs > between access routers when the FMIPv6 signaling occurs (that is, it is for > information only), then that would be the equivalent of CARD. If signaling > does > occur, perhaps to pre-configure a care of address on the new subnet, then it > would be different. > > I think a more pressing issue for CARD is whether the same protocol can be > used > to exchange CARD information between routers. > > AJOY-> I agree and this will also be addressed. First > we would like WG to agree upon MN-AR messaging. > > The current FMIPv6 approach isn't > defined for this, and there are some good arguments why this should be done > using a reliable transport, such as SCTP or TCP, rather than UDP, which came > up > during the CT discussion. > > AJOY-> Since this > discussion has already taken place in context of CT protocol, > do we really need to get WG consensus about this? Won't the same > conclusion apply in this case also? > > > Intermediate Approach: In this approach, we can define CARD signaling as > > generic ICMP options. These ICMP options can be piggybacked upon any ICMP > > message including FMIPv6 signaling messages. Additionally, we can also > define > > new CARD ICMP messages, which can be used when no outgoing ICMP messages > are > > pending. > > > > The following are the PROS and CONS of this approach: > > > > PROS: This approach enables the deployment of CARD along with any protocol > > including FMIPv6. This also provides opportunity for additional > optimization > > when deployed with FMIPv6 by exploiting the possibility of piggybacking > CARD > > signaling over the FMIPv6 messages. > > > > CONS: The CARD protocol will be slightly more complex compared to the > other > > approaches. > > > > I am opposed to this. It seems the least clean of all the approaches, both > architecturally and implementationally. > > AJOY-> Why do you think so? Is it because this approach allows the > piggybacking > of CARD messages over any ICMP messages? If this is your concern, we can > state that CARD signaling can only be piggybacked upon FMIPv6 as well as > some explicit CARD messages. The new CARD messages will be used > when CARD is not deployed along with FMIPv6. > > > Loose Coupling Approach: We can define CARD signaling as new set of > messages > > and prohibit the possibility of piggybacking upon any FMIPv6 messages. > > > > The following are the PROS and CONS of this approach: > > > > PROS:De-couples CARD from any other protocol including FMIPv6. Probably > this > > is simpler to implement. > > > > I'm not sure I follow why. While implementing the protocol might be easier, > since FMIPv6 will be the principle consumer, it might be more complicated to > integrate the two. > > AJOY-> I agree, if we assume CARD will only be deployed with FMIPv6. > > > CONS: Adds extra over the air messages during critical path of handoff > which > > may not be desirable for the most wireless link. > > > > Again, why would this be so? The CARD information can be exchanged between > the > AR and MN at any time prior to the handover. > > AJOY-> Not all CARD information will be exchanged long before the handoff. > Some of the dynamic capabilities may only be exchanged just prior to > handoff. > > BTW, I think that the Loose Coupling approach might be appropriate for the > inter-router exchange protocol, presuming we want to tackle that. However, I > believe we would need to look at alternatives, such as including CARD > information in the IGP (though that might be messy, given the IETF has three > "standard" IGPs). > > AJOY-> OK, probably we can ignore this approach for now. > > jak > > >Hello All, > >The CARD design team would like to solicit WG consensus about CARD >and FMIPv6 protocol inter-working. The selection of anyone method >from the proposed list would help us to focus in the right direction >during the next phase of the protocol design. The high-level description >of the various approaches with their relative merits and de-merits is >listed below: >Tight Coupling Approach >Intermediate Approach >Loose Coupling Approach >Tight Coupling Approach: In this case, we can define CARD signaling as >an extension to the FMIPv6 messages. This makes the CARD protocol tightly >coupled with FMIv6 protocol. >The following are the PROS and CONS of this approach: >PROS: Enables inter-working of CARD and FMIPv6. Probably this will make >CARD and FMIPv6 implementation less complicated. >CONS: This approach restricts the deployment of CARD to FMIpv6 only. >This approach may also require modification to the present FMIPv6 protocol. >Intermediate Approach: In this approach, we can define CARD signaling as >generic ICMP options. These ICMP options can be piggybacked upon any ICMP >message including FMIPv6 signaling messages. Additionally, we can also define >new CARD ICMP messages, which can be used when no outgoing ICMP messages are >pending. > >The following are the PROS and CONS of this approach: > >PROS: This approach enables the deployment of CARD along with any protocol >including FMIPv6. This also provides opportunity for additional optimization >when deployed with FMIPv6 by exploiting the possibility of piggybacking CARD >signaling over the FMIPv6 messages. > >CONS: The CARD protocol will be slightly more complex compared to the other >approaches. > >Loose Coupling Approach: We can define CARD signaling as new set of messages >and prohibit the possibility of piggybacking upon any FMIPv6 messages. > >The following are the PROS and CONS of this approach: > >PROS:De-couples CARD from any other protocol including FMIPv6. Probably this >is simpler to implement. > >CONS: Adds extra over the air messages during critical path of handoff which >may not be desirable for the most wireless link. > >Please send your choice if any. > >Regards, >Ajoy _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Jan 6 19:03:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19435 for ; Mon, 6 Jan 2003 19:03:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h070DJJ27012; Mon, 6 Jan 2003 19:13:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h070CjJ26982 for ; Mon, 6 Jan 2003 19:12:45 -0500 Received: from motgate3.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19403 for ; Mon, 6 Jan 2003 19:01:46 -0500 (EST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h07046db006695 for ; Mon, 6 Jan 2003 17:04:06 -0700 (MST) Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id RAA17913 for ; Mon, 6 Jan 2003 17:04:33 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Mon, 6 Jan 2003 18:05:00 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BD68@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Erik Nordmark'" , Singh Ajoy-ASINGH1 Cc: mankin@psg.com, "'James Kempf'" , Seamoby@ietf.org Subject: RE: [Seamoby] CARD - FMIPv6 protocol interworking Date: Mon, 6 Jan 2003 18:04:54 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Erik, Please find my inline reply. Regards, Ajoy -----Original Message----- From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] Sent: Monday, January 06, 2003 5:49 PM To: Singh Ajoy-ASINGH1 Cc: mankin@psg.com; erik.nordmark@sun.com; 'James Kempf'; Seamoby@ietf.org Subject: RE: [Seamoby] CARD - FMIPv6 protocol interworking > We have been discussion the possibility of > defining CARD signaling as generic ICMP options. > The idea is to allow piggybacking of > the generic ICMP options over any ICMP messages > including FMIPv6 messages (ProxyRouterSol and ProxyRouterAdv). > Do you see any issue this approach? James, has indicated > some potential issue in the attached email. > I would appreciate your comments. I don't have enough context to understand. Is this written up in an I-D already? AJOY-> The detailed text is not yet available. But some high-level description is available in section 6.1 of http://www.ietf.org/internet-drafts/draft-ietf-seamoby-card-protocol-00.txt. I assume you mean Neighbor Discovery options and not ICMP options since the ICMP message format doesn't have any options. AJOY-> Yes Erik _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Jan 6 19:04:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19452 for ; Mon, 6 Jan 2003 19:04:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h070EuS27058 for seamoby-archive@odin.ietf.org; Mon, 6 Jan 2003 19:14:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h070EuJ27055 for ; Mon, 6 Jan 2003 19:14:56 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19438 for ; Mon, 6 Jan 2003 19:03:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h070DJJ27012; Mon, 6 Jan 2003 19:13:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h070CjJ26982 for ; Mon, 6 Jan 2003 19:12:45 -0500 Received: from motgate3.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19403 for ; Mon, 6 Jan 2003 19:01:46 -0500 (EST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h07046db006695 for ; Mon, 6 Jan 2003 17:04:06 -0700 (MST) Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id RAA17913 for ; Mon, 6 Jan 2003 17:04:33 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Mon, 6 Jan 2003 18:05:00 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BD68@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Erik Nordmark'" , Singh Ajoy-ASINGH1 Cc: mankin@psg.com, "'James Kempf'" , Seamoby@ietf.org Subject: RE: [Seamoby] CARD - FMIPv6 protocol interworking Date: Mon, 6 Jan 2003 18:04:54 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Erik, Please find my inline reply. Regards, Ajoy -----Original Message----- From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] Sent: Monday, January 06, 2003 5:49 PM To: Singh Ajoy-ASINGH1 Cc: mankin@psg.com; erik.nordmark@sun.com; 'James Kempf'; Seamoby@ietf.org Subject: RE: [Seamoby] CARD - FMIPv6 protocol interworking > We have been discussion the possibility of > defining CARD signaling as generic ICMP options. > The idea is to allow piggybacking of > the generic ICMP options over any ICMP messages > including FMIPv6 messages (ProxyRouterSol and ProxyRouterAdv). > Do you see any issue this approach? James, has indicated > some potential issue in the attached email. > I would appreciate your comments. I don't have enough context to understand. Is this written up in an I-D already? AJOY-> The detailed text is not yet available. But some high-level description is available in section 6.1 of http://www.ietf.org/internet-drafts/draft-ietf-seamoby-card-protocol-00.txt. I assume you mean Neighbor Discovery options and not ICMP options since the ICMP message format doesn't have any options. AJOY-> Yes Erik _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Jan 6 20:05:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20637 for ; Mon, 6 Jan 2003 20:05:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h071FVJ30781; Mon, 6 Jan 2003 20:15:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0700TJ25888 for ; Mon, 6 Jan 2003 19:00:29 -0500 Received: from nwkea-mail-1.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19068 for ; Mon, 6 Jan 2003 18:49:30 -0500 (EST) Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA05574; Mon, 6 Jan 2003 15:52:44 -0800 (PST) Received: from localhost (d-mpk17-85-173.Eng.Sun.COM [129.146.85.173]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h06NqfP18429; Tue, 7 Jan 2003 00:52:41 +0100 (MET) Date: Tue, 7 Jan 2003 00:49:19 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: [Seamoby] CARD - FMIPv6 protocol interworking To: Singh Ajoy-ASINGH1 Cc: "'mankin@psg.com'" , "'erik.nordmark@sun.com'" , "'James Kempf'" , "'Seamoby@ietf.org'" In-Reply-To: "Your message with ID" <35DBB8B7AC89D4118E98009027B1009B0CD4BD67@IL27EXM10.cig.mot.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , > We have been discussion the possibility of > defining CARD signaling as generic ICMP options. > The idea is to allow piggybacking of > the generic ICMP options over any ICMP messages > including FMIPv6 messages (ProxyRouterSol and ProxyRouterAdv). > Do you see any issue this approach? James, has indicated > some potential issue in the attached email. > I would appreciate your comments. I don't have enough context to understand. Is this written up in an I-D already? I assume you mean Neighbor Discovery options and not ICMP options since the ICMP message format doesn't have any options. Erik _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Jan 6 20:08:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20673 for ; Mon, 6 Jan 2003 20:08:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h071JIR30884 for seamoby-archive@odin.ietf.org; Mon, 6 Jan 2003 20:19:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h071JIJ30881 for ; Mon, 6 Jan 2003 20:19:18 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20640 for ; Mon, 6 Jan 2003 20:05:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h071FVJ30781; Mon, 6 Jan 2003 20:15:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0700TJ25888 for ; Mon, 6 Jan 2003 19:00:29 -0500 Received: from nwkea-mail-1.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19068 for ; Mon, 6 Jan 2003 18:49:30 -0500 (EST) Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA05574; Mon, 6 Jan 2003 15:52:44 -0800 (PST) Received: from localhost (d-mpk17-85-173.Eng.Sun.COM [129.146.85.173]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h06NqfP18429; Tue, 7 Jan 2003 00:52:41 +0100 (MET) Date: Tue, 7 Jan 2003 00:49:19 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: [Seamoby] CARD - FMIPv6 protocol interworking To: Singh Ajoy-ASINGH1 Cc: "'mankin@psg.com'" , "'erik.nordmark@sun.com'" , "'James Kempf'" , "'Seamoby@ietf.org'" In-Reply-To: "Your message with ID" <35DBB8B7AC89D4118E98009027B1009B0CD4BD67@IL27EXM10.cig.mot.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , > We have been discussion the possibility of > defining CARD signaling as generic ICMP options. > The idea is to allow piggybacking of > the generic ICMP options over any ICMP messages > including FMIPv6 messages (ProxyRouterSol and ProxyRouterAdv). > Do you see any issue this approach? James, has indicated > some potential issue in the attached email. > I would appreciate your comments. I don't have enough context to understand. Is this written up in an I-D already? I assume you mean Neighbor Discovery options and not ICMP options since the ICMP message format doesn't have any options. Erik _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Jan 7 11:42:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20335 for ; Tue, 7 Jan 2003 11:42:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07GqDJ01824; Tue, 7 Jan 2003 11:52:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07GlvJ01639 for ; Tue, 7 Jan 2003 11:47:57 -0500 Received: from ftpbox.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20158 for ; Tue, 7 Jan 2003 11:36:38 -0500 (EST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h07GdrQ5023823 for ; Tue, 7 Jan 2003 09:39:53 -0700 (MST) Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id JAA04231 for ; Tue, 7 Jan 2003 09:39:24 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Tue, 7 Jan 2003 10:39:52 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BD6B@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Erik.Nordmark@sun.com'" Cc: "'mankin@psg.com'" , "'James Kempf'" , "'Seamoby@ietf.org'" Subject: RE: [Seamoby] CARD - FMIPv6 protocol interworking Date: Tue, 7 Jan 2003 10:39:50 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Erik, Please find my inline reply. Regards, Ajoy -----Original Message----- From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] Sent: Monday, January 06, 2003 5:49 PM To: Singh Ajoy-ASINGH1 Cc: mankin@psg.com; erik.nordmark@sun.com; 'James Kempf'; Seamoby@ietf.org Subject: RE: [Seamoby] CARD - FMIPv6 protocol interworking > We have been discussion the possibility of > defining CARD signaling as generic ICMP options. > The idea is to allow piggybacking of > the generic ICMP options over any ICMP messages > including FMIPv6 messages (ProxyRouterSol and ProxyRouterAdv). > Do you see any issue this approach? James, has indicated > some potential issue in the attached email. > I would appreciate your comments. I don't have enough context to understand. Is this written up in an I-D already? AJOY-> The detailed text is not yet available. But some high-level description is available in section 6.1 of http://www.ietf.org/internet-drafts/draft-ietf-seamoby-card-protocol-00.txt. I assume you mean Neighbor Discovery options and not ICMP options since the ICMP message format doesn't have any options. AJOY-> Yes Erik _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Jan 7 11:42:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20380 for ; Tue, 7 Jan 2003 11:42:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h07GrX401910 for seamoby-archive@odin.ietf.org; Tue, 7 Jan 2003 11:53:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07GrWJ01907 for ; Tue, 7 Jan 2003 11:53:32 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20338 for ; Tue, 7 Jan 2003 11:42:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07GqDJ01824; Tue, 7 Jan 2003 11:52:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07GlvJ01639 for ; Tue, 7 Jan 2003 11:47:57 -0500 Received: from ftpbox.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20158 for ; Tue, 7 Jan 2003 11:36:38 -0500 (EST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h07GdrQ5023823 for ; Tue, 7 Jan 2003 09:39:53 -0700 (MST) Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id JAA04231 for ; Tue, 7 Jan 2003 09:39:24 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Tue, 7 Jan 2003 10:39:52 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BD6B@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Erik.Nordmark@sun.com'" Cc: "'mankin@psg.com'" , "'James Kempf'" , "'Seamoby@ietf.org'" Subject: RE: [Seamoby] CARD - FMIPv6 protocol interworking Date: Tue, 7 Jan 2003 10:39:50 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Erik, Please find my inline reply. Regards, Ajoy -----Original Message----- From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] Sent: Monday, January 06, 2003 5:49 PM To: Singh Ajoy-ASINGH1 Cc: mankin@psg.com; erik.nordmark@sun.com; 'James Kempf'; Seamoby@ietf.org Subject: RE: [Seamoby] CARD - FMIPv6 protocol interworking > We have been discussion the possibility of > defining CARD signaling as generic ICMP options. > The idea is to allow piggybacking of > the generic ICMP options over any ICMP messages > including FMIPv6 messages (ProxyRouterSol and ProxyRouterAdv). > Do you see any issue this approach? James, has indicated > some potential issue in the attached email. > I would appreciate your comments. I don't have enough context to understand. Is this written up in an I-D already? AJOY-> The detailed text is not yet available. But some high-level description is available in section 6.1 of http://www.ietf.org/internet-drafts/draft-ietf-seamoby-card-protocol-00.txt. I assume you mean Neighbor Discovery options and not ICMP options since the ICMP message format doesn't have any options. AJOY-> Yes Erik _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Jan 7 16:11:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28880 for ; Tue, 7 Jan 2003 16:11:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07LLGJ18715; Tue, 7 Jan 2003 16:21:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07KDoJ14952 for ; Tue, 7 Jan 2003 15:13:50 -0500 Received: from kathmandu.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26698 for ; Tue, 7 Jan 2003 15:02:26 -0500 (EST) Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA22540; Tue, 7 Jan 2003 13:05:41 -0700 (MST) Received: from localhost (dhcp-usun05-024-244.Eng.Sun.COM [129.144.24.244]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h07K5bP02758; Tue, 7 Jan 2003 21:05:38 +0100 (MET) Date: Tue, 7 Jan 2003 21:02:14 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: [Seamoby] CARD - FMIPv6 protocol interworking To: Singh Ajoy-ASINGH1 Cc: "'Erik Nordmark'" , mankin@psg.com, "'James Kempf'" , Seamoby@ietf.org In-Reply-To: "Your message with ID" <35DBB8B7AC89D4118E98009027B1009B0CD4BD68@IL27EXM10.cig.mot.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Part of the tradeoffs with piggybacking has to do with implementation considerations. In order to do piggybacking of CARD on e.g. FMIPv6 the same piece of software needs to implement both protocols. Thus you loose some implementation flexibility if you want piggybacking which, depending on how CARD and FMIPv6 are deployed, might make deployment harder. For instance, if FMIPv6 is already implemented and deployed by vendor X and Y but those vendors do not have plans to update their implementations to add CARD, then you can't really deploy CARD as an add-on piece of software that people can download. But if most people that are going to implement one of the protocols is going to implement the other as well then this wouldn't be a concern. So I think it all depends on whether most people view this as two pieces of the same protocol, or merely two different protocols operating between the same set of nodes. In the latter case I think you want the implementation flexibility of different implementors providing the different protocols for the same box. Erik _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Jan 7 16:12:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28915 for ; Tue, 7 Jan 2003 16:12:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h07LMti18764 for seamoby-archive@odin.ietf.org; Tue, 7 Jan 2003 16:22:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07LMtJ18761 for ; Tue, 7 Jan 2003 16:22:55 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28883 for ; Tue, 7 Jan 2003 16:11:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07LLGJ18715; Tue, 7 Jan 2003 16:21:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07KDoJ14952 for ; Tue, 7 Jan 2003 15:13:50 -0500 Received: from kathmandu.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26698 for ; Tue, 7 Jan 2003 15:02:26 -0500 (EST) Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA22540; Tue, 7 Jan 2003 13:05:41 -0700 (MST) Received: from localhost (dhcp-usun05-024-244.Eng.Sun.COM [129.144.24.244]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h07K5bP02758; Tue, 7 Jan 2003 21:05:38 +0100 (MET) Date: Tue, 7 Jan 2003 21:02:14 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: [Seamoby] CARD - FMIPv6 protocol interworking To: Singh Ajoy-ASINGH1 Cc: "'Erik Nordmark'" , mankin@psg.com, "'James Kempf'" , Seamoby@ietf.org In-Reply-To: "Your message with ID" <35DBB8B7AC89D4118E98009027B1009B0CD4BD68@IL27EXM10.cig.mot.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Part of the tradeoffs with piggybacking has to do with implementation considerations. In order to do piggybacking of CARD on e.g. FMIPv6 the same piece of software needs to implement both protocols. Thus you loose some implementation flexibility if you want piggybacking which, depending on how CARD and FMIPv6 are deployed, might make deployment harder. For instance, if FMIPv6 is already implemented and deployed by vendor X and Y but those vendors do not have plans to update their implementations to add CARD, then you can't really deploy CARD as an add-on piece of software that people can download. But if most people that are going to implement one of the protocols is going to implement the other as well then this wouldn't be a concern. So I think it all depends on whether most people view this as two pieces of the same protocol, or merely two different protocols operating between the same set of nodes. In the latter case I think you want the implementation flexibility of different implementors providing the different protocols for the same box. Erik _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Jan 7 17:16:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00997 for ; Tue, 7 Jan 2003 17:16:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07MQpJ22895; Tue, 7 Jan 2003 17:26:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07MEFJ22481 for ; Tue, 7 Jan 2003 17:14:15 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00681 for ; Tue, 7 Jan 2003 17:02:50 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h07M60E13911 for ; Tue, 7 Jan 2003 16:06:05 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 7 Jan 2003 16:05:51 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 7 Jan 2003 16:05:51 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CARD - FMIPv6 protocol interworking Date: Tue, 7 Jan 2003 17:05:50 -0500 Message-ID: Thread-Topic: [Seamoby] CARD - FMIPv6 protocol interworking Thread-Index: AcK2kaqF7VNgVuCpRuuXl9SCuzVWggABTtmw To: , Cc: , , X-OriginalArrivalTime: 07 Jan 2003 22:05:51.0821 (UTC) FILETIME=[F13A4FD0:01C2B698] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h07MEFJ22482 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Erik: Let me chip into the discussion. In the current CARD protocol draft, we have defined CARD ICMP type. This enables standalone implementation of CARD, independent of FMIPv6. There are two ICMP options for this type, namely, Request and Response. Each of those options have sub-options carrying CARD info. At the same time, to allow for integration with FMIPv6, if that is the implementers' choice, CARD Request and Response can be piggybacked on FMIPv6 signaling. This however, imposes the restriction that CARD signaling events must be aligned with FMIPv6 signaling events. To eliminate this restriction when integrating with FMIPv6, we were considering a possibility of the type, say, send Request in CARD ICMP type and possibly receive response in FMIPv6 message with CARD Response option piggybacked on it. For this however, Request and Response options need to have sequence ID field of their own. Please let us know about what you think about it. In particular, about the feasibility of mixed standalone and piggybacking. Regards, Hemant -----Original Message----- From: ext Erik Nordmark [mailto:Erik.Nordmark@sun.com] Sent: Tuesday, January 07, 2003 3:02 PM To: Singh Ajoy-ASINGH1 Cc: 'Erik Nordmark'; mankin@psg.com; 'James Kempf'; Seamoby@ietf.org Subject: RE: [Seamoby] CARD - FMIPv6 protocol interworking Part of the tradeoffs with piggybacking has to do with implementation considerations. In order to do piggybacking of CARD on e.g. FMIPv6 the same piece of software needs to implement both protocols. Thus you loose some implementation flexibility if you want piggybacking which, depending on how CARD and FMIPv6 are deployed, might make deployment harder. For instance, if FMIPv6 is already implemented and deployed by vendor X and Y but those vendors do not have plans to update their implementations to add CARD, then you can't really deploy CARD as an add-on piece of software that people can download. But if most people that are going to implement one of the protocols is going to implement the other as well then this wouldn't be a concern. So I think it all depends on whether most people view this as two pieces of the same protocol, or merely two different protocols operating between the same set of nodes. In the latter case I think you want the implementation flexibility of different implementors providing the different protocols for the same box. Erik _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Jan 7 17:17:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01023 for ; Tue, 7 Jan 2003 17:17:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h07MSPA22945 for seamoby-archive@odin.ietf.org; Tue, 7 Jan 2003 17:28:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07MSPJ22942 for ; Tue, 7 Jan 2003 17:28:25 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01000 for ; Tue, 7 Jan 2003 17:16:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07MQpJ22895; Tue, 7 Jan 2003 17:26:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07MEFJ22481 for ; Tue, 7 Jan 2003 17:14:15 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00681 for ; Tue, 7 Jan 2003 17:02:50 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h07M60E13911 for ; Tue, 7 Jan 2003 16:06:05 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 7 Jan 2003 16:05:51 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 7 Jan 2003 16:05:51 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CARD - FMIPv6 protocol interworking Date: Tue, 7 Jan 2003 17:05:50 -0500 Message-ID: Thread-Topic: [Seamoby] CARD - FMIPv6 protocol interworking Thread-Index: AcK2kaqF7VNgVuCpRuuXl9SCuzVWggABTtmw To: , Cc: , , X-OriginalArrivalTime: 07 Jan 2003 22:05:51.0821 (UTC) FILETIME=[F13A4FD0:01C2B698] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h07MEFJ22482 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Erik: Let me chip into the discussion. In the current CARD protocol draft, we have defined CARD ICMP type. This enables standalone implementation of CARD, independent of FMIPv6. There are two ICMP options for this type, namely, Request and Response. Each of those options have sub-options carrying CARD info. At the same time, to allow for integration with FMIPv6, if that is the implementers' choice, CARD Request and Response can be piggybacked on FMIPv6 signaling. This however, imposes the restriction that CARD signaling events must be aligned with FMIPv6 signaling events. To eliminate this restriction when integrating with FMIPv6, we were considering a possibility of the type, say, send Request in CARD ICMP type and possibly receive response in FMIPv6 message with CARD Response option piggybacked on it. For this however, Request and Response options need to have sequence ID field of their own. Please let us know about what you think about it. In particular, about the feasibility of mixed standalone and piggybacking. Regards, Hemant -----Original Message----- From: ext Erik Nordmark [mailto:Erik.Nordmark@sun.com] Sent: Tuesday, January 07, 2003 3:02 PM To: Singh Ajoy-ASINGH1 Cc: 'Erik Nordmark'; mankin@psg.com; 'James Kempf'; Seamoby@ietf.org Subject: RE: [Seamoby] CARD - FMIPv6 protocol interworking Part of the tradeoffs with piggybacking has to do with implementation considerations. In order to do piggybacking of CARD on e.g. FMIPv6 the same piece of software needs to implement both protocols. Thus you loose some implementation flexibility if you want piggybacking which, depending on how CARD and FMIPv6 are deployed, might make deployment harder. For instance, if FMIPv6 is already implemented and deployed by vendor X and Y but those vendors do not have plans to update their implementations to add CARD, then you can't really deploy CARD as an add-on piece of software that people can download. But if most people that are going to implement one of the protocols is going to implement the other as well then this wouldn't be a concern. So I think it all depends on whether most people view this as two pieces of the same protocol, or merely two different protocols operating between the same set of nodes. In the latter case I think you want the implementation flexibility of different implementors providing the different protocols for the same box. Erik _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Jan 7 18:01:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02153 for ; Tue, 7 Jan 2003 18:01:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07NBWJ26033; Tue, 7 Jan 2003 18:11:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07N5OJ25187 for ; Tue, 7 Jan 2003 18:05:24 -0500 Received: from motgate2.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01979 for ; Tue, 7 Jan 2003 17:53:58 -0500 (EST) Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h07MvarB017371 for ; Tue, 7 Jan 2003 15:57:36 -0700 (MST) Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id PAA16186 for ; Tue, 7 Jan 2003 15:57:13 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Tue, 7 Jan 2003 16:57:13 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BD75@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Erik Nordmark'" , Singh Ajoy-ASINGH1 Cc: mankin@psg.com, "'James Kempf'" , Seamoby@ietf.org, mobile-ip@sunroof.eng.sun.com Subject: RE: [Seamoby] CARD - FMIPv6 protocol interworking Date: Tue, 7 Jan 2003 16:57:12 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Erick, Thanks for your feedback. Please find my inline reply. I am also posting this to Mobile/IP WG as this may affect FMIPv6 protocol. Regards, Ajoy -----Original Message----- From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] Sent: Tuesday, January 07, 2003 2:02 PM To: Singh Ajoy-ASINGH1 Cc: 'Erik Nordmark'; mankin@psg.com; 'James Kempf'; Seamoby@ietf.org Subject: RE: [Seamoby] CARD - FMIPv6 protocol interworking Part of the tradeoffs with piggybacking has to do with implementation considerations. In order to do piggybacking of CARD on e.g. FMIPv6 the same piece of software needs to implement both protocols. Thus you loose some implementation flexibility if you want piggybacking which, depending on how CARD and FMIPv6 are deployed, might make deployment harder. For instance, if FMIPv6 is already implemented and deployed by vendor X and Y but those vendors do not have plans to update their implementations to add CARD, then you can't really deploy CARD as an add-on piece of software that people can download. AJOY-> Good point. So, I guess we should define both generic ICMP options as well as the carrier of the generic options (new messages) in the base CARD draft. This will eliminate the issue raised by you. Additionally, the FMIPv6 draft may describe how to piggyback CARD options on FMIPv6 messages. This will enable FMIPv6 implementation to take advantage of the efficient implementataion of the CARD. I do agree in this case both CARD and FMIPv6 must be developed by same vendor which is ok. But if most people that are going to implement one of the protocols is going to implement the other as well then this wouldn't be a concern. AJOY-> I think this will be the most common scenario. Hence, it makes sense to piggyback CARD options on FMIPv6 messages. But I guess this is mostly an FMIPv6 issue and probably should be addressed in FMIPv6 draft. What other's think? So I think it all depends on whether most people view this as two pieces of the same protocol, or merely two different protocols operating between the same set of nodes. In the latter case I think you want the implementation flexibility of different implementers providing the different protocols for the same box. Erik _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Jan 7 18:02:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02178 for ; Tue, 7 Jan 2003 18:02:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h07ND3r26057 for seamoby-archive@odin.ietf.org; Tue, 7 Jan 2003 18:13:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07ND3J26054 for ; Tue, 7 Jan 2003 18:13:03 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02156 for ; Tue, 7 Jan 2003 18:01:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07NBWJ26033; Tue, 7 Jan 2003 18:11:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07N5OJ25187 for ; Tue, 7 Jan 2003 18:05:24 -0500 Received: from motgate2.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01979 for ; Tue, 7 Jan 2003 17:53:58 -0500 (EST) Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h07MvarB017371 for ; Tue, 7 Jan 2003 15:57:36 -0700 (MST) Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id PAA16186 for ; Tue, 7 Jan 2003 15:57:13 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Tue, 7 Jan 2003 16:57:13 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BD75@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Erik Nordmark'" , Singh Ajoy-ASINGH1 Cc: mankin@psg.com, "'James Kempf'" , Seamoby@ietf.org, mobile-ip@sunroof.eng.sun.com Subject: RE: [Seamoby] CARD - FMIPv6 protocol interworking Date: Tue, 7 Jan 2003 16:57:12 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Erick, Thanks for your feedback. Please find my inline reply. I am also posting this to Mobile/IP WG as this may affect FMIPv6 protocol. Regards, Ajoy -----Original Message----- From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] Sent: Tuesday, January 07, 2003 2:02 PM To: Singh Ajoy-ASINGH1 Cc: 'Erik Nordmark'; mankin@psg.com; 'James Kempf'; Seamoby@ietf.org Subject: RE: [Seamoby] CARD - FMIPv6 protocol interworking Part of the tradeoffs with piggybacking has to do with implementation considerations. In order to do piggybacking of CARD on e.g. FMIPv6 the same piece of software needs to implement both protocols. Thus you loose some implementation flexibility if you want piggybacking which, depending on how CARD and FMIPv6 are deployed, might make deployment harder. For instance, if FMIPv6 is already implemented and deployed by vendor X and Y but those vendors do not have plans to update their implementations to add CARD, then you can't really deploy CARD as an add-on piece of software that people can download. AJOY-> Good point. So, I guess we should define both generic ICMP options as well as the carrier of the generic options (new messages) in the base CARD draft. This will eliminate the issue raised by you. Additionally, the FMIPv6 draft may describe how to piggyback CARD options on FMIPv6 messages. This will enable FMIPv6 implementation to take advantage of the efficient implementataion of the CARD. I do agree in this case both CARD and FMIPv6 must be developed by same vendor which is ok. But if most people that are going to implement one of the protocols is going to implement the other as well then this wouldn't be a concern. AJOY-> I think this will be the most common scenario. Hence, it makes sense to piggyback CARD options on FMIPv6 messages. But I guess this is mostly an FMIPv6 issue and probably should be addressed in FMIPv6 draft. What other's think? So I think it all depends on whether most people view this as two pieces of the same protocol, or merely two different protocols operating between the same set of nodes. In the latter case I think you want the implementation flexibility of different implementers providing the different protocols for the same box. Erik _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Jan 7 19:06:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04468 for ; Tue, 7 Jan 2003 19:06:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h080E8J30005; Tue, 7 Jan 2003 19:14:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0804AJ28998 for ; Tue, 7 Jan 2003 19:04:10 -0500 Received: from mailhost.iprg.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04007 for ; Tue, 7 Jan 2003 18:52:42 -0500 (EST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA26023; Tue, 7 Jan 2003 15:55:55 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h07NtsC06748; Tue, 7 Jan 2003 15:55:54 -0800 X-mProtect: <200301072355> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdFfv6Ks; Tue, 07 Jan 2003 15:55:53 PST Message-ID: <3E1B6909.551D4BC4@iprg.nokia.com> Date: Tue, 07 Jan 2003 15:55:53 -0800 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: Singh Ajoy-ASINGH1 , mankin@psg.com, "'James Kempf'" , Seamoby@ietf.org Subject: Re: [Seamoby] CARD - FMIPv6 protocol interworking References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Erik, Erik Nordmark wrote: > > So I think it all depends on whether most people view this as two pieces > of the same protocol, or merely two different protocols operating between > the same set of nodes. In the latter case I think you want the implementation > flexibility of different implementors providing the different protocols for > the same box. > I might add that CARD could define options for MN - AR exchange, specify that the two FMIPv6 messages be used whenever they are available. When FMIPv6 is not available for a CARD implementation, CARD _could_ use the same format as PrRtSol and PrRtAdv for its carrier. -Rajeev > > Erik > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Jan 7 19:08:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04538 for ; Tue, 7 Jan 2003 19:08:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h080JEm30342 for seamoby-archive@odin.ietf.org; Tue, 7 Jan 2003 19:19:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h080JEJ30339 for ; Tue, 7 Jan 2003 19:19:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04471 for ; Tue, 7 Jan 2003 19:06:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h080E8J30005; Tue, 7 Jan 2003 19:14:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0804AJ28998 for ; Tue, 7 Jan 2003 19:04:10 -0500 Received: from mailhost.iprg.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04007 for ; Tue, 7 Jan 2003 18:52:42 -0500 (EST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA26023; Tue, 7 Jan 2003 15:55:55 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h07NtsC06748; Tue, 7 Jan 2003 15:55:54 -0800 X-mProtect: <200301072355> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdFfv6Ks; Tue, 07 Jan 2003 15:55:53 PST Message-ID: <3E1B6909.551D4BC4@iprg.nokia.com> Date: Tue, 07 Jan 2003 15:55:53 -0800 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: Singh Ajoy-ASINGH1 , mankin@psg.com, "'James Kempf'" , Seamoby@ietf.org Subject: Re: [Seamoby] CARD - FMIPv6 protocol interworking References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Erik, Erik Nordmark wrote: > > So I think it all depends on whether most people view this as two pieces > of the same protocol, or merely two different protocols operating between > the same set of nodes. In the latter case I think you want the implementation > flexibility of different implementors providing the different protocols for > the same box. > I might add that CARD could define options for MN - AR exchange, specify that the two FMIPv6 messages be used whenever they are available. When FMIPv6 is not available for a CARD implementation, CARD _could_ use the same format as PrRtSol and PrRtAdv for its carrier. -Rajeev > > Erik > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Jan 8 08:34:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18904 for ; Wed, 8 Jan 2003 08:34:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08DikJ22033; Wed, 8 Jan 2003 08:44:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h082A7J05054 for ; Tue, 7 Jan 2003 21:10:07 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08215 for ; Tue, 7 Jan 2003 20:58:35 -0500 (EST) Message-ID: <060101c2b6b9$a7b49570$096015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Singh Ajoy-ASINGH1" , "'Erik Nordmark'" Cc: , "'James Kempf'" , , References: <35DBB8B7AC89D4118E98009027B1009B0CD4BD75@IL27EXM10.cig.mot.com> Subject: Re: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol interworking Date: Tue, 7 Jan 2003 17:59:58 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit We also need to look at the consumer(s) of CARD. If we are talking about mapping link-layer identifier of the next access router to its IP address and prefix information for fast handovers, FMIPv6 protocol already covers this funcitonality with PrRtSol and PrRtAdv. Are there other consumers, usage scenarios of CARD? alper > Erick, > Thanks for your feedback. Please find my > inline reply. I am also posting this to > Mobile/IP WG as this may affect > FMIPv6 protocol. > Regards, > Ajoy > > -----Original Message----- > From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] > Sent: Tuesday, January 07, 2003 2:02 PM > To: Singh Ajoy-ASINGH1 > Cc: 'Erik Nordmark'; mankin@psg.com; 'James Kempf'; Seamoby@ietf.org > Subject: RE: [Seamoby] CARD - FMIPv6 protocol interworking > > > > Part of the tradeoffs with piggybacking has to do with implementation > considerations. > In order to do piggybacking of CARD on e.g. FMIPv6 the same piece > of software needs to implement both protocols. Thus you loose some > implementation flexibility if you want piggybacking which, depending > on how CARD and FMIPv6 are deployed, might make deployment harder. > > For instance, if FMIPv6 is already implemented and deployed by vendor X and Y > but those vendors do not have plans to update their implementations to add > CARD, then you can't really deploy CARD as an add-on piece of software that > people can download. > > AJOY-> Good point. So, I guess we should define both generic ICMP options > as well as the carrier of the generic options (new messages) in the base CARD > draft. This will eliminate the issue raised by you. Additionally, the FMIPv6 > draft may describe how to piggyback CARD options on FMIPv6 messages. > This will enable FMIPv6 implementation to take advantage of the > efficient implementataion of the CARD. I do agree in this case both CARD > and FMIPv6 must be developed by same vendor which is ok. > > But if most people that are going to implement one of the protocols is > going to implement the other as well then this wouldn't be a concern. > > AJOY-> I think this will be the most common scenario. Hence, it makes > sense to piggyback CARD options on FMIPv6 messages. > But I guess this is mostly an FMIPv6 issue and probably should be addressed > in FMIPv6 draft. What other's think? > > So I think it all depends on whether most people view this as two pieces > of the same protocol, or merely two different protocols operating between > the same set of nodes. In the latter case I think you want the implementation > flexibility of different implementers providing the different protocols for > the same box. > > Erik > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Jan 8 08:35:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18935 for ; Wed, 8 Jan 2003 08:35:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08DkUH22110 for seamoby-archive@odin.ietf.org; Wed, 8 Jan 2003 08:46:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08DkTJ22107 for ; Wed, 8 Jan 2003 08:46:29 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18908 for ; Wed, 8 Jan 2003 08:34:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08DikJ22033; Wed, 8 Jan 2003 08:44:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h082A7J05054 for ; Tue, 7 Jan 2003 21:10:07 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08215 for ; Tue, 7 Jan 2003 20:58:35 -0500 (EST) Message-ID: <060101c2b6b9$a7b49570$096015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Singh Ajoy-ASINGH1" , "'Erik Nordmark'" Cc: , "'James Kempf'" , , References: <35DBB8B7AC89D4118E98009027B1009B0CD4BD75@IL27EXM10.cig.mot.com> Subject: Re: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol interworking Date: Tue, 7 Jan 2003 17:59:58 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit We also need to look at the consumer(s) of CARD. If we are talking about mapping link-layer identifier of the next access router to its IP address and prefix information for fast handovers, FMIPv6 protocol already covers this funcitonality with PrRtSol and PrRtAdv. Are there other consumers, usage scenarios of CARD? alper > Erick, > Thanks for your feedback. Please find my > inline reply. I am also posting this to > Mobile/IP WG as this may affect > FMIPv6 protocol. > Regards, > Ajoy > > -----Original Message----- > From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] > Sent: Tuesday, January 07, 2003 2:02 PM > To: Singh Ajoy-ASINGH1 > Cc: 'Erik Nordmark'; mankin@psg.com; 'James Kempf'; Seamoby@ietf.org > Subject: RE: [Seamoby] CARD - FMIPv6 protocol interworking > > > > Part of the tradeoffs with piggybacking has to do with implementation > considerations. > In order to do piggybacking of CARD on e.g. FMIPv6 the same piece > of software needs to implement both protocols. Thus you loose some > implementation flexibility if you want piggybacking which, depending > on how CARD and FMIPv6 are deployed, might make deployment harder. > > For instance, if FMIPv6 is already implemented and deployed by vendor X and Y > but those vendors do not have plans to update their implementations to add > CARD, then you can't really deploy CARD as an add-on piece of software that > people can download. > > AJOY-> Good point. So, I guess we should define both generic ICMP options > as well as the carrier of the generic options (new messages) in the base CARD > draft. This will eliminate the issue raised by you. Additionally, the FMIPv6 > draft may describe how to piggyback CARD options on FMIPv6 messages. > This will enable FMIPv6 implementation to take advantage of the > efficient implementataion of the CARD. I do agree in this case both CARD > and FMIPv6 must be developed by same vendor which is ok. > > But if most people that are going to implement one of the protocols is > going to implement the other as well then this wouldn't be a concern. > > AJOY-> I think this will be the most common scenario. Hence, it makes > sense to piggyback CARD options on FMIPv6 messages. > But I guess this is mostly an FMIPv6 issue and probably should be addressed > in FMIPv6 draft. What other's think? > > So I think it all depends on whether most people view this as two pieces > of the same protocol, or merely two different protocols operating between > the same set of nodes. In the latter case I think you want the implementation > flexibility of different implementers providing the different protocols for > the same box. > > Erik > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Jan 8 10:18:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22119 for ; Wed, 8 Jan 2003 10:18:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08FTKJ28895; Wed, 8 Jan 2003 10:29:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08FSPJ28852 for ; Wed, 8 Jan 2003 10:28:25 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22063 for ; Wed, 8 Jan 2003 10:16:39 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h08FJsE10670 for ; Wed, 8 Jan 2003 09:19:55 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 8 Jan 2003 09:19:49 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 8 Jan 2003 07:18:27 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Subject: RE: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol interworking Date: Wed, 8 Jan 2003 10:18:19 -0500 Message-ID: Thread-Topic: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol interworking Thread-Index: AcK3Gv2TjWba8vxUT92rABJGL34KzwADYN+A To: Cc: X-OriginalArrivalTime: 08 Jan 2003 15:18:27.0282 (UTC) FILETIME=[318F6B20:01C2B729] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h08FSPJ28853 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Alper, Comments inline. Cheers, Govind. -----Original Message----- From: ext Alper E. YEGIN [mailto:alper@docomolabs-usa.com] Sent: Tuesday, January 07, 2003 9:00 PM To: Singh Ajoy-ASINGH1; 'Erik Nordmark' Cc: mankin@psg.com; 'James Kempf'; Seamoby@ietf.org; mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol interworking We also need to look at the consumer(s) of CARD. If we are talking about mapping link-layer identifier of the next access router to its IP address and prefix information for fast handovers, FMIPv6 protocol already covers this funcitonality with PrRtSol and PrRtAdv. [Govind] What you describe there are carriers that take the messages from and to the MN. I don't think anyone is discounting the fact that if FMIPv6 is available and is adapted to the needs of CARD these messages can be used as carriers. However, CARD also talks about capabilities discovery and mapping capabilities to the requirements of the MN. Also, FMIPv6 needs "something" to fill in the mapping from link layer id to L3 id. CARD does that. Are there other consumers, usage scenarios of CARD? [Govind] Several potential uses are listed in the issues draft. alper > Erick, > Thanks for your feedback. Please find my > inline reply. I am also posting this to > Mobile/IP WG as this may affect > FMIPv6 protocol. > Regards, > Ajoy > > -----Original Message----- > From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] > Sent: Tuesday, January 07, 2003 2:02 PM > To: Singh Ajoy-ASINGH1 > Cc: 'Erik Nordmark'; mankin@psg.com; 'James Kempf'; Seamoby@ietf.org > Subject: RE: [Seamoby] CARD - FMIPv6 protocol interworking > > > > Part of the tradeoffs with piggybacking has to do with implementation > considerations. > In order to do piggybacking of CARD on e.g. FMIPv6 the same piece > of software needs to implement both protocols. Thus you loose some > implementation flexibility if you want piggybacking which, depending > on how CARD and FMIPv6 are deployed, might make deployment harder. > > For instance, if FMIPv6 is already implemented and deployed by vendor X and Y > but those vendors do not have plans to update their implementations to add > CARD, then you can't really deploy CARD as an add-on piece of software that > people can download. > > AJOY-> Good point. So, I guess we should define both generic ICMP options > as well as the carrier of the generic options (new messages) in the base CARD > draft. This will eliminate the issue raised by you. Additionally, the FMIPv6 > draft may describe how to piggyback CARD options on FMIPv6 messages. > This will enable FMIPv6 implementation to take advantage of the > efficient implementataion of the CARD. I do agree in this case both CARD > and FMIPv6 must be developed by same vendor which is ok. > > But if most people that are going to implement one of the protocols is > going to implement the other as well then this wouldn't be a concern. > > AJOY-> I think this will be the most common scenario. Hence, it makes > sense to piggyback CARD options on FMIPv6 messages. > But I guess this is mostly an FMIPv6 issue and probably should be addressed > in FMIPv6 draft. What other's think? > > So I think it all depends on whether most people view this as two pieces > of the same protocol, or merely two different protocols operating between > the same set of nodes. In the latter case I think you want the implementation > flexibility of different implementers providing the different protocols for > the same box. > > Erik > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Jan 8 10:20:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22176 for ; Wed, 8 Jan 2003 10:20:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08FVMm28985 for seamoby-archive@odin.ietf.org; Wed, 8 Jan 2003 10:31:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08FVMJ28982 for ; Wed, 8 Jan 2003 10:31:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22122 for ; Wed, 8 Jan 2003 10:18:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08FTKJ28895; Wed, 8 Jan 2003 10:29:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08FSPJ28852 for ; Wed, 8 Jan 2003 10:28:25 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22063 for ; Wed, 8 Jan 2003 10:16:39 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h08FJsE10670 for ; Wed, 8 Jan 2003 09:19:55 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 8 Jan 2003 09:19:49 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 8 Jan 2003 07:18:27 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Subject: RE: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol interworking Date: Wed, 8 Jan 2003 10:18:19 -0500 Message-ID: Thread-Topic: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol interworking Thread-Index: AcK3Gv2TjWba8vxUT92rABJGL34KzwADYN+A To: Cc: X-OriginalArrivalTime: 08 Jan 2003 15:18:27.0282 (UTC) FILETIME=[318F6B20:01C2B729] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h08FSPJ28853 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Alper, Comments inline. Cheers, Govind. -----Original Message----- From: ext Alper E. YEGIN [mailto:alper@docomolabs-usa.com] Sent: Tuesday, January 07, 2003 9:00 PM To: Singh Ajoy-ASINGH1; 'Erik Nordmark' Cc: mankin@psg.com; 'James Kempf'; Seamoby@ietf.org; mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol interworking We also need to look at the consumer(s) of CARD. If we are talking about mapping link-layer identifier of the next access router to its IP address and prefix information for fast handovers, FMIPv6 protocol already covers this funcitonality with PrRtSol and PrRtAdv. [Govind] What you describe there are carriers that take the messages from and to the MN. I don't think anyone is discounting the fact that if FMIPv6 is available and is adapted to the needs of CARD these messages can be used as carriers. However, CARD also talks about capabilities discovery and mapping capabilities to the requirements of the MN. Also, FMIPv6 needs "something" to fill in the mapping from link layer id to L3 id. CARD does that. Are there other consumers, usage scenarios of CARD? [Govind] Several potential uses are listed in the issues draft. alper > Erick, > Thanks for your feedback. Please find my > inline reply. I am also posting this to > Mobile/IP WG as this may affect > FMIPv6 protocol. > Regards, > Ajoy > > -----Original Message----- > From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] > Sent: Tuesday, January 07, 2003 2:02 PM > To: Singh Ajoy-ASINGH1 > Cc: 'Erik Nordmark'; mankin@psg.com; 'James Kempf'; Seamoby@ietf.org > Subject: RE: [Seamoby] CARD - FMIPv6 protocol interworking > > > > Part of the tradeoffs with piggybacking has to do with implementation > considerations. > In order to do piggybacking of CARD on e.g. FMIPv6 the same piece > of software needs to implement both protocols. Thus you loose some > implementation flexibility if you want piggybacking which, depending > on how CARD and FMIPv6 are deployed, might make deployment harder. > > For instance, if FMIPv6 is already implemented and deployed by vendor X and Y > but those vendors do not have plans to update their implementations to add > CARD, then you can't really deploy CARD as an add-on piece of software that > people can download. > > AJOY-> Good point. So, I guess we should define both generic ICMP options > as well as the carrier of the generic options (new messages) in the base CARD > draft. This will eliminate the issue raised by you. Additionally, the FMIPv6 > draft may describe how to piggyback CARD options on FMIPv6 messages. > This will enable FMIPv6 implementation to take advantage of the > efficient implementataion of the CARD. I do agree in this case both CARD > and FMIPv6 must be developed by same vendor which is ok. > > But if most people that are going to implement one of the protocols is > going to implement the other as well then this wouldn't be a concern. > > AJOY-> I think this will be the most common scenario. Hence, it makes > sense to piggyback CARD options on FMIPv6 messages. > But I guess this is mostly an FMIPv6 issue and probably should be addressed > in FMIPv6 draft. What other's think? > > So I think it all depends on whether most people view this as two pieces > of the same protocol, or merely two different protocols operating between > the same set of nodes. In the latter case I think you want the implementation > flexibility of different implementers providing the different protocols for > the same box. > > Erik > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Jan 8 13:00:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29677 for ; Wed, 8 Jan 2003 13:00:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08IAZJ09956; Wed, 8 Jan 2003 13:10:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08I9OJ09915 for ; Wed, 8 Jan 2003 13:09:24 -0500 Received: from mailhost.iprg.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29439 for ; Wed, 8 Jan 2003 12:57:34 -0500 (EST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA28972; Wed, 8 Jan 2003 10:00:44 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h08I0eD28382; Wed, 8 Jan 2003 10:00:40 -0800 X-mProtect: <200301081800> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdQnvWBU; Wed, 08 Jan 2003 10:00:38 PST Message-ID: <3E1C6747.7E6EB470@iprg.nokia.com> Date: Wed, 08 Jan 2003 10:00:39 -0800 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Govind.Krishnamurthi@nokia.com CC: alper@docomolabs-usa.com, Seamoby@ietf.org Subject: Re: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol interworking References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Govind, Govind.Krishnamurthi@nokia.com wrote: > > [Govind] What you describe there are carriers that take the messages from > and to the MN. I don't think anyone is discounting the fact that > if FMIPv6 is available and is adapted to the needs of CARD these > messages can be used as carriers. However, CARD also talks about > capabilities discovery and mapping capabilities to the requirements > of the MN. Also, FMIPv6 needs "something" to fill in the mapping > from link layer id to L3 id. CARD does that. This is not an accurate characterization. FMIPv6 can work without CARD. How the map containing the [AP-ID, AR-prefix] tuple is computed on the access router is orthogonal to the operation of FMIPv6. One could use CARD or static configuration, or any link state routing protocol (with extensions) for that matter to compute the map. -Rajeev > > > Are there other consumers, usage scenarios of CARD? > [Govind] Several potential uses are listed in the issues draft. > > alper > > > Erick, > > Thanks for your feedback. Please find my > > inline reply. I am also posting this to > > Mobile/IP WG as this may affect > > FMIPv6 protocol. > > Regards, > > Ajoy > > > > -----Original Message----- > > From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] > > Sent: Tuesday, January 07, 2003 2:02 PM > > To: Singh Ajoy-ASINGH1 > > Cc: 'Erik Nordmark'; mankin@psg.com; 'James Kempf'; Seamoby@ietf.org > > Subject: RE: [Seamoby] CARD - FMIPv6 protocol interworking > > > > > > > > Part of the tradeoffs with piggybacking has to do with implementation > > considerations. > > In order to do piggybacking of CARD on e.g. FMIPv6 the same piece > > of software needs to implement both protocols. Thus you loose some > > implementation flexibility if you want piggybacking which, depending > > on how CARD and FMIPv6 are deployed, might make deployment harder. > > > > For instance, if FMIPv6 is already implemented and deployed by vendor X > and Y > > but those vendors do not have plans to update their implementations to add > > CARD, then you can't really deploy CARD as an add-on piece of software > that > > people can download. > > > > AJOY-> Good point. So, I guess we should define both generic ICMP options > > as well as the carrier of the generic options (new messages) in the base > CARD > > draft. This will eliminate the issue raised by you. Additionally, the > FMIPv6 > > draft may describe how to piggyback CARD options on FMIPv6 messages. > > This will enable FMIPv6 implementation to take advantage of the > > efficient implementataion of the CARD. I do agree in this case both CARD > > and FMIPv6 must be developed by same vendor which is ok. > > > > But if most people that are going to implement one of the protocols is > > going to implement the other as well then this wouldn't be a concern. > > > > AJOY-> I think this will be the most common scenario. Hence, it makes > > sense to piggyback CARD options on FMIPv6 messages. > > But I guess this is mostly an FMIPv6 issue and probably should be > addressed > > in FMIPv6 draft. What other's think? > > > > So I think it all depends on whether most people view this as two pieces > > of the same protocol, or merely two different protocols operating between > > the same set of nodes. In the latter case I think you want the > implementation > > flexibility of different implementers providing the different protocols > for > > the same box. > > > > Erik > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Jan 8 13:01:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29733 for ; Wed, 8 Jan 2003 13:01:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08ICkM10016 for seamoby-archive@odin.ietf.org; Wed, 8 Jan 2003 13:12:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08ICjJ10013 for ; Wed, 8 Jan 2003 13:12:45 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29680 for ; Wed, 8 Jan 2003 13:00:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08IAZJ09956; Wed, 8 Jan 2003 13:10:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08I9OJ09915 for ; Wed, 8 Jan 2003 13:09:24 -0500 Received: from mailhost.iprg.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29439 for ; Wed, 8 Jan 2003 12:57:34 -0500 (EST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA28972; Wed, 8 Jan 2003 10:00:44 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h08I0eD28382; Wed, 8 Jan 2003 10:00:40 -0800 X-mProtect: <200301081800> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdQnvWBU; Wed, 08 Jan 2003 10:00:38 PST Message-ID: <3E1C6747.7E6EB470@iprg.nokia.com> Date: Wed, 08 Jan 2003 10:00:39 -0800 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Govind.Krishnamurthi@nokia.com CC: alper@docomolabs-usa.com, Seamoby@ietf.org Subject: Re: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol interworking References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Govind, Govind.Krishnamurthi@nokia.com wrote: > > [Govind] What you describe there are carriers that take the messages from > and to the MN. I don't think anyone is discounting the fact that > if FMIPv6 is available and is adapted to the needs of CARD these > messages can be used as carriers. However, CARD also talks about > capabilities discovery and mapping capabilities to the requirements > of the MN. Also, FMIPv6 needs "something" to fill in the mapping > from link layer id to L3 id. CARD does that. This is not an accurate characterization. FMIPv6 can work without CARD. How the map containing the [AP-ID, AR-prefix] tuple is computed on the access router is orthogonal to the operation of FMIPv6. One could use CARD or static configuration, or any link state routing protocol (with extensions) for that matter to compute the map. -Rajeev > > > Are there other consumers, usage scenarios of CARD? > [Govind] Several potential uses are listed in the issues draft. > > alper > > > Erick, > > Thanks for your feedback. Please find my > > inline reply. I am also posting this to > > Mobile/IP WG as this may affect > > FMIPv6 protocol. > > Regards, > > Ajoy > > > > -----Original Message----- > > From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] > > Sent: Tuesday, January 07, 2003 2:02 PM > > To: Singh Ajoy-ASINGH1 > > Cc: 'Erik Nordmark'; mankin@psg.com; 'James Kempf'; Seamoby@ietf.org > > Subject: RE: [Seamoby] CARD - FMIPv6 protocol interworking > > > > > > > > Part of the tradeoffs with piggybacking has to do with implementation > > considerations. > > In order to do piggybacking of CARD on e.g. FMIPv6 the same piece > > of software needs to implement both protocols. Thus you loose some > > implementation flexibility if you want piggybacking which, depending > > on how CARD and FMIPv6 are deployed, might make deployment harder. > > > > For instance, if FMIPv6 is already implemented and deployed by vendor X > and Y > > but those vendors do not have plans to update their implementations to add > > CARD, then you can't really deploy CARD as an add-on piece of software > that > > people can download. > > > > AJOY-> Good point. So, I guess we should define both generic ICMP options > > as well as the carrier of the generic options (new messages) in the base > CARD > > draft. This will eliminate the issue raised by you. Additionally, the > FMIPv6 > > draft may describe how to piggyback CARD options on FMIPv6 messages. > > This will enable FMIPv6 implementation to take advantage of the > > efficient implementataion of the CARD. I do agree in this case both CARD > > and FMIPv6 must be developed by same vendor which is ok. > > > > But if most people that are going to implement one of the protocols is > > going to implement the other as well then this wouldn't be a concern. > > > > AJOY-> I think this will be the most common scenario. Hence, it makes > > sense to piggyback CARD options on FMIPv6 messages. > > But I guess this is mostly an FMIPv6 issue and probably should be > addressed > > in FMIPv6 draft. What other's think? > > > > So I think it all depends on whether most people view this as two pieces > > of the same protocol, or merely two different protocols operating between > > the same set of nodes. In the latter case I think you want the > implementation > > flexibility of different implementers providing the different protocols > for > > the same box. > > > > Erik > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Jan 8 13:05:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29930 for ; Wed, 8 Jan 2003 13:05:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08IG5J10157; Wed, 8 Jan 2003 13:16:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08IFFJ10114 for ; Wed, 8 Jan 2003 13:15:15 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29846 for ; Wed, 8 Jan 2003 13:03:25 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h08I6iE21946 for ; Wed, 8 Jan 2003 12:06:44 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 8 Jan 2003 12:06:39 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 8 Jan 2003 12:06:01 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol interworking Date: Wed, 8 Jan 2003 13:06:00 -0500 Message-ID: Thread-Topic: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol interworking Thread-Index: AcK3P98yuh61NYsyTeWsYNP8m1QulAAABEnA To: Cc: , X-OriginalArrivalTime: 08 Jan 2003 18:06:01.0482 (UTC) FILETIME=[9A5496A0:01C2B740] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h08IFFJ10115 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Rajeev, What you describe as alternatives is just ways of performing CARD IMO, each one having pros and cons. One of the functionalities of CARD (however you do it) is to fill up this mapping table. Doing it statically is just one way of doing it. Govind. -----Original Message----- From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] Sent: Wednesday, January 08, 2003 1:01 PM To: Krishnamurthi Govind (NRC/Boston) Cc: alper@docomolabs-usa.com; Seamoby@ietf.org Subject: Re: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol interworking Govind, Govind.Krishnamurthi@nokia.com wrote: > > [Govind] What you describe there are carriers that take the messages from > and to the MN. I don't think anyone is discounting the fact that > if FMIPv6 is available and is adapted to the needs of CARD these > messages can be used as carriers. However, CARD also talks about > capabilities discovery and mapping capabilities to the requirements > of the MN. Also, FMIPv6 needs "something" to fill in the mapping > from link layer id to L3 id. CARD does that. This is not an accurate characterization. FMIPv6 can work without CARD. How the map containing the [AP-ID, AR-prefix] tuple is computed on the access router is orthogonal to the operation of FMIPv6. One could use CARD or static configuration, or any link state routing protocol (with extensions) for that matter to compute the map. -Rajeev > > > Are there other consumers, usage scenarios of CARD? > [Govind] Several potential uses are listed in the issues draft. > > alper > > > Erick, > > Thanks for your feedback. Please find my > > inline reply. I am also posting this to > > Mobile/IP WG as this may affect > > FMIPv6 protocol. > > Regards, > > Ajoy > > > > -----Original Message----- > > From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] > > Sent: Tuesday, January 07, 2003 2:02 PM > > To: Singh Ajoy-ASINGH1 > > Cc: 'Erik Nordmark'; mankin@psg.com; 'James Kempf'; Seamoby@ietf.org > > Subject: RE: [Seamoby] CARD - FMIPv6 protocol interworking > > > > > > > > Part of the tradeoffs with piggybacking has to do with implementation > > considerations. > > In order to do piggybacking of CARD on e.g. FMIPv6 the same piece > > of software needs to implement both protocols. Thus you loose some > > implementation flexibility if you want piggybacking which, depending > > on how CARD and FMIPv6 are deployed, might make deployment harder. > > > > For instance, if FMIPv6 is already implemented and deployed by vendor X > and Y > > but those vendors do not have plans to update their implementations to add > > CARD, then you can't really deploy CARD as an add-on piece of software > that > > people can download. > > > > AJOY-> Good point. So, I guess we should define both generic ICMP options > > as well as the carrier of the generic options (new messages) in the base > CARD > > draft. This will eliminate the issue raised by you. Additionally, the > FMIPv6 > > draft may describe how to piggyback CARD options on FMIPv6 messages. > > This will enable FMIPv6 implementation to take advantage of the > > efficient implementataion of the CARD. I do agree in this case both CARD > > and FMIPv6 must be developed by same vendor which is ok. > > > > But if most people that are going to implement one of the protocols is > > going to implement the other as well then this wouldn't be a concern. > > > > AJOY-> I think this will be the most common scenario. Hence, it makes > > sense to piggyback CARD options on FMIPv6 messages. > > But I guess this is mostly an FMIPv6 issue and probably should be > addressed > > in FMIPv6 draft. What other's think? > > > > So I think it all depends on whether most people view this as two pieces > > of the same protocol, or merely two different protocols operating between > > the same set of nodes. In the latter case I think you want the > implementation > > flexibility of different implementers providing the different protocols > for > > the same box. > > > > Erik > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Jan 8 13:06:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29956 for ; Wed, 8 Jan 2003 13:06:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08IHVL10221 for seamoby-archive@odin.ietf.org; Wed, 8 Jan 2003 13:17:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08IHVJ10218 for ; Wed, 8 Jan 2003 13:17:31 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29933 for ; Wed, 8 Jan 2003 13:05:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08IG5J10157; Wed, 8 Jan 2003 13:16:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08IFFJ10114 for ; Wed, 8 Jan 2003 13:15:15 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29846 for ; Wed, 8 Jan 2003 13:03:25 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h08I6iE21946 for ; Wed, 8 Jan 2003 12:06:44 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 8 Jan 2003 12:06:39 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 8 Jan 2003 12:06:01 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol interworking Date: Wed, 8 Jan 2003 13:06:00 -0500 Message-ID: Thread-Topic: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol interworking Thread-Index: AcK3P98yuh61NYsyTeWsYNP8m1QulAAABEnA To: Cc: , X-OriginalArrivalTime: 08 Jan 2003 18:06:01.0482 (UTC) FILETIME=[9A5496A0:01C2B740] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h08IFFJ10115 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Rajeev, What you describe as alternatives is just ways of performing CARD IMO, each one having pros and cons. One of the functionalities of CARD (however you do it) is to fill up this mapping table. Doing it statically is just one way of doing it. Govind. -----Original Message----- From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] Sent: Wednesday, January 08, 2003 1:01 PM To: Krishnamurthi Govind (NRC/Boston) Cc: alper@docomolabs-usa.com; Seamoby@ietf.org Subject: Re: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol interworking Govind, Govind.Krishnamurthi@nokia.com wrote: > > [Govind] What you describe there are carriers that take the messages from > and to the MN. I don't think anyone is discounting the fact that > if FMIPv6 is available and is adapted to the needs of CARD these > messages can be used as carriers. However, CARD also talks about > capabilities discovery and mapping capabilities to the requirements > of the MN. Also, FMIPv6 needs "something" to fill in the mapping > from link layer id to L3 id. CARD does that. This is not an accurate characterization. FMIPv6 can work without CARD. How the map containing the [AP-ID, AR-prefix] tuple is computed on the access router is orthogonal to the operation of FMIPv6. One could use CARD or static configuration, or any link state routing protocol (with extensions) for that matter to compute the map. -Rajeev > > > Are there other consumers, usage scenarios of CARD? > [Govind] Several potential uses are listed in the issues draft. > > alper > > > Erick, > > Thanks for your feedback. Please find my > > inline reply. I am also posting this to > > Mobile/IP WG as this may affect > > FMIPv6 protocol. > > Regards, > > Ajoy > > > > -----Original Message----- > > From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] > > Sent: Tuesday, January 07, 2003 2:02 PM > > To: Singh Ajoy-ASINGH1 > > Cc: 'Erik Nordmark'; mankin@psg.com; 'James Kempf'; Seamoby@ietf.org > > Subject: RE: [Seamoby] CARD - FMIPv6 protocol interworking > > > > > > > > Part of the tradeoffs with piggybacking has to do with implementation > > considerations. > > In order to do piggybacking of CARD on e.g. FMIPv6 the same piece > > of software needs to implement both protocols. Thus you loose some > > implementation flexibility if you want piggybacking which, depending > > on how CARD and FMIPv6 are deployed, might make deployment harder. > > > > For instance, if FMIPv6 is already implemented and deployed by vendor X > and Y > > but those vendors do not have plans to update their implementations to add > > CARD, then you can't really deploy CARD as an add-on piece of software > that > > people can download. > > > > AJOY-> Good point. So, I guess we should define both generic ICMP options > > as well as the carrier of the generic options (new messages) in the base > CARD > > draft. This will eliminate the issue raised by you. Additionally, the > FMIPv6 > > draft may describe how to piggyback CARD options on FMIPv6 messages. > > This will enable FMIPv6 implementation to take advantage of the > > efficient implementataion of the CARD. I do agree in this case both CARD > > and FMIPv6 must be developed by same vendor which is ok. > > > > But if most people that are going to implement one of the protocols is > > going to implement the other as well then this wouldn't be a concern. > > > > AJOY-> I think this will be the most common scenario. Hence, it makes > > sense to piggyback CARD options on FMIPv6 messages. > > But I guess this is mostly an FMIPv6 issue and probably should be > addressed > > in FMIPv6 draft. What other's think? > > > > So I think it all depends on whether most people view this as two pieces > > of the same protocol, or merely two different protocols operating between > > the same set of nodes. In the latter case I think you want the > implementation > > flexibility of different implementers providing the different protocols > for > > the same box. > > > > Erik > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Jan 8 13:08:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00020 for ; Wed, 8 Jan 2003 13:08:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08IJ3J10312; Wed, 8 Jan 2003 13:19:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08IIKJ10271 for ; Wed, 8 Jan 2003 13:18:20 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29975 for ; Wed, 8 Jan 2003 13:06:30 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h08I9oE22694 for ; Wed, 8 Jan 2003 12:09:50 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 8 Jan 2003 12:09:45 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 8 Jan 2003 10:08:28 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol interworking Date: Wed, 8 Jan 2003 13:08:27 -0500 Message-ID: Thread-Topic: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol interworking Thread-Index: AcK3QCZ7pi4qFkUGQPKTzKrsGDXkXgAAB3vA To: , Cc: , X-OriginalArrivalTime: 08 Jan 2003 18:08:28.0972 (UTC) FILETIME=[F23DC6C0:01C2B740] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h08IIKJ10272 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Rajeev: As you say, the L2 ID - IP address mapping is orthogonal to FMIPv6. Well, but it is very much essential component of CARD, according to CARD problem statement. Whether to use that component in FMIPv6 or not is implementer's choice. Hemant -----Original Message----- From: ext Rajeev Koodli [mailto:rajeev@iprg.nokia.com] Sent: Wednesday, January 08, 2003 1:01 PM To: Krishnamurthi Govind (NRC/Boston) Cc: alper@docomolabs-usa.com; Seamoby@ietf.org Subject: Re: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol interworking Govind, Govind.Krishnamurthi@nokia.com wrote: > > [Govind] What you describe there are carriers that take the messages from > and to the MN. I don't think anyone is discounting the fact that > if FMIPv6 is available and is adapted to the needs of CARD these > messages can be used as carriers. However, CARD also talks about > capabilities discovery and mapping capabilities to the requirements > of the MN. Also, FMIPv6 needs "something" to fill in the mapping > from link layer id to L3 id. CARD does that. This is not an accurate characterization. FMIPv6 can work without CARD. How the map containing the [AP-ID, AR-prefix] tuple is computed on the access router is orthogonal to the operation of FMIPv6. One could use CARD or static configuration, or any link state routing protocol (with extensions) for that matter to compute the map. -Rajeev > > > Are there other consumers, usage scenarios of CARD? > [Govind] Several potential uses are listed in the issues draft. > > alper > > > Erick, > > Thanks for your feedback. Please find my > > inline reply. I am also posting this to > > Mobile/IP WG as this may affect > > FMIPv6 protocol. > > Regards, > > Ajoy > > > > -----Original Message----- > > From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] > > Sent: Tuesday, January 07, 2003 2:02 PM > > To: Singh Ajoy-ASINGH1 > > Cc: 'Erik Nordmark'; mankin@psg.com; 'James Kempf'; Seamoby@ietf.org > > Subject: RE: [Seamoby] CARD - FMIPv6 protocol interworking > > > > > > > > Part of the tradeoffs with piggybacking has to do with implementation > > considerations. > > In order to do piggybacking of CARD on e.g. FMIPv6 the same piece > > of software needs to implement both protocols. Thus you loose some > > implementation flexibility if you want piggybacking which, depending > > on how CARD and FMIPv6 are deployed, might make deployment harder. > > > > For instance, if FMIPv6 is already implemented and deployed by vendor X > and Y > > but those vendors do not have plans to update their implementations to add > > CARD, then you can't really deploy CARD as an add-on piece of software > that > > people can download. > > > > AJOY-> Good point. So, I guess we should define both generic ICMP options > > as well as the carrier of the generic options (new messages) in the base > CARD > > draft. This will eliminate the issue raised by you. Additionally, the > FMIPv6 > > draft may describe how to piggyback CARD options on FMIPv6 messages. > > This will enable FMIPv6 implementation to take advantage of the > > efficient implementataion of the CARD. I do agree in this case both CARD > > and FMIPv6 must be developed by same vendor which is ok. > > > > But if most people that are going to implement one of the protocols is > > going to implement the other as well then this wouldn't be a concern. > > > > AJOY-> I think this will be the most common scenario. Hence, it makes > > sense to piggyback CARD options on FMIPv6 messages. > > But I guess this is mostly an FMIPv6 issue and probably should be > addressed > > in FMIPv6 draft. What other's think? > > > > So I think it all depends on whether most people view this as two pieces > > of the same protocol, or merely two different protocols operating between > > the same set of nodes. In the latter case I think you want the > implementation > > flexibility of different implementers providing the different protocols > for > > the same box. > > > > Erik > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Jan 8 13:08:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00051 for ; Wed, 8 Jan 2003 13:08:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08IJx610344 for seamoby-archive@odin.ietf.org; Wed, 8 Jan 2003 13:19:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08IJwJ10341 for ; Wed, 8 Jan 2003 13:19:58 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00024 for ; Wed, 8 Jan 2003 13:08:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08IJ3J10312; Wed, 8 Jan 2003 13:19:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08IIKJ10271 for ; Wed, 8 Jan 2003 13:18:20 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29975 for ; Wed, 8 Jan 2003 13:06:30 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h08I9oE22694 for ; Wed, 8 Jan 2003 12:09:50 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 8 Jan 2003 12:09:45 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 8 Jan 2003 10:08:28 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol interworking Date: Wed, 8 Jan 2003 13:08:27 -0500 Message-ID: Thread-Topic: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol interworking Thread-Index: AcK3QCZ7pi4qFkUGQPKTzKrsGDXkXgAAB3vA To: , Cc: , X-OriginalArrivalTime: 08 Jan 2003 18:08:28.0972 (UTC) FILETIME=[F23DC6C0:01C2B740] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h08IIKJ10272 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Rajeev: As you say, the L2 ID - IP address mapping is orthogonal to FMIPv6. Well, but it is very much essential component of CARD, according to CARD problem statement. Whether to use that component in FMIPv6 or not is implementer's choice. Hemant -----Original Message----- From: ext Rajeev Koodli [mailto:rajeev@iprg.nokia.com] Sent: Wednesday, January 08, 2003 1:01 PM To: Krishnamurthi Govind (NRC/Boston) Cc: alper@docomolabs-usa.com; Seamoby@ietf.org Subject: Re: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol interworking Govind, Govind.Krishnamurthi@nokia.com wrote: > > [Govind] What you describe there are carriers that take the messages from > and to the MN. I don't think anyone is discounting the fact that > if FMIPv6 is available and is adapted to the needs of CARD these > messages can be used as carriers. However, CARD also talks about > capabilities discovery and mapping capabilities to the requirements > of the MN. Also, FMIPv6 needs "something" to fill in the mapping > from link layer id to L3 id. CARD does that. This is not an accurate characterization. FMIPv6 can work without CARD. How the map containing the [AP-ID, AR-prefix] tuple is computed on the access router is orthogonal to the operation of FMIPv6. One could use CARD or static configuration, or any link state routing protocol (with extensions) for that matter to compute the map. -Rajeev > > > Are there other consumers, usage scenarios of CARD? > [Govind] Several potential uses are listed in the issues draft. > > alper > > > Erick, > > Thanks for your feedback. Please find my > > inline reply. I am also posting this to > > Mobile/IP WG as this may affect > > FMIPv6 protocol. > > Regards, > > Ajoy > > > > -----Original Message----- > > From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] > > Sent: Tuesday, January 07, 2003 2:02 PM > > To: Singh Ajoy-ASINGH1 > > Cc: 'Erik Nordmark'; mankin@psg.com; 'James Kempf'; Seamoby@ietf.org > > Subject: RE: [Seamoby] CARD - FMIPv6 protocol interworking > > > > > > > > Part of the tradeoffs with piggybacking has to do with implementation > > considerations. > > In order to do piggybacking of CARD on e.g. FMIPv6 the same piece > > of software needs to implement both protocols. Thus you loose some > > implementation flexibility if you want piggybacking which, depending > > on how CARD and FMIPv6 are deployed, might make deployment harder. > > > > For instance, if FMIPv6 is already implemented and deployed by vendor X > and Y > > but those vendors do not have plans to update their implementations to add > > CARD, then you can't really deploy CARD as an add-on piece of software > that > > people can download. > > > > AJOY-> Good point. So, I guess we should define both generic ICMP options > > as well as the carrier of the generic options (new messages) in the base > CARD > > draft. This will eliminate the issue raised by you. Additionally, the > FMIPv6 > > draft may describe how to piggyback CARD options on FMIPv6 messages. > > This will enable FMIPv6 implementation to take advantage of the > > efficient implementataion of the CARD. I do agree in this case both CARD > > and FMIPv6 must be developed by same vendor which is ok. > > > > But if most people that are going to implement one of the protocols is > > going to implement the other as well then this wouldn't be a concern. > > > > AJOY-> I think this will be the most common scenario. Hence, it makes > > sense to piggyback CARD options on FMIPv6 messages. > > But I guess this is mostly an FMIPv6 issue and probably should be > addressed > > in FMIPv6 draft. What other's think? > > > > So I think it all depends on whether most people view this as two pieces > > of the same protocol, or merely two different protocols operating between > > the same set of nodes. In the latter case I think you want the > implementation > > flexibility of different implementers providing the different protocols > for > > the same box. > > > > Erik > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Jan 8 14:13:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02740 for ; Wed, 8 Jan 2003 14:13:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08JNmJ14964; Wed, 8 Jan 2003 14:23:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08JMnJ14915 for ; Wed, 8 Jan 2003 14:22:49 -0500 Received: from motgate3.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02600 for ; Wed, 8 Jan 2003 14:10:57 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h08JDGMQ010325 for ; Wed, 8 Jan 2003 12:13:16 -0700 (MST) Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id MAA29804 for ; Wed, 8 Jan 2003 12:14:12 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Wed, 8 Jan 2003 13:14:12 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BD77@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Alper E. YEGIN'" , Singh Ajoy-ASINGH1 , "'Erik Nordmark'" Cc: mankin@psg.com, "'James Kempf'" , Seamoby@ietf.org, mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol interworking Date: Wed, 8 Jan 2003 13:14:11 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , -----Original Message----- From: Alper E. YEGIN [mailto:alper@docomolabs-usa.com] Sent: Tuesday, January 07, 2003 8:00 PM To: Singh Ajoy-ASINGH1; 'Erik Nordmark' Cc: mankin@psg.com; 'James Kempf'; Seamoby@ietf.org; mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol interworking We also need to look at the consumer(s) of CARD. If we are talking about mapping link-layer identifier of the next access router to its IP address and prefix information for fast handovers, FMIPv6 protocol already covers this funcitonality with PrRtSol and PrRtAdv Are there other consumers, usage scenarios of CARD? AJOY-> CARD has two components: 1. L2-L3 address mapping 2. Capability discovery of neighboring AR. Perhaps the capability discovery feature of the CARD may be useful for any handoff including fast handoff. The CARD may be used in case of standard Mobile/IP if MN is capable to perform make before break IP layer handoff. Perhaps this feature will be applicable for inter-technology handoff with overlapping coverage area. Any comments? alper > Erick, > Thanks for your feedback. Please find my > inline reply. I am also posting this to > Mobile/IP WG as this may affect > FMIPv6 protocol. > Regards, > Ajoy > > -----Original Message----- > From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] > Sent: Tuesday, January 07, 2003 2:02 PM > To: Singh Ajoy-ASINGH1 > Cc: 'Erik Nordmark'; mankin@psg.com; 'James Kempf'; Seamoby@ietf.org > Subject: RE: [Seamoby] CARD - FMIPv6 protocol interworking > > > > Part of the tradeoffs with piggybacking has to do with implementation > considerations. > In order to do piggybacking of CARD on e.g. FMIPv6 the same piece > of software needs to implement both protocols. Thus you loose some > implementation flexibility if you want piggybacking which, depending > on how CARD and FMIPv6 are deployed, might make deployment harder. > > For instance, if FMIPv6 is already implemented and deployed by vendor X and Y > but those vendors do not have plans to update their implementations to add > CARD, then you can't really deploy CARD as an add-on piece of software that > people can download. > > AJOY-> Good point. So, I guess we should define both generic ICMP options > as well as the carrier of the generic options (new messages) in the base CARD > draft. This will eliminate the issue raised by you. Additionally, the FMIPv6 > draft may describe how to piggyback CARD options on FMIPv6 messages. > This will enable FMIPv6 implementation to take advantage of the > efficient implementataion of the CARD. I do agree in this case both CARD > and FMIPv6 must be developed by same vendor which is ok. > > But if most people that are going to implement one of the protocols is > going to implement the other as well then this wouldn't be a concern. > > AJOY-> I think this will be the most common scenario. Hence, it makes > sense to piggyback CARD options on FMIPv6 messages. > But I guess this is mostly an FMIPv6 issue and probably should be addressed > in FMIPv6 draft. What other's think? > > So I think it all depends on whether most people view this as two pieces > of the same protocol, or merely two different protocols operating between > the same set of nodes. In the latter case I think you want the implementation > flexibility of different implementers providing the different protocols for > the same box. > > Erik > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Jan 8 14:14:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02793 for ; Wed, 8 Jan 2003 14:14:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08JPBJ15056; Wed, 8 Jan 2003 14:25:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08JOTJ15011 for ; Wed, 8 Jan 2003 14:24:29 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02690 for ; Wed, 8 Jan 2003 14:12:38 -0500 (EST) Message-ID: <015501c2b74a$1e4338a0$506015ac@T23KEMPF> From: "James Kempf" To: "Rajeev Koodli" , Cc: , References: <3E1C6747.7E6EB470@iprg.nokia.com> Subject: Re: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol interworking Date: Wed, 8 Jan 2003 11:14:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Rajeev, > This is not an accurate characterization. FMIPv6 can work without CARD. > How the map containing the [AP-ID, AR-prefix] tuple is computed on the > access router is orthogonal to the operation of FMIPv6. One could use CARD > or static configuration, or any link state routing protocol (with extensions) > for > that matter to compute the map. > Of course, the link state routing protocol extensions might be viewed as a kind of CARD for routers. Or some other inter-router protocol. This is an area that currently isn't touched in the initial CARD design document, I believe. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Jan 8 14:15:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02924 for ; Wed, 8 Jan 2003 14:15:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08JQiU15139 for seamoby-archive@odin.ietf.org; Wed, 8 Jan 2003 14:26:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08JQiJ15136 for ; Wed, 8 Jan 2003 14:26:44 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02797 for ; Wed, 8 Jan 2003 14:14:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08JPBJ15056; Wed, 8 Jan 2003 14:25:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08JOTJ15011 for ; Wed, 8 Jan 2003 14:24:29 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02690 for ; Wed, 8 Jan 2003 14:12:38 -0500 (EST) Message-ID: <015501c2b74a$1e4338a0$506015ac@T23KEMPF> From: "James Kempf" To: "Rajeev Koodli" , Cc: , References: <3E1C6747.7E6EB470@iprg.nokia.com> Subject: Re: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol interworking Date: Wed, 8 Jan 2003 11:14:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Rajeev, > This is not an accurate characterization. FMIPv6 can work without CARD. > How the map containing the [AP-ID, AR-prefix] tuple is computed on the > access router is orthogonal to the operation of FMIPv6. One could use CARD > or static configuration, or any link state routing protocol (with extensions) > for > that matter to compute the map. > Of course, the link state routing protocol extensions might be viewed as a kind of CARD for routers. Or some other inter-router protocol. This is an area that currently isn't touched in the initial CARD design document, I believe. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Jan 8 14:14:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02813 for ; Wed, 8 Jan 2003 14:14:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08JPlq15087 for seamoby-archive@odin.ietf.org; Wed, 8 Jan 2003 14:25:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08JPkJ15084 for ; Wed, 8 Jan 2003 14:25:46 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02745 for ; Wed, 8 Jan 2003 14:13:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08JNmJ14964; Wed, 8 Jan 2003 14:23:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08JMnJ14915 for ; Wed, 8 Jan 2003 14:22:49 -0500 Received: from motgate3.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02600 for ; Wed, 8 Jan 2003 14:10:57 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h08JDGMQ010325 for ; Wed, 8 Jan 2003 12:13:16 -0700 (MST) Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id MAA29804 for ; Wed, 8 Jan 2003 12:14:12 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Wed, 8 Jan 2003 13:14:12 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0CD4BD77@IL27EXM10.cig.mot.com> From: Singh Ajoy-ASINGH1 To: "'Alper E. YEGIN'" , Singh Ajoy-ASINGH1 , "'Erik Nordmark'" Cc: mankin@psg.com, "'James Kempf'" , Seamoby@ietf.org, mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol interworking Date: Wed, 8 Jan 2003 13:14:11 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , -----Original Message----- From: Alper E. YEGIN [mailto:alper@docomolabs-usa.com] Sent: Tuesday, January 07, 2003 8:00 PM To: Singh Ajoy-ASINGH1; 'Erik Nordmark' Cc: mankin@psg.com; 'James Kempf'; Seamoby@ietf.org; mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol interworking We also need to look at the consumer(s) of CARD. If we are talking about mapping link-layer identifier of the next access router to its IP address and prefix information for fast handovers, FMIPv6 protocol already covers this funcitonality with PrRtSol and PrRtAdv Are there other consumers, usage scenarios of CARD? AJOY-> CARD has two components: 1. L2-L3 address mapping 2. Capability discovery of neighboring AR. Perhaps the capability discovery feature of the CARD may be useful for any handoff including fast handoff. The CARD may be used in case of standard Mobile/IP if MN is capable to perform make before break IP layer handoff. Perhaps this feature will be applicable for inter-technology handoff with overlapping coverage area. Any comments? alper > Erick, > Thanks for your feedback. Please find my > inline reply. I am also posting this to > Mobile/IP WG as this may affect > FMIPv6 protocol. > Regards, > Ajoy > > -----Original Message----- > From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] > Sent: Tuesday, January 07, 2003 2:02 PM > To: Singh Ajoy-ASINGH1 > Cc: 'Erik Nordmark'; mankin@psg.com; 'James Kempf'; Seamoby@ietf.org > Subject: RE: [Seamoby] CARD - FMIPv6 protocol interworking > > > > Part of the tradeoffs with piggybacking has to do with implementation > considerations. > In order to do piggybacking of CARD on e.g. FMIPv6 the same piece > of software needs to implement both protocols. Thus you loose some > implementation flexibility if you want piggybacking which, depending > on how CARD and FMIPv6 are deployed, might make deployment harder. > > For instance, if FMIPv6 is already implemented and deployed by vendor X and Y > but those vendors do not have plans to update their implementations to add > CARD, then you can't really deploy CARD as an add-on piece of software that > people can download. > > AJOY-> Good point. So, I guess we should define both generic ICMP options > as well as the carrier of the generic options (new messages) in the base CARD > draft. This will eliminate the issue raised by you. Additionally, the FMIPv6 > draft may describe how to piggyback CARD options on FMIPv6 messages. > This will enable FMIPv6 implementation to take advantage of the > efficient implementataion of the CARD. I do agree in this case both CARD > and FMIPv6 must be developed by same vendor which is ok. > > But if most people that are going to implement one of the protocols is > going to implement the other as well then this wouldn't be a concern. > > AJOY-> I think this will be the most common scenario. Hence, it makes > sense to piggyback CARD options on FMIPv6 messages. > But I guess this is mostly an FMIPv6 issue and probably should be addressed > in FMIPv6 draft. What other's think? > > So I think it all depends on whether most people view this as two pieces > of the same protocol, or merely two different protocols operating between > the same set of nodes. In the latter case I think you want the implementation > flexibility of different implementers providing the different protocols for > the same box. > > Erik > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Jan 8 16:38:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08627 for ; Wed, 8 Jan 2003 16:38:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08LnaJ24560; Wed, 8 Jan 2003 16:49:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08LmFJ24479 for ; Wed, 8 Jan 2003 16:48:15 -0500 Received: from mailhost.iprg.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08545 for ; Wed, 8 Jan 2003 16:36:22 -0500 (EST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA07927; Wed, 8 Jan 2003 13:39:36 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h08LdWM11764; Wed, 8 Jan 2003 13:39:32 -0800 X-mProtect: <200301082139> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdJmcNCv; Wed, 08 Jan 2003 13:39:31 PST Message-ID: <3E1C9A94.2CCA59D8@iprg.nokia.com> Date: Wed, 08 Jan 2003 13:39:32 -0800 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Govind.Krishnamurthi@nokia.com CC: alper@docomolabs-usa.com, Seamoby@ietf.org Subject: Re: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol interworking References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Govind.Krishnamurthi@nokia.com wrote: > Rajeev, > > What you describe as alternatives is just ways of performing CARD IMO, each one having pros and cons. One of the functionalities of CARD (however you do it) is to fill up this mapping table. > Doing it statically is just one way of doing it. > OK, if CARD means a set of options to chose from and not _a_ protocol, then I agree with you. My impression was CARD is a protocol in works. -Rajeev > > Govind. > > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: Wednesday, January 08, 2003 1:01 PM > To: Krishnamurthi Govind (NRC/Boston) > Cc: alper@docomolabs-usa.com; Seamoby@ietf.org > Subject: Re: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol > interworking > > Govind, > > Govind.Krishnamurthi@nokia.com wrote: > > > > > [Govind] What you describe there are carriers that take the messages from > > and to the MN. I don't think anyone is discounting the fact that > > if FMIPv6 is available and is adapted to the needs of CARD these > > messages can be used as carriers. However, CARD also talks about > > capabilities discovery and mapping capabilities to the requirements > > of the MN. Also, FMIPv6 needs "something" to fill in the mapping > > from link layer id to L3 id. CARD does that. > > This is not an accurate characterization. FMIPv6 can work without CARD. > How the map containing the [AP-ID, AR-prefix] tuple is computed on the > access router is orthogonal to the operation of FMIPv6. One could use CARD > or static configuration, or any link state routing protocol (with extensions) > for > that matter to compute the map. > > -Rajeev > > > > > > > Are there other consumers, usage scenarios of CARD? > > [Govind] Several potential uses are listed in the issues draft. > > > > alper > > > > > Erick, > > > Thanks for your feedback. Please find my > > > inline reply. I am also posting this to > > > Mobile/IP WG as this may affect > > > FMIPv6 protocol. > > > Regards, > > > Ajoy > > > > > > -----Original Message----- > > > From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] > > > Sent: Tuesday, January 07, 2003 2:02 PM > > > To: Singh Ajoy-ASINGH1 > > > Cc: 'Erik Nordmark'; mankin@psg.com; 'James Kempf'; Seamoby@ietf.org > > > Subject: RE: [Seamoby] CARD - FMIPv6 protocol interworking > > > > > > > > > > > > Part of the tradeoffs with piggybacking has to do with implementation > > > considerations. > > > In order to do piggybacking of CARD on e.g. FMIPv6 the same piece > > > of software needs to implement both protocols. Thus you loose some > > > implementation flexibility if you want piggybacking which, depending > > > on how CARD and FMIPv6 are deployed, might make deployment harder. > > > > > > For instance, if FMIPv6 is already implemented and deployed by vendor X > > and Y > > > but those vendors do not have plans to update their implementations to add > > > CARD, then you can't really deploy CARD as an add-on piece of software > > that > > > people can download. > > > > > > AJOY-> Good point. So, I guess we should define both generic ICMP options > > > as well as the carrier of the generic options (new messages) in the base > > CARD > > > draft. This will eliminate the issue raised by you. Additionally, the > > FMIPv6 > > > draft may describe how to piggyback CARD options on FMIPv6 messages. > > > This will enable FMIPv6 implementation to take advantage of the > > > efficient implementataion of the CARD. I do agree in this case both CARD > > > and FMIPv6 must be developed by same vendor which is ok. > > > > > > But if most people that are going to implement one of the protocols is > > > going to implement the other as well then this wouldn't be a concern. > > > > > > AJOY-> I think this will be the most common scenario. Hence, it makes > > > sense to piggyback CARD options on FMIPv6 messages. > > > But I guess this is mostly an FMIPv6 issue and probably should be > > addressed > > > in FMIPv6 draft. What other's think? > > > > > > So I think it all depends on whether most people view this as two pieces > > > of the same protocol, or merely two different protocols operating between > > > the same set of nodes. In the latter case I think you want the > > implementation > > > flexibility of different implementers providing the different protocols > > for > > > the same box. > > > > > > Erik > > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Jan 8 16:39:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08680 for ; Wed, 8 Jan 2003 16:39:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08LpE824686 for seamoby-archive@odin.ietf.org; Wed, 8 Jan 2003 16:51:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08LpEJ24683 for ; Wed, 8 Jan 2003 16:51:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08630 for ; Wed, 8 Jan 2003 16:38:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08LnaJ24560; Wed, 8 Jan 2003 16:49:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08LmFJ24479 for ; Wed, 8 Jan 2003 16:48:15 -0500 Received: from mailhost.iprg.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08545 for ; Wed, 8 Jan 2003 16:36:22 -0500 (EST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA07927; Wed, 8 Jan 2003 13:39:36 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h08LdWM11764; Wed, 8 Jan 2003 13:39:32 -0800 X-mProtect: <200301082139> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdJmcNCv; Wed, 08 Jan 2003 13:39:31 PST Message-ID: <3E1C9A94.2CCA59D8@iprg.nokia.com> Date: Wed, 08 Jan 2003 13:39:32 -0800 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Govind.Krishnamurthi@nokia.com CC: alper@docomolabs-usa.com, Seamoby@ietf.org Subject: Re: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol interworking References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Govind.Krishnamurthi@nokia.com wrote: > Rajeev, > > What you describe as alternatives is just ways of performing CARD IMO, each one having pros and cons. One of the functionalities of CARD (however you do it) is to fill up this mapping table. > Doing it statically is just one way of doing it. > OK, if CARD means a set of options to chose from and not _a_ protocol, then I agree with you. My impression was CARD is a protocol in works. -Rajeev > > Govind. > > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: Wednesday, January 08, 2003 1:01 PM > To: Krishnamurthi Govind (NRC/Boston) > Cc: alper@docomolabs-usa.com; Seamoby@ietf.org > Subject: Re: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol > interworking > > Govind, > > Govind.Krishnamurthi@nokia.com wrote: > > > > > [Govind] What you describe there are carriers that take the messages from > > and to the MN. I don't think anyone is discounting the fact that > > if FMIPv6 is available and is adapted to the needs of CARD these > > messages can be used as carriers. However, CARD also talks about > > capabilities discovery and mapping capabilities to the requirements > > of the MN. Also, FMIPv6 needs "something" to fill in the mapping > > from link layer id to L3 id. CARD does that. > > This is not an accurate characterization. FMIPv6 can work without CARD. > How the map containing the [AP-ID, AR-prefix] tuple is computed on the > access router is orthogonal to the operation of FMIPv6. One could use CARD > or static configuration, or any link state routing protocol (with extensions) > for > that matter to compute the map. > > -Rajeev > > > > > > > Are there other consumers, usage scenarios of CARD? > > [Govind] Several potential uses are listed in the issues draft. > > > > alper > > > > > Erick, > > > Thanks for your feedback. Please find my > > > inline reply. I am also posting this to > > > Mobile/IP WG as this may affect > > > FMIPv6 protocol. > > > Regards, > > > Ajoy > > > > > > -----Original Message----- > > > From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] > > > Sent: Tuesday, January 07, 2003 2:02 PM > > > To: Singh Ajoy-ASINGH1 > > > Cc: 'Erik Nordmark'; mankin@psg.com; 'James Kempf'; Seamoby@ietf.org > > > Subject: RE: [Seamoby] CARD - FMIPv6 protocol interworking > > > > > > > > > > > > Part of the tradeoffs with piggybacking has to do with implementation > > > considerations. > > > In order to do piggybacking of CARD on e.g. FMIPv6 the same piece > > > of software needs to implement both protocols. Thus you loose some > > > implementation flexibility if you want piggybacking which, depending > > > on how CARD and FMIPv6 are deployed, might make deployment harder. > > > > > > For instance, if FMIPv6 is already implemented and deployed by vendor X > > and Y > > > but those vendors do not have plans to update their implementations to add > > > CARD, then you can't really deploy CARD as an add-on piece of software > > that > > > people can download. > > > > > > AJOY-> Good point. So, I guess we should define both generic ICMP options > > > as well as the carrier of the generic options (new messages) in the base > > CARD > > > draft. This will eliminate the issue raised by you. Additionally, the > > FMIPv6 > > > draft may describe how to piggyback CARD options on FMIPv6 messages. > > > This will enable FMIPv6 implementation to take advantage of the > > > efficient implementataion of the CARD. I do agree in this case both CARD > > > and FMIPv6 must be developed by same vendor which is ok. > > > > > > But if most people that are going to implement one of the protocols is > > > going to implement the other as well then this wouldn't be a concern. > > > > > > AJOY-> I think this will be the most common scenario. Hence, it makes > > > sense to piggyback CARD options on FMIPv6 messages. > > > But I guess this is mostly an FMIPv6 issue and probably should be > > addressed > > > in FMIPv6 draft. What other's think? > > > > > > So I think it all depends on whether most people view this as two pieces > > > of the same protocol, or merely two different protocols operating between > > > the same set of nodes. In the latter case I think you want the > > implementation > > > flexibility of different implementers providing the different protocols > > for > > > the same box. > > > > > > Erik > > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Jan 8 16:46:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08903 for ; Wed, 8 Jan 2003 16:46:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08Lv5J24995; Wed, 8 Jan 2003 16:57:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08LuEJ24952 for ; Wed, 8 Jan 2003 16:56:14 -0500 Received: from mailhost.iprg.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08847 for ; Wed, 8 Jan 2003 16:44:20 -0500 (EST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA08192; Wed, 8 Jan 2003 13:47:35 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h08LlWr17858; Wed, 8 Jan 2003 13:47:32 -0800 X-mProtect: <200301082147> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdTyiFkm; Wed, 08 Jan 2003 13:47:31 PST Message-ID: <3E1C9C73.C6704DD0@iprg.nokia.com> Date: Wed, 08 Jan 2003 13:47:31 -0800 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Hemant.Chaskar@nokia.com CC: Govind.Krishnamurthi@nokia.com, alper@docomolabs-usa.com, Seamoby@ietf.org Subject: Re: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol interworking References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hemant, Hemant.Chaskar@nokia.com wrote: > Hi Rajeev: > > As you say, the L2 ID - IP address mapping is orthogonal to FMIPv6. Well, but it is very much essential component Right, how the map is computed on the access router is beyond the scope of FMIPv6. > of CARD, according to CARD problem statement. Whether to use that component in FMIPv6 or not is implementer's choice. > Agreed. From FMIPv6's perspective, the MN queries the AR to resolve the AP-ID, and gets a response. To use CARD to compute the tuple is someone's choice. Good. -Rajeev > > Hemant > > -----Original Message----- > From: ext Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: Wednesday, January 08, 2003 1:01 PM > To: Krishnamurthi Govind (NRC/Boston) > Cc: alper@docomolabs-usa.com; Seamoby@ietf.org > Subject: Re: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol > interworking > > Govind, > > Govind.Krishnamurthi@nokia.com wrote: > > > > > [Govind] What you describe there are carriers that take the messages from > > and to the MN. I don't think anyone is discounting the fact that > > if FMIPv6 is available and is adapted to the needs of CARD these > > messages can be used as carriers. However, CARD also talks about > > capabilities discovery and mapping capabilities to the requirements > > of the MN. Also, FMIPv6 needs "something" to fill in the mapping > > from link layer id to L3 id. CARD does that. > > This is not an accurate characterization. FMIPv6 can work without CARD. > How the map containing the [AP-ID, AR-prefix] tuple is computed on the > access router is orthogonal to the operation of FMIPv6. One could use CARD > or static configuration, or any link state routing protocol (with extensions) > for > that matter to compute the map. > > -Rajeev > > > > > > > Are there other consumers, usage scenarios of CARD? > > [Govind] Several potential uses are listed in the issues draft. > > > > alper > > > > > Erick, > > > Thanks for your feedback. Please find my > > > inline reply. I am also posting this to > > > Mobile/IP WG as this may affect > > > FMIPv6 protocol. > > > Regards, > > > Ajoy > > > > > > -----Original Message----- > > > From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] > > > Sent: Tuesday, January 07, 2003 2:02 PM > > > To: Singh Ajoy-ASINGH1 > > > Cc: 'Erik Nordmark'; mankin@psg.com; 'James Kempf'; Seamoby@ietf.org > > > Subject: RE: [Seamoby] CARD - FMIPv6 protocol interworking > > > > > > > > > > > > Part of the tradeoffs with piggybacking has to do with implementation > > > considerations. > > > In order to do piggybacking of CARD on e.g. FMIPv6 the same piece > > > of software needs to implement both protocols. Thus you loose some > > > implementation flexibility if you want piggybacking which, depending > > > on how CARD and FMIPv6 are deployed, might make deployment harder. > > > > > > For instance, if FMIPv6 is already implemented and deployed by vendor X > > and Y > > > but those vendors do not have plans to update their implementations to add > > > CARD, then you can't really deploy CARD as an add-on piece of software > > that > > > people can download. > > > > > > AJOY-> Good point. So, I guess we should define both generic ICMP options > > > as well as the carrier of the generic options (new messages) in the base > > CARD > > > draft. This will eliminate the issue raised by you. Additionally, the > > FMIPv6 > > > draft may describe how to piggyback CARD options on FMIPv6 messages. > > > This will enable FMIPv6 implementation to take advantage of the > > > efficient implementataion of the CARD. I do agree in this case both CARD > > > and FMIPv6 must be developed by same vendor which is ok. > > > > > > But if most people that are going to implement one of the protocols is > > > going to implement the other as well then this wouldn't be a concern. > > > > > > AJOY-> I think this will be the most common scenario. Hence, it makes > > > sense to piggyback CARD options on FMIPv6 messages. > > > But I guess this is mostly an FMIPv6 issue and probably should be > > addressed > > > in FMIPv6 draft. What other's think? > > > > > > So I think it all depends on whether most people view this as two pieces > > > of the same protocol, or merely two different protocols operating between > > > the same set of nodes. In the latter case I think you want the > > implementation > > > flexibility of different implementers providing the different protocols > > for > > > the same box. > > > > > > Erik > > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Jan 8 16:47:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08945 for ; Wed, 8 Jan 2003 16:47:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08LwXK25074 for seamoby-archive@odin.ietf.org; Wed, 8 Jan 2003 16:58:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08LwXJ25071 for ; Wed, 8 Jan 2003 16:58:33 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08907 for ; Wed, 8 Jan 2003 16:46:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08Lv5J24995; Wed, 8 Jan 2003 16:57:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08LuEJ24952 for ; Wed, 8 Jan 2003 16:56:14 -0500 Received: from mailhost.iprg.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08847 for ; Wed, 8 Jan 2003 16:44:20 -0500 (EST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA08192; Wed, 8 Jan 2003 13:47:35 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h08LlWr17858; Wed, 8 Jan 2003 13:47:32 -0800 X-mProtect: <200301082147> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdTyiFkm; Wed, 08 Jan 2003 13:47:31 PST Message-ID: <3E1C9C73.C6704DD0@iprg.nokia.com> Date: Wed, 08 Jan 2003 13:47:31 -0800 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Hemant.Chaskar@nokia.com CC: Govind.Krishnamurthi@nokia.com, alper@docomolabs-usa.com, Seamoby@ietf.org Subject: Re: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol interworking References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hemant, Hemant.Chaskar@nokia.com wrote: > Hi Rajeev: > > As you say, the L2 ID - IP address mapping is orthogonal to FMIPv6. Well, but it is very much essential component Right, how the map is computed on the access router is beyond the scope of FMIPv6. > of CARD, according to CARD problem statement. Whether to use that component in FMIPv6 or not is implementer's choice. > Agreed. From FMIPv6's perspective, the MN queries the AR to resolve the AP-ID, and gets a response. To use CARD to compute the tuple is someone's choice. Good. -Rajeev > > Hemant > > -----Original Message----- > From: ext Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: Wednesday, January 08, 2003 1:01 PM > To: Krishnamurthi Govind (NRC/Boston) > Cc: alper@docomolabs-usa.com; Seamoby@ietf.org > Subject: Re: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol > interworking > > Govind, > > Govind.Krishnamurthi@nokia.com wrote: > > > > > [Govind] What you describe there are carriers that take the messages from > > and to the MN. I don't think anyone is discounting the fact that > > if FMIPv6 is available and is adapted to the needs of CARD these > > messages can be used as carriers. However, CARD also talks about > > capabilities discovery and mapping capabilities to the requirements > > of the MN. Also, FMIPv6 needs "something" to fill in the mapping > > from link layer id to L3 id. CARD does that. > > This is not an accurate characterization. FMIPv6 can work without CARD. > How the map containing the [AP-ID, AR-prefix] tuple is computed on the > access router is orthogonal to the operation of FMIPv6. One could use CARD > or static configuration, or any link state routing protocol (with extensions) > for > that matter to compute the map. > > -Rajeev > > > > > > > Are there other consumers, usage scenarios of CARD? > > [Govind] Several potential uses are listed in the issues draft. > > > > alper > > > > > Erick, > > > Thanks for your feedback. Please find my > > > inline reply. I am also posting this to > > > Mobile/IP WG as this may affect > > > FMIPv6 protocol. > > > Regards, > > > Ajoy > > > > > > -----Original Message----- > > > From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] > > > Sent: Tuesday, January 07, 2003 2:02 PM > > > To: Singh Ajoy-ASINGH1 > > > Cc: 'Erik Nordmark'; mankin@psg.com; 'James Kempf'; Seamoby@ietf.org > > > Subject: RE: [Seamoby] CARD - FMIPv6 protocol interworking > > > > > > > > > > > > Part of the tradeoffs with piggybacking has to do with implementation > > > considerations. > > > In order to do piggybacking of CARD on e.g. FMIPv6 the same piece > > > of software needs to implement both protocols. Thus you loose some > > > implementation flexibility if you want piggybacking which, depending > > > on how CARD and FMIPv6 are deployed, might make deployment harder. > > > > > > For instance, if FMIPv6 is already implemented and deployed by vendor X > > and Y > > > but those vendors do not have plans to update their implementations to add > > > CARD, then you can't really deploy CARD as an add-on piece of software > > that > > > people can download. > > > > > > AJOY-> Good point. So, I guess we should define both generic ICMP options > > > as well as the carrier of the generic options (new messages) in the base > > CARD > > > draft. This will eliminate the issue raised by you. Additionally, the > > FMIPv6 > > > draft may describe how to piggyback CARD options on FMIPv6 messages. > > > This will enable FMIPv6 implementation to take advantage of the > > > efficient implementataion of the CARD. I do agree in this case both CARD > > > and FMIPv6 must be developed by same vendor which is ok. > > > > > > But if most people that are going to implement one of the protocols is > > > going to implement the other as well then this wouldn't be a concern. > > > > > > AJOY-> I think this will be the most common scenario. Hence, it makes > > > sense to piggyback CARD options on FMIPv6 messages. > > > But I guess this is mostly an FMIPv6 issue and probably should be > > addressed > > > in FMIPv6 draft. What other's think? > > > > > > So I think it all depends on whether most people view this as two pieces > > > of the same protocol, or merely two different protocols operating between > > > the same set of nodes. In the latter case I think you want the > > implementation > > > flexibility of different implementers providing the different protocols > > for > > > the same box. > > > > > > Erik > > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Jan 8 16:50:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09110 for ; Wed, 8 Jan 2003 16:50:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08M1MJ25677; Wed, 8 Jan 2003 17:01:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08M0YJ25454 for ; Wed, 8 Jan 2003 17:00:34 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09088 for ; Wed, 8 Jan 2003 16:48:39 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h08LpwE16117 for ; Wed, 8 Jan 2003 15:51:58 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 8 Jan 2003 15:51:52 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 8 Jan 2003 15:51:52 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol interworking Date: Wed, 8 Jan 2003 16:51:51 -0500 Message-ID: Thread-Topic: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol interworking Thread-Index: AcK3XnJ7aUWpyqeeQZe1oEZ6RlwLtAAATqfg To: Cc: , X-OriginalArrivalTime: 08 Jan 2003 21:51:52.0479 (UTC) FILETIME=[275AA2F0:01C2B760] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h08M0YJ25455 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Rajeev, I don't understand what you mean by saying CARD is not a protocol. There are several ways to implement the various components of the CARD protocol and having a static map, IMO, is one way to implement the mapping to facilitate L2-L3 translation. Ofcourse, this is a simplistic and clearly not the best way to do it as explained in the issues draft. Hope it is clear now. -Govind. -----Original Message----- From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] Sent: Wednesday, January 08, 2003 4:40 PM To: Krishnamurthi Govind (NRC/Boston) Cc: alper@docomolabs-usa.com; Seamoby@ietf.org Subject: Re: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol interworking Govind.Krishnamurthi@nokia.com wrote: > Rajeev, > > What you describe as alternatives is just ways of performing CARD IMO, each one having pros and cons. One of the functionalities of CARD (however you do it) is to fill up this mapping table. > Doing it statically is just one way of doing it. > OK, if CARD means a set of options to chose from and not _a_ protocol, then I agree with you. My impression was CARD is a protocol in works. -Rajeev > > Govind. > > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: Wednesday, January 08, 2003 1:01 PM > To: Krishnamurthi Govind (NRC/Boston) > Cc: alper@docomolabs-usa.com; Seamoby@ietf.org > Subject: Re: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol > interworking > > Govind, > > Govind.Krishnamurthi@nokia.com wrote: > > > > > [Govind] What you describe there are carriers that take the messages from > > and to the MN. I don't think anyone is discounting the fact that > > if FMIPv6 is available and is adapted to the needs of CARD these > > messages can be used as carriers. However, CARD also talks about > > capabilities discovery and mapping capabilities to the requirements > > of the MN. Also, FMIPv6 needs "something" to fill in the mapping > > from link layer id to L3 id. CARD does that. > > This is not an accurate characterization. FMIPv6 can work without CARD. > How the map containing the [AP-ID, AR-prefix] tuple is computed on the > access router is orthogonal to the operation of FMIPv6. One could use CARD > or static configuration, or any link state routing protocol (with extensions) > for > that matter to compute the map. > > -Rajeev > > > > > > > Are there other consumers, usage scenarios of CARD? > > [Govind] Several potential uses are listed in the issues draft. > > > > alper > > > > > Erick, > > > Thanks for your feedback. Please find my > > > inline reply. I am also posting this to > > > Mobile/IP WG as this may affect > > > FMIPv6 protocol. > > > Regards, > > > Ajoy > > > > > > -----Original Message----- > > > From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] > > > Sent: Tuesday, January 07, 2003 2:02 PM > > > To: Singh Ajoy-ASINGH1 > > > Cc: 'Erik Nordmark'; mankin@psg.com; 'James Kempf'; Seamoby@ietf.org > > > Subject: RE: [Seamoby] CARD - FMIPv6 protocol interworking > > > > > > > > > > > > Part of the tradeoffs with piggybacking has to do with implementation > > > considerations. > > > In order to do piggybacking of CARD on e.g. FMIPv6 the same piece > > > of software needs to implement both protocols. Thus you loose some > > > implementation flexibility if you want piggybacking which, depending > > > on how CARD and FMIPv6 are deployed, might make deployment harder. > > > > > > For instance, if FMIPv6 is already implemented and deployed by vendor X > > and Y > > > but those vendors do not have plans to update their implementations to add > > > CARD, then you can't really deploy CARD as an add-on piece of software > > that > > > people can download. > > > > > > AJOY-> Good point. So, I guess we should define both generic ICMP options > > > as well as the carrier of the generic options (new messages) in the base > > CARD > > > draft. This will eliminate the issue raised by you. Additionally, the > > FMIPv6 > > > draft may describe how to piggyback CARD options on FMIPv6 messages. > > > This will enable FMIPv6 implementation to take advantage of the > > > efficient implementataion of the CARD. I do agree in this case both CARD > > > and FMIPv6 must be developed by same vendor which is ok. > > > > > > But if most people that are going to implement one of the protocols is > > > going to implement the other as well then this wouldn't be a concern. > > > > > > AJOY-> I think this will be the most common scenario. Hence, it makes > > > sense to piggyback CARD options on FMIPv6 messages. > > > But I guess this is mostly an FMIPv6 issue and probably should be > > addressed > > > in FMIPv6 draft. What other's think? > > > > > > So I think it all depends on whether most people view this as two pieces > > > of the same protocol, or merely two different protocols operating between > > > the same set of nodes. In the latter case I think you want the > > implementation > > > flexibility of different implementers providing the different protocols > > for > > > the same box. > > > > > > Erik > > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Jan 8 16:51:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09141 for ; Wed, 8 Jan 2003 16:51:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08M2b225747 for seamoby-archive@odin.ietf.org; Wed, 8 Jan 2003 17:02:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08M2bJ25744 for ; Wed, 8 Jan 2003 17:02:37 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09113 for ; Wed, 8 Jan 2003 16:50:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08M1MJ25677; Wed, 8 Jan 2003 17:01:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08M0YJ25454 for ; Wed, 8 Jan 2003 17:00:34 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09088 for ; Wed, 8 Jan 2003 16:48:39 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h08LpwE16117 for ; Wed, 8 Jan 2003 15:51:58 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 8 Jan 2003 15:51:52 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 8 Jan 2003 15:51:52 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol interworking Date: Wed, 8 Jan 2003 16:51:51 -0500 Message-ID: Thread-Topic: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol interworking Thread-Index: AcK3XnJ7aUWpyqeeQZe1oEZ6RlwLtAAATqfg To: Cc: , X-OriginalArrivalTime: 08 Jan 2003 21:51:52.0479 (UTC) FILETIME=[275AA2F0:01C2B760] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h08M0YJ25455 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Rajeev, I don't understand what you mean by saying CARD is not a protocol. There are several ways to implement the various components of the CARD protocol and having a static map, IMO, is one way to implement the mapping to facilitate L2-L3 translation. Ofcourse, this is a simplistic and clearly not the best way to do it as explained in the issues draft. Hope it is clear now. -Govind. -----Original Message----- From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] Sent: Wednesday, January 08, 2003 4:40 PM To: Krishnamurthi Govind (NRC/Boston) Cc: alper@docomolabs-usa.com; Seamoby@ietf.org Subject: Re: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol interworking Govind.Krishnamurthi@nokia.com wrote: > Rajeev, > > What you describe as alternatives is just ways of performing CARD IMO, each one having pros and cons. One of the functionalities of CARD (however you do it) is to fill up this mapping table. > Doing it statically is just one way of doing it. > OK, if CARD means a set of options to chose from and not _a_ protocol, then I agree with you. My impression was CARD is a protocol in works. -Rajeev > > Govind. > > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: Wednesday, January 08, 2003 1:01 PM > To: Krishnamurthi Govind (NRC/Boston) > Cc: alper@docomolabs-usa.com; Seamoby@ietf.org > Subject: Re: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol > interworking > > Govind, > > Govind.Krishnamurthi@nokia.com wrote: > > > > > [Govind] What you describe there are carriers that take the messages from > > and to the MN. I don't think anyone is discounting the fact that > > if FMIPv6 is available and is adapted to the needs of CARD these > > messages can be used as carriers. However, CARD also talks about > > capabilities discovery and mapping capabilities to the requirements > > of the MN. Also, FMIPv6 needs "something" to fill in the mapping > > from link layer id to L3 id. CARD does that. > > This is not an accurate characterization. FMIPv6 can work without CARD. > How the map containing the [AP-ID, AR-prefix] tuple is computed on the > access router is orthogonal to the operation of FMIPv6. One could use CARD > or static configuration, or any link state routing protocol (with extensions) > for > that matter to compute the map. > > -Rajeev > > > > > > > Are there other consumers, usage scenarios of CARD? > > [Govind] Several potential uses are listed in the issues draft. > > > > alper > > > > > Erick, > > > Thanks for your feedback. Please find my > > > inline reply. I am also posting this to > > > Mobile/IP WG as this may affect > > > FMIPv6 protocol. > > > Regards, > > > Ajoy > > > > > > -----Original Message----- > > > From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] > > > Sent: Tuesday, January 07, 2003 2:02 PM > > > To: Singh Ajoy-ASINGH1 > > > Cc: 'Erik Nordmark'; mankin@psg.com; 'James Kempf'; Seamoby@ietf.org > > > Subject: RE: [Seamoby] CARD - FMIPv6 protocol interworking > > > > > > > > > > > > Part of the tradeoffs with piggybacking has to do with implementation > > > considerations. > > > In order to do piggybacking of CARD on e.g. FMIPv6 the same piece > > > of software needs to implement both protocols. Thus you loose some > > > implementation flexibility if you want piggybacking which, depending > > > on how CARD and FMIPv6 are deployed, might make deployment harder. > > > > > > For instance, if FMIPv6 is already implemented and deployed by vendor X > > and Y > > > but those vendors do not have plans to update their implementations to add > > > CARD, then you can't really deploy CARD as an add-on piece of software > > that > > > people can download. > > > > > > AJOY-> Good point. So, I guess we should define both generic ICMP options > > > as well as the carrier of the generic options (new messages) in the base > > CARD > > > draft. This will eliminate the issue raised by you. Additionally, the > > FMIPv6 > > > draft may describe how to piggyback CARD options on FMIPv6 messages. > > > This will enable FMIPv6 implementation to take advantage of the > > > efficient implementataion of the CARD. I do agree in this case both CARD > > > and FMIPv6 must be developed by same vendor which is ok. > > > > > > But if most people that are going to implement one of the protocols is > > > going to implement the other as well then this wouldn't be a concern. > > > > > > AJOY-> I think this will be the most common scenario. Hence, it makes > > > sense to piggyback CARD options on FMIPv6 messages. > > > But I guess this is mostly an FMIPv6 issue and probably should be > > addressed > > > in FMIPv6 draft. What other's think? > > > > > > So I think it all depends on whether most people view this as two pieces > > > of the same protocol, or merely two different protocols operating between > > > the same set of nodes. In the latter case I think you want the > > implementation > > > flexibility of different implementers providing the different protocols > > for > > > the same box. > > > > > > Erik > > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Jan 8 17:44:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11029 for ; Wed, 8 Jan 2003 17:44:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08MtFJ29229; Wed, 8 Jan 2003 17:55:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08MrLJ29102 for ; Wed, 8 Jan 2003 17:53:21 -0500 Received: from mailhost.iprg.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10851 for ; Wed, 8 Jan 2003 17:41:25 -0500 (EST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA10708; Wed, 8 Jan 2003 14:44:40 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h08MiaE03294; Wed, 8 Jan 2003 14:44:36 -0800 X-mProtect: <200301082244> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdXq6LpI; Wed, 08 Jan 2003 14:44:35 PST Message-ID: <3E1CA9D4.23E82E5E@iprg.nokia.com> Date: Wed, 08 Jan 2003 14:44:36 -0800 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Govind.Krishnamurthi@nokia.com CC: alper@docomolabs-usa.com, Seamoby@ietf.org Subject: Re: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol interworking References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Govind.Krishnamurthi@nokia.com wrote: > Rajeev, > I don't understand what you mean by saying CARD is not a protocol. > There are several ways to implement the various components of the CARD protocol > and having a static map, IMO, is one way to implement the mapping to facilitate L2-L3 > translation. Ofcourse, this is a simplistic and clearly not the best way to do it as > explained in the issues draft. > Hope it is clear now. > I don't mean to drag along this.. We disagree on whether static configuration is part of a protocol. So, let's conclude. Thanks, -Rajeev > > -Govind. > > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: Wednesday, January 08, 2003 4:40 PM > To: Krishnamurthi Govind (NRC/Boston) > Cc: alper@docomolabs-usa.com; Seamoby@ietf.org > Subject: Re: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol > interworking > > Govind.Krishnamurthi@nokia.com wrote: > > > Rajeev, > > > > What you describe as alternatives is just ways of performing CARD IMO, each one having pros and cons. One of the functionalities of CARD (however you do it) is to fill up this mapping table. > > Doing it statically is just one way of doing it. > > > > OK, if CARD means a set of options to chose from and not _a_ protocol, then > I agree with you. My impression was CARD is a protocol in works. > > -Rajeev > > > > > Govind. > > > > -----Original Message----- > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > Sent: Wednesday, January 08, 2003 1:01 PM > > To: Krishnamurthi Govind (NRC/Boston) > > Cc: alper@docomolabs-usa.com; Seamoby@ietf.org > > Subject: Re: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol > > interworking > > > > Govind, > > > > Govind.Krishnamurthi@nokia.com wrote: > > > > > > > > [Govind] What you describe there are carriers that take the messages from > > > and to the MN. I don't think anyone is discounting the fact that > > > if FMIPv6 is available and is adapted to the needs of CARD these > > > messages can be used as carriers. However, CARD also talks about > > > capabilities discovery and mapping capabilities to the requirements > > > of the MN. Also, FMIPv6 needs "something" to fill in the mapping > > > from link layer id to L3 id. CARD does that. > > > > This is not an accurate characterization. FMIPv6 can work without CARD. > > How the map containing the [AP-ID, AR-prefix] tuple is computed on the > > access router is orthogonal to the operation of FMIPv6. One could use CARD > > or static configuration, or any link state routing protocol (with extensions) > > for > > that matter to compute the map. > > > > -Rajeev > > > > > > > > > > > Are there other consumers, usage scenarios of CARD? > > > [Govind] Several potential uses are listed in the issues draft. > > > > > > alper > > > > > > > Erick, > > > > Thanks for your feedback. Please find my > > > > inline reply. I am also posting this to > > > > Mobile/IP WG as this may affect > > > > FMIPv6 protocol. > > > > Regards, > > > > Ajoy > > > > > > > > -----Original Message----- > > > > From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] > > > > Sent: Tuesday, January 07, 2003 2:02 PM > > > > To: Singh Ajoy-ASINGH1 > > > > Cc: 'Erik Nordmark'; mankin@psg.com; 'James Kempf'; Seamoby@ietf.org > > > > Subject: RE: [Seamoby] CARD - FMIPv6 protocol interworking > > > > > > > > > > > > > > > > Part of the tradeoffs with piggybacking has to do with implementation > > > > considerations. > > > > In order to do piggybacking of CARD on e.g. FMIPv6 the same piece > > > > of software needs to implement both protocols. Thus you loose some > > > > implementation flexibility if you want piggybacking which, depending > > > > on how CARD and FMIPv6 are deployed, might make deployment harder. > > > > > > > > For instance, if FMIPv6 is already implemented and deployed by vendor X > > > and Y > > > > but those vendors do not have plans to update their implementations to add > > > > CARD, then you can't really deploy CARD as an add-on piece of software > > > that > > > > people can download. > > > > > > > > AJOY-> Good point. So, I guess we should define both generic ICMP options > > > > as well as the carrier of the generic options (new messages) in the base > > > CARD > > > > draft. This will eliminate the issue raised by you. Additionally, the > > > FMIPv6 > > > > draft may describe how to piggyback CARD options on FMIPv6 messages. > > > > This will enable FMIPv6 implementation to take advantage of the > > > > efficient implementataion of the CARD. I do agree in this case both CARD > > > > and FMIPv6 must be developed by same vendor which is ok. > > > > > > > > But if most people that are going to implement one of the protocols is > > > > going to implement the other as well then this wouldn't be a concern. > > > > > > > > AJOY-> I think this will be the most common scenario. Hence, it makes > > > > sense to piggyback CARD options on FMIPv6 messages. > > > > But I guess this is mostly an FMIPv6 issue and probably should be > > > addressed > > > > in FMIPv6 draft. What other's think? > > > > > > > > So I think it all depends on whether most people view this as two pieces > > > > of the same protocol, or merely two different protocols operating between > > > > the same set of nodes. In the latter case I think you want the > > > implementation > > > > flexibility of different implementers providing the different protocols > > > for > > > > the same box. > > > > > > > > Erik > > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Jan 8 17:47:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11231 for ; Wed, 8 Jan 2003 17:47:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08MwPi29385 for seamoby-archive@odin.ietf.org; Wed, 8 Jan 2003 17:58:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08MwOJ29382 for ; Wed, 8 Jan 2003 17:58:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11033 for ; Wed, 8 Jan 2003 17:44:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08MtFJ29229; Wed, 8 Jan 2003 17:55:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08MrLJ29102 for ; Wed, 8 Jan 2003 17:53:21 -0500 Received: from mailhost.iprg.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10851 for ; Wed, 8 Jan 2003 17:41:25 -0500 (EST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA10708; Wed, 8 Jan 2003 14:44:40 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h08MiaE03294; Wed, 8 Jan 2003 14:44:36 -0800 X-mProtect: <200301082244> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdXq6LpI; Wed, 08 Jan 2003 14:44:35 PST Message-ID: <3E1CA9D4.23E82E5E@iprg.nokia.com> Date: Wed, 08 Jan 2003 14:44:36 -0800 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Govind.Krishnamurthi@nokia.com CC: alper@docomolabs-usa.com, Seamoby@ietf.org Subject: Re: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol interworking References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Govind.Krishnamurthi@nokia.com wrote: > Rajeev, > I don't understand what you mean by saying CARD is not a protocol. > There are several ways to implement the various components of the CARD protocol > and having a static map, IMO, is one way to implement the mapping to facilitate L2-L3 > translation. Ofcourse, this is a simplistic and clearly not the best way to do it as > explained in the issues draft. > Hope it is clear now. > I don't mean to drag along this.. We disagree on whether static configuration is part of a protocol. So, let's conclude. Thanks, -Rajeev > > -Govind. > > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: Wednesday, January 08, 2003 4:40 PM > To: Krishnamurthi Govind (NRC/Boston) > Cc: alper@docomolabs-usa.com; Seamoby@ietf.org > Subject: Re: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol > interworking > > Govind.Krishnamurthi@nokia.com wrote: > > > Rajeev, > > > > What you describe as alternatives is just ways of performing CARD IMO, each one having pros and cons. One of the functionalities of CARD (however you do it) is to fill up this mapping table. > > Doing it statically is just one way of doing it. > > > > OK, if CARD means a set of options to chose from and not _a_ protocol, then > I agree with you. My impression was CARD is a protocol in works. > > -Rajeev > > > > > Govind. > > > > -----Original Message----- > > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > > Sent: Wednesday, January 08, 2003 1:01 PM > > To: Krishnamurthi Govind (NRC/Boston) > > Cc: alper@docomolabs-usa.com; Seamoby@ietf.org > > Subject: Re: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol > > interworking > > > > Govind, > > > > Govind.Krishnamurthi@nokia.com wrote: > > > > > > > > [Govind] What you describe there are carriers that take the messages from > > > and to the MN. I don't think anyone is discounting the fact that > > > if FMIPv6 is available and is adapted to the needs of CARD these > > > messages can be used as carriers. However, CARD also talks about > > > capabilities discovery and mapping capabilities to the requirements > > > of the MN. Also, FMIPv6 needs "something" to fill in the mapping > > > from link layer id to L3 id. CARD does that. > > > > This is not an accurate characterization. FMIPv6 can work without CARD. > > How the map containing the [AP-ID, AR-prefix] tuple is computed on the > > access router is orthogonal to the operation of FMIPv6. One could use CARD > > or static configuration, or any link state routing protocol (with extensions) > > for > > that matter to compute the map. > > > > -Rajeev > > > > > > > > > > > Are there other consumers, usage scenarios of CARD? > > > [Govind] Several potential uses are listed in the issues draft. > > > > > > alper > > > > > > > Erick, > > > > Thanks for your feedback. Please find my > > > > inline reply. I am also posting this to > > > > Mobile/IP WG as this may affect > > > > FMIPv6 protocol. > > > > Regards, > > > > Ajoy > > > > > > > > -----Original Message----- > > > > From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] > > > > Sent: Tuesday, January 07, 2003 2:02 PM > > > > To: Singh Ajoy-ASINGH1 > > > > Cc: 'Erik Nordmark'; mankin@psg.com; 'James Kempf'; Seamoby@ietf.org > > > > Subject: RE: [Seamoby] CARD - FMIPv6 protocol interworking > > > > > > > > > > > > > > > > Part of the tradeoffs with piggybacking has to do with implementation > > > > considerations. > > > > In order to do piggybacking of CARD on e.g. FMIPv6 the same piece > > > > of software needs to implement both protocols. Thus you loose some > > > > implementation flexibility if you want piggybacking which, depending > > > > on how CARD and FMIPv6 are deployed, might make deployment harder. > > > > > > > > For instance, if FMIPv6 is already implemented and deployed by vendor X > > > and Y > > > > but those vendors do not have plans to update their implementations to add > > > > CARD, then you can't really deploy CARD as an add-on piece of software > > > that > > > > people can download. > > > > > > > > AJOY-> Good point. So, I guess we should define both generic ICMP options > > > > as well as the carrier of the generic options (new messages) in the base > > > CARD > > > > draft. This will eliminate the issue raised by you. Additionally, the > > > FMIPv6 > > > > draft may describe how to piggyback CARD options on FMIPv6 messages. > > > > This will enable FMIPv6 implementation to take advantage of the > > > > efficient implementataion of the CARD. I do agree in this case both CARD > > > > and FMIPv6 must be developed by same vendor which is ok. > > > > > > > > But if most people that are going to implement one of the protocols is > > > > going to implement the other as well then this wouldn't be a concern. > > > > > > > > AJOY-> I think this will be the most common scenario. Hence, it makes > > > > sense to piggyback CARD options on FMIPv6 messages. > > > > But I guess this is mostly an FMIPv6 issue and probably should be > > > addressed > > > > in FMIPv6 draft. What other's think? > > > > > > > > So I think it all depends on whether most people view this as two pieces > > > > of the same protocol, or merely two different protocols operating between > > > > the same set of nodes. In the latter case I think you want the > > > implementation > > > > flexibility of different implementers providing the different protocols > > > for > > > > the same box. > > > > > > > > Erik > > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Jan 8 19:22:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14636 for ; Wed, 8 Jan 2003 19:22:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h090XMJ01889; Wed, 8 Jan 2003 19:33:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h090W7J01853 for ; Wed, 8 Jan 2003 19:32:07 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14578 for ; Wed, 8 Jan 2003 19:20:10 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h090NVE12459 for ; Wed, 8 Jan 2003 18:23:31 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 8 Jan 2003 18:23:25 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 8 Jan 2003 18:23:05 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol interworking Date: Wed, 8 Jan 2003 19:23:04 -0500 Message-ID: Thread-Topic: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol interworking Thread-Index: AcK3XrwvW0q+wchYR+eR225ek4nRZwAFeazA To: , Cc: , X-OriginalArrivalTime: 09 Jan 2003 00:23:05.0521 (UTC) FILETIME=[474EFA10:01C2B775] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h090W8J01856 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi: I don't understand this distinction between protocol and options. All protocols have options, extensions and optimizations. How does one define if something is a protocol and something is an option? CARD has in its charter designing a mechanism to provide L2 ID to IP adr. mapping. Of course, static configuration is one of them. But, it is a trivial solution and does not warrant any discussion or specific mention. Then, there can be more sophisticated solutions. If implementer sees any benefits in using sophisticated solutions, he may do so. If he thinks it is too much, he can let it go. Hemant -----Original Message----- From: ext Rajeev Koodli [mailto:rajeev@iprg.nokia.com] Sent: Wednesday, January 08, 2003 4:40 PM To: Krishnamurthi Govind (NRC/Boston) Cc: alper@docomolabs-usa.com; Seamoby@ietf.org Subject: Re: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol interworking Govind.Krishnamurthi@nokia.com wrote: > Rajeev, > > What you describe as alternatives is just ways of performing CARD IMO, each one having pros and cons. One of the functionalities of CARD (however you do it) is to fill up this mapping table. > Doing it statically is just one way of doing it. > OK, if CARD means a set of options to chose from and not _a_ protocol, then I agree with you. My impression was CARD is a protocol in works. -Rajeev > > Govind. > > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: Wednesday, January 08, 2003 1:01 PM > To: Krishnamurthi Govind (NRC/Boston) > Cc: alper@docomolabs-usa.com; Seamoby@ietf.org > Subject: Re: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol > interworking > > Govind, > > Govind.Krishnamurthi@nokia.com wrote: > > > > > [Govind] What you describe there are carriers that take the messages from > > and to the MN. I don't think anyone is discounting the fact that > > if FMIPv6 is available and is adapted to the needs of CARD these > > messages can be used as carriers. However, CARD also talks about > > capabilities discovery and mapping capabilities to the requirements > > of the MN. Also, FMIPv6 needs "something" to fill in the mapping > > from link layer id to L3 id. CARD does that. > > This is not an accurate characterization. FMIPv6 can work without CARD. > How the map containing the [AP-ID, AR-prefix] tuple is computed on the > access router is orthogonal to the operation of FMIPv6. One could use CARD > or static configuration, or any link state routing protocol (with extensions) > for > that matter to compute the map. > > -Rajeev > > > > > > > Are there other consumers, usage scenarios of CARD? > > [Govind] Several potential uses are listed in the issues draft. > > > > alper > > > > > Erick, > > > Thanks for your feedback. Please find my > > > inline reply. I am also posting this to > > > Mobile/IP WG as this may affect > > > FMIPv6 protocol. > > > Regards, > > > Ajoy > > > > > > -----Original Message----- > > > From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] > > > Sent: Tuesday, January 07, 2003 2:02 PM > > > To: Singh Ajoy-ASINGH1 > > > Cc: 'Erik Nordmark'; mankin@psg.com; 'James Kempf'; Seamoby@ietf.org > > > Subject: RE: [Seamoby] CARD - FMIPv6 protocol interworking > > > > > > > > > > > > Part of the tradeoffs with piggybacking has to do with implementation > > > considerations. > > > In order to do piggybacking of CARD on e.g. FMIPv6 the same piece > > > of software needs to implement both protocols. Thus you loose some > > > implementation flexibility if you want piggybacking which, depending > > > on how CARD and FMIPv6 are deployed, might make deployment harder. > > > > > > For instance, if FMIPv6 is already implemented and deployed by vendor X > > and Y > > > but those vendors do not have plans to update their implementations to add > > > CARD, then you can't really deploy CARD as an add-on piece of software > > that > > > people can download. > > > > > > AJOY-> Good point. So, I guess we should define both generic ICMP options > > > as well as the carrier of the generic options (new messages) in the base > > CARD > > > draft. This will eliminate the issue raised by you. Additionally, the > > FMIPv6 > > > draft may describe how to piggyback CARD options on FMIPv6 messages. > > > This will enable FMIPv6 implementation to take advantage of the > > > efficient implementataion of the CARD. I do agree in this case both CARD > > > and FMIPv6 must be developed by same vendor which is ok. > > > > > > But if most people that are going to implement one of the protocols is > > > going to implement the other as well then this wouldn't be a concern. > > > > > > AJOY-> I think this will be the most common scenario. Hence, it makes > > > sense to piggyback CARD options on FMIPv6 messages. > > > But I guess this is mostly an FMIPv6 issue and probably should be > > addressed > > > in FMIPv6 draft. What other's think? > > > > > > So I think it all depends on whether most people view this as two pieces > > > of the same protocol, or merely two different protocols operating between > > > the same set of nodes. In the latter case I think you want the > > implementation > > > flexibility of different implementers providing the different protocols > > for > > > the same box. > > > > > > Erik > > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Jan 8 19:23:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14666 for ; Wed, 8 Jan 2003 19:23:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h090Yme01927 for seamoby-archive@odin.ietf.org; Wed, 8 Jan 2003 19:34:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h090YmJ01924 for ; Wed, 8 Jan 2003 19:34:48 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14639 for ; Wed, 8 Jan 2003 19:22:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h090XMJ01889; Wed, 8 Jan 2003 19:33:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h090W7J01853 for ; Wed, 8 Jan 2003 19:32:07 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14578 for ; Wed, 8 Jan 2003 19:20:10 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h090NVE12459 for ; Wed, 8 Jan 2003 18:23:31 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 8 Jan 2003 18:23:25 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 8 Jan 2003 18:23:05 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol interworking Date: Wed, 8 Jan 2003 19:23:04 -0500 Message-ID: Thread-Topic: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol interworking Thread-Index: AcK3XrwvW0q+wchYR+eR225ek4nRZwAFeazA To: , Cc: , X-OriginalArrivalTime: 09 Jan 2003 00:23:05.0521 (UTC) FILETIME=[474EFA10:01C2B775] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h090W8J01856 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi: I don't understand this distinction between protocol and options. All protocols have options, extensions and optimizations. How does one define if something is a protocol and something is an option? CARD has in its charter designing a mechanism to provide L2 ID to IP adr. mapping. Of course, static configuration is one of them. But, it is a trivial solution and does not warrant any discussion or specific mention. Then, there can be more sophisticated solutions. If implementer sees any benefits in using sophisticated solutions, he may do so. If he thinks it is too much, he can let it go. Hemant -----Original Message----- From: ext Rajeev Koodli [mailto:rajeev@iprg.nokia.com] Sent: Wednesday, January 08, 2003 4:40 PM To: Krishnamurthi Govind (NRC/Boston) Cc: alper@docomolabs-usa.com; Seamoby@ietf.org Subject: Re: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol interworking Govind.Krishnamurthi@nokia.com wrote: > Rajeev, > > What you describe as alternatives is just ways of performing CARD IMO, each one having pros and cons. One of the functionalities of CARD (however you do it) is to fill up this mapping table. > Doing it statically is just one way of doing it. > OK, if CARD means a set of options to chose from and not _a_ protocol, then I agree with you. My impression was CARD is a protocol in works. -Rajeev > > Govind. > > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: Wednesday, January 08, 2003 1:01 PM > To: Krishnamurthi Govind (NRC/Boston) > Cc: alper@docomolabs-usa.com; Seamoby@ietf.org > Subject: Re: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol > interworking > > Govind, > > Govind.Krishnamurthi@nokia.com wrote: > > > > > [Govind] What you describe there are carriers that take the messages from > > and to the MN. I don't think anyone is discounting the fact that > > if FMIPv6 is available and is adapted to the needs of CARD these > > messages can be used as carriers. However, CARD also talks about > > capabilities discovery and mapping capabilities to the requirements > > of the MN. Also, FMIPv6 needs "something" to fill in the mapping > > from link layer id to L3 id. CARD does that. > > This is not an accurate characterization. FMIPv6 can work without CARD. > How the map containing the [AP-ID, AR-prefix] tuple is computed on the > access router is orthogonal to the operation of FMIPv6. One could use CARD > or static configuration, or any link state routing protocol (with extensions) > for > that matter to compute the map. > > -Rajeev > > > > > > > Are there other consumers, usage scenarios of CARD? > > [Govind] Several potential uses are listed in the issues draft. > > > > alper > > > > > Erick, > > > Thanks for your feedback. Please find my > > > inline reply. I am also posting this to > > > Mobile/IP WG as this may affect > > > FMIPv6 protocol. > > > Regards, > > > Ajoy > > > > > > -----Original Message----- > > > From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] > > > Sent: Tuesday, January 07, 2003 2:02 PM > > > To: Singh Ajoy-ASINGH1 > > > Cc: 'Erik Nordmark'; mankin@psg.com; 'James Kempf'; Seamoby@ietf.org > > > Subject: RE: [Seamoby] CARD - FMIPv6 protocol interworking > > > > > > > > > > > > Part of the tradeoffs with piggybacking has to do with implementation > > > considerations. > > > In order to do piggybacking of CARD on e.g. FMIPv6 the same piece > > > of software needs to implement both protocols. Thus you loose some > > > implementation flexibility if you want piggybacking which, depending > > > on how CARD and FMIPv6 are deployed, might make deployment harder. > > > > > > For instance, if FMIPv6 is already implemented and deployed by vendor X > > and Y > > > but those vendors do not have plans to update their implementations to add > > > CARD, then you can't really deploy CARD as an add-on piece of software > > that > > > people can download. > > > > > > AJOY-> Good point. So, I guess we should define both generic ICMP options > > > as well as the carrier of the generic options (new messages) in the base > > CARD > > > draft. This will eliminate the issue raised by you. Additionally, the > > FMIPv6 > > > draft may describe how to piggyback CARD options on FMIPv6 messages. > > > This will enable FMIPv6 implementation to take advantage of the > > > efficient implementataion of the CARD. I do agree in this case both CARD > > > and FMIPv6 must be developed by same vendor which is ok. > > > > > > But if most people that are going to implement one of the protocols is > > > going to implement the other as well then this wouldn't be a concern. > > > > > > AJOY-> I think this will be the most common scenario. Hence, it makes > > > sense to piggyback CARD options on FMIPv6 messages. > > > But I guess this is mostly an FMIPv6 issue and probably should be > > addressed > > > in FMIPv6 draft. What other's think? > > > > > > So I think it all depends on whether most people view this as two pieces > > > of the same protocol, or merely two different protocols operating between > > > the same set of nodes. In the latter case I think you want the > > implementation > > > flexibility of different implementers providing the different protocols > > for > > > the same box. > > > > > > Erik > > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Jan 8 21:18:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17152 for ; Wed, 8 Jan 2003 21:18:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h092TbJ08422; Wed, 8 Jan 2003 21:29:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h091s7J06321 for ; Wed, 8 Jan 2003 20:54:07 -0500 Received: from patan.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16651 for ; Wed, 8 Jan 2003 20:42:03 -0500 (EST) Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA15859; Wed, 8 Jan 2003 18:45:18 -0700 (MST) Received: from localhost (d-mpk17-85-141.Eng.Sun.COM [129.146.85.141]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h091jFP00405; Thu, 9 Jan 2003 02:45:15 +0100 (MET) Date: Thu, 9 Jan 2003 02:41:52 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: [Seamoby] CARD - FMIPv6 protocol interworking To: Hemant.Chaskar@nokia.com Cc: Erik.Nordmark@Sun.COM, ASINGH1@motorola.com, mankin@psg.com, kempf@docomolabs-usa.com, Seamoby@ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , > In the current CARD protocol draft, we have defined CARD ICMP type. This > enables standalone implementation of CARD, independent of FMIPv6. There are > two ICMP options for this type, namely, Request and Response. Each of those > options have sub-options carrying CARD info. OK. > At the same time, to allow for integration with FMIPv6, if that is the > implementers' choice, CARD Request and Response can be piggybacked on FMIPv6 > signaling. This however, imposes the restriction that CARD signaling events > must be aligned with FMIPv6 signaling events. And that the FMIPv6 sender only perform such piggybacking when the FMIPv6 receiver is capable to process the received piggybacked info. Thus this can't be an independent choice for an implementor - you might need a mechanism in FMIPv6 to know whether the peer supports CARD piggybacking on the FMIPv6 messages. > To eliminate this restriction when integrating with FMIPv6, we were > considering a possibility of the type, say, send Request in CARD ICMP type > and possibly receive response in FMIPv6 message with CARD Response option > piggybacked on it. For this however, Request and Response options need to > have sequence ID field of their own. So you would send a CARD message that says "if you'd like I can accept the response as a CARD message or piggybacked on a FMIPv6 message". If you always use that type of exchange you handle the capability discovery part. But aren't there also cases when you want to piggyback something on the CARD request? Do we already know that CARD would be logically sent first? Or will there (also) be a need for the inverse piggybacking (carrying FMIPv6 information in CARD ICMP messages?) Erik _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Jan 8 21:19:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17178 for ; Wed, 8 Jan 2003 21:19:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h092UkK08472 for seamoby-archive@odin.ietf.org; Wed, 8 Jan 2003 21:30:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h092UkJ08469 for ; Wed, 8 Jan 2003 21:30:46 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17155 for ; Wed, 8 Jan 2003 21:18:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h092TbJ08422; Wed, 8 Jan 2003 21:29:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h091s7J06321 for ; Wed, 8 Jan 2003 20:54:07 -0500 Received: from patan.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16651 for ; Wed, 8 Jan 2003 20:42:03 -0500 (EST) Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA15859; Wed, 8 Jan 2003 18:45:18 -0700 (MST) Received: from localhost (d-mpk17-85-141.Eng.Sun.COM [129.146.85.141]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h091jFP00405; Thu, 9 Jan 2003 02:45:15 +0100 (MET) Date: Thu, 9 Jan 2003 02:41:52 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: [Seamoby] CARD - FMIPv6 protocol interworking To: Hemant.Chaskar@nokia.com Cc: Erik.Nordmark@Sun.COM, ASINGH1@motorola.com, mankin@psg.com, kempf@docomolabs-usa.com, Seamoby@ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , > In the current CARD protocol draft, we have defined CARD ICMP type. This > enables standalone implementation of CARD, independent of FMIPv6. There are > two ICMP options for this type, namely, Request and Response. Each of those > options have sub-options carrying CARD info. OK. > At the same time, to allow for integration with FMIPv6, if that is the > implementers' choice, CARD Request and Response can be piggybacked on FMIPv6 > signaling. This however, imposes the restriction that CARD signaling events > must be aligned with FMIPv6 signaling events. And that the FMIPv6 sender only perform such piggybacking when the FMIPv6 receiver is capable to process the received piggybacked info. Thus this can't be an independent choice for an implementor - you might need a mechanism in FMIPv6 to know whether the peer supports CARD piggybacking on the FMIPv6 messages. > To eliminate this restriction when integrating with FMIPv6, we were > considering a possibility of the type, say, send Request in CARD ICMP type > and possibly receive response in FMIPv6 message with CARD Response option > piggybacked on it. For this however, Request and Response options need to > have sequence ID field of their own. So you would send a CARD message that says "if you'd like I can accept the response as a CARD message or piggybacked on a FMIPv6 message". If you always use that type of exchange you handle the capability discovery part. But aren't there also cases when you want to piggyback something on the CARD request? Do we already know that CARD would be logically sent first? Or will there (also) be a need for the inverse piggybacking (carrying FMIPv6 information in CARD ICMP messages?) Erik _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Jan 8 23:27:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19145 for ; Wed, 8 Jan 2003 23:27:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h094cJJ15281; Wed, 8 Jan 2003 23:38:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h094auJ14625 for ; Wed, 8 Jan 2003 23:36:56 -0500 Received: from hotmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19108 for ; Wed, 8 Jan 2003 23:24:54 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 8 Jan 2003 20:28:09 -0800 Received: from 66.30.240.206 by lw7fd.law7.hotmail.msn.com with HTTP; Thu, 09 Jan 2003 04:28:08 GMT X-Originating-IP: [66.30.240.206] From: "Hemant Chaskar" To: Erik.Nordmark@Sun.COM Cc: ASINGH1@motorola.com, mankin@psg.com, kempf@docomolabs-usa.com, Seamoby@ietf.org Subject: RE: [Seamoby] CARD - FMIPv6 protocol interworking Date: Thu, 09 Jan 2003 04:28:08 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 09 Jan 2003 04:28:09.0754 (UTC) FILETIME=[83B6DFA0:01C2B797] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Hi Erik: See some comments below as [HMC]: >From: Erik Nordmark >Reply-To: Erik Nordmark >To: Hemant.Chaskar@nokia.com >CC: Erik.Nordmark@Sun.COM, ASINGH1@motorola.com, mankin@psg.com, >kempf@docomolabs-usa.com, Seamoby@ietf.org >Subject: RE: [Seamoby] CARD - FMIPv6 protocol interworking >Date: Thu, 9 Jan 2003 02:41:52 +0100 (CET) > > > > In the current CARD protocol draft, we have defined CARD ICMP type. This > > enables standalone implementation of CARD, independent of FMIPv6. There >are > > two ICMP options for this type, namely, Request and Response. Each of >those > > options have sub-options carrying CARD info. > >OK. > > > At the same time, to allow for integration with FMIPv6, if that is the > > implementers' choice, CARD Request and Response can be piggybacked on >FMIPv6 > > signaling. This however, imposes the restriction that CARD signaling >events > > must be aligned with FMIPv6 signaling events. > >And that the FMIPv6 sender only perform such piggybacking when the FMIPv6 >receiver is capable to process the received piggybacked info. >Thus this can't be an independent choice for an implementor - you might >need >a mechanism in FMIPv6 to know whether the peer supports CARD piggybacking >on the FMIPv6 messages. [HMC] I agree. For this FMIPv6 spec needs to recognize CARD options and suboptions as well. > > > To eliminate this restriction when integrating with FMIPv6, we were > > considering a possibility of the type, say, send Request in CARD ICMP >type > > and possibly receive response in FMIPv6 message with CARD Response >option > > piggybacked on it. For this however, Request and Response options need >to > > have sequence ID field of their own. > >So you would send a CARD message that says "if you'd like I can accept >the response as a CARD message or piggybacked on a FMIPv6 message". >If you always use that type of exchange you handle the capability discovery >part. > >But aren't there also cases when you want to piggyback something on >the CARD request? > >Do we already know that CARD would be logically sent first? >Or will there (also) be a need for the inverse piggybacking (carrying >FMIPv6 >information in CARD ICMP messages?) [HMC] I agree. But then, a better approach could be to define combined CARD/FMIPv6 ICMP type. The corresponding options can be FMIPv6 options or CARD options. So, as I see there are two approaches possible: (1) CARD ICMP type with its options and suboptions. It is implementation's task to properly sync CARD and FMIPv6 state machines in MN and AR. (2) A combined FMIPv6/CARD ICMP type with options and suboptions for both FMIPv6 and CARD. What does the WG think about this? Hemant > > Erik > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Jan 8 23:27:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19165 for ; Wed, 8 Jan 2003 23:27:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h094dOt15318 for seamoby-archive@odin.ietf.org; Wed, 8 Jan 2003 23:39:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h094dOJ15315 for ; Wed, 8 Jan 2003 23:39:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19148 for ; Wed, 8 Jan 2003 23:27:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h094cJJ15281; Wed, 8 Jan 2003 23:38:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h094auJ14625 for ; Wed, 8 Jan 2003 23:36:56 -0500 Received: from hotmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19108 for ; Wed, 8 Jan 2003 23:24:54 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 8 Jan 2003 20:28:09 -0800 Received: from 66.30.240.206 by lw7fd.law7.hotmail.msn.com with HTTP; Thu, 09 Jan 2003 04:28:08 GMT X-Originating-IP: [66.30.240.206] From: "Hemant Chaskar" To: Erik.Nordmark@Sun.COM Cc: ASINGH1@motorola.com, mankin@psg.com, kempf@docomolabs-usa.com, Seamoby@ietf.org Subject: RE: [Seamoby] CARD - FMIPv6 protocol interworking Date: Thu, 09 Jan 2003 04:28:08 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 09 Jan 2003 04:28:09.0754 (UTC) FILETIME=[83B6DFA0:01C2B797] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Hi Erik: See some comments below as [HMC]: >From: Erik Nordmark >Reply-To: Erik Nordmark >To: Hemant.Chaskar@nokia.com >CC: Erik.Nordmark@Sun.COM, ASINGH1@motorola.com, mankin@psg.com, >kempf@docomolabs-usa.com, Seamoby@ietf.org >Subject: RE: [Seamoby] CARD - FMIPv6 protocol interworking >Date: Thu, 9 Jan 2003 02:41:52 +0100 (CET) > > > > In the current CARD protocol draft, we have defined CARD ICMP type. This > > enables standalone implementation of CARD, independent of FMIPv6. There >are > > two ICMP options for this type, namely, Request and Response. Each of >those > > options have sub-options carrying CARD info. > >OK. > > > At the same time, to allow for integration with FMIPv6, if that is the > > implementers' choice, CARD Request and Response can be piggybacked on >FMIPv6 > > signaling. This however, imposes the restriction that CARD signaling >events > > must be aligned with FMIPv6 signaling events. > >And that the FMIPv6 sender only perform such piggybacking when the FMIPv6 >receiver is capable to process the received piggybacked info. >Thus this can't be an independent choice for an implementor - you might >need >a mechanism in FMIPv6 to know whether the peer supports CARD piggybacking >on the FMIPv6 messages. [HMC] I agree. For this FMIPv6 spec needs to recognize CARD options and suboptions as well. > > > To eliminate this restriction when integrating with FMIPv6, we were > > considering a possibility of the type, say, send Request in CARD ICMP >type > > and possibly receive response in FMIPv6 message with CARD Response >option > > piggybacked on it. For this however, Request and Response options need >to > > have sequence ID field of their own. > >So you would send a CARD message that says "if you'd like I can accept >the response as a CARD message or piggybacked on a FMIPv6 message". >If you always use that type of exchange you handle the capability discovery >part. > >But aren't there also cases when you want to piggyback something on >the CARD request? > >Do we already know that CARD would be logically sent first? >Or will there (also) be a need for the inverse piggybacking (carrying >FMIPv6 >information in CARD ICMP messages?) [HMC] I agree. But then, a better approach could be to define combined CARD/FMIPv6 ICMP type. The corresponding options can be FMIPv6 options or CARD options. So, as I see there are two approaches possible: (1) CARD ICMP type with its options and suboptions. It is implementation's task to properly sync CARD and FMIPv6 state machines in MN and AR. (2) A combined FMIPv6/CARD ICMP type with options and suboptions for both FMIPv6 and CARD. What does the WG think about this? Hemant > > Erik > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Jan 13 14:52:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21625 for ; Mon, 13 Jan 2003 14:52:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DK5pJ17922; Mon, 13 Jan 2003 15:05:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DK3mJ17833 for ; Mon, 13 Jan 2003 15:03:48 -0500 Received: from ftpbox.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21534 for ; Mon, 13 Jan 2003 14:49:28 -0500 (EST) Received: from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h0DJqluP023138 for ; Mon, 13 Jan 2003 12:52:48 -0700 (MST) Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id MAA27260 for ; Mon, 13 Jan 2003 12:52:47 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Mon, 13 Jan 2003 13:52:47 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD5C6D@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Hemant.Chaskar@nokia.com'" , Seamoby@ietf.org Cc: Nakhjiri Madjid-MNAKHJI1 Subject: RE: [Seamoby] CARD feeding TAR selection issue Date: Mon, 13 Jan 2003 13:52:36 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Hi Hemant, Sorry for being a bit late in the discussion. I think we need to be careful in ruling one versus the other approach. As I recall, interdomain was a secondary concern for CARD, so why the most control is in the hand of the MN (network control is only optional?) I have a few concerns: 1-Air bandwidth: it is either very scarce, or tightly controlled. Sending a lot of gathered information in either direction is either not very economic, or needs prior QoS mechanism support. Sometimes the MN hears a lot of beacons (specially in an inter-domain/ access tech case) sometimes the network has most of the information (I think this is more often). Either we need to allow both cases (selection at either MN or network, depending on where it is collected) or send only parts of the data (say: one side makes a partial decision and offers a few options to selecting party). 2-Network management: Networks that have tight (central and distributed) management approach, are more paranoid about their resources and don't want to have the MN make such decision (not to mention the denial of service issues this may have), would want to do the selection themselves. On the other for inter-domain cases, MN involvement maybe inevitable. It seems to me that a network based selection should be the base approach?? Regards, Madjid -----Original Message----- From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] Sent: Sunday, January 05, 2003 4:46 PM To: Seamoby@ietf.org Subject: [Seamoby] CARD feeding TAR selection issue Hi all: In order to proceed with next version of CARD draft, the design team would like to seek WG consensus on the following way of CARD operation, so that it can be used for TAR selection. TAR selection is defined as selecting a unique AR for handoff from a set of CARs. For this, TAR selection module needs access to CAR identities and their capabilities. TAR selection module resides in the MN. Base protocol: -------------- Step 1: MN collects the identities of CARs (after listening to AP beacons from them) and their capabilities using CARD protocol. For this, MN queries either current AR or new AR (depending upon whether is it doing CARD in MN orchestrated or network assisted mode) and receives this information. For a given CAR, its entire capability set is provided to MN. Step 2: MN runs TAR selection algorithm to choose TAR at the time of handoff. Optional optimizations to the base protocol: -------------------------------------------- Capability pre-filtering: Step 1A: To avoid sending whole capability set of any CAR to MN, especially if MN is not interested in all those capabilities, in the CARD query MN can specify the capabilities that it is interested in receiving (by specifying capability attributes). Step 1B: Even when capabilities of interest are specified by MN in query, to avoid sending information on CARs that MN is not obviously going to like, MN can also specify in the query to send CAR information if the capability of interest is above a threshold (attribute being greater than some value). Network policies: Network policies (in network assisted CARD) can be implemented indirectly by current AR. In other words, current AR may not send information about certain CARs to MN, if network policy in unfavorable to those CARs. In an extreme case, if network sends to MN information about only one CAR, it is tantamount to performing TAR selection on current AR. Please provide your feedback on this. Thanks, Hemant _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Jan 13 14:53:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21649 for ; Mon, 13 Jan 2003 14:53:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0DK7I218345 for seamoby-archive@odin.ietf.org; Mon, 13 Jan 2003 15:07:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DK7IJ18336 for ; Mon, 13 Jan 2003 15:07:18 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21628 for ; Mon, 13 Jan 2003 14:52:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DK5pJ17922; Mon, 13 Jan 2003 15:05:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DK3mJ17833 for ; Mon, 13 Jan 2003 15:03:48 -0500 Received: from ftpbox.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21534 for ; Mon, 13 Jan 2003 14:49:28 -0500 (EST) Received: from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h0DJqluP023138 for ; Mon, 13 Jan 2003 12:52:48 -0700 (MST) Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id MAA27260 for ; Mon, 13 Jan 2003 12:52:47 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Mon, 13 Jan 2003 13:52:47 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD5C6D@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Hemant.Chaskar@nokia.com'" , Seamoby@ietf.org Cc: Nakhjiri Madjid-MNAKHJI1 Subject: RE: [Seamoby] CARD feeding TAR selection issue Date: Mon, 13 Jan 2003 13:52:36 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Hi Hemant, Sorry for being a bit late in the discussion. I think we need to be careful in ruling one versus the other approach. As I recall, interdomain was a secondary concern for CARD, so why the most control is in the hand of the MN (network control is only optional?) I have a few concerns: 1-Air bandwidth: it is either very scarce, or tightly controlled. Sending a lot of gathered information in either direction is either not very economic, or needs prior QoS mechanism support. Sometimes the MN hears a lot of beacons (specially in an inter-domain/ access tech case) sometimes the network has most of the information (I think this is more often). Either we need to allow both cases (selection at either MN or network, depending on where it is collected) or send only parts of the data (say: one side makes a partial decision and offers a few options to selecting party). 2-Network management: Networks that have tight (central and distributed) management approach, are more paranoid about their resources and don't want to have the MN make such decision (not to mention the denial of service issues this may have), would want to do the selection themselves. On the other for inter-domain cases, MN involvement maybe inevitable. It seems to me that a network based selection should be the base approach?? Regards, Madjid -----Original Message----- From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] Sent: Sunday, January 05, 2003 4:46 PM To: Seamoby@ietf.org Subject: [Seamoby] CARD feeding TAR selection issue Hi all: In order to proceed with next version of CARD draft, the design team would like to seek WG consensus on the following way of CARD operation, so that it can be used for TAR selection. TAR selection is defined as selecting a unique AR for handoff from a set of CARs. For this, TAR selection module needs access to CAR identities and their capabilities. TAR selection module resides in the MN. Base protocol: -------------- Step 1: MN collects the identities of CARs (after listening to AP beacons from them) and their capabilities using CARD protocol. For this, MN queries either current AR or new AR (depending upon whether is it doing CARD in MN orchestrated or network assisted mode) and receives this information. For a given CAR, its entire capability set is provided to MN. Step 2: MN runs TAR selection algorithm to choose TAR at the time of handoff. Optional optimizations to the base protocol: -------------------------------------------- Capability pre-filtering: Step 1A: To avoid sending whole capability set of any CAR to MN, especially if MN is not interested in all those capabilities, in the CARD query MN can specify the capabilities that it is interested in receiving (by specifying capability attributes). Step 1B: Even when capabilities of interest are specified by MN in query, to avoid sending information on CARs that MN is not obviously going to like, MN can also specify in the query to send CAR information if the capability of interest is above a threshold (attribute being greater than some value). Network policies: Network policies (in network assisted CARD) can be implemented indirectly by current AR. In other words, current AR may not send information about certain CARs to MN, if network policy in unfavorable to those CARs. In an extreme case, if network sends to MN information about only one CAR, it is tantamount to performing TAR selection on current AR. Please provide your feedback on this. Thanks, Hemant _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Jan 13 15:30:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22987 for ; Mon, 13 Jan 2003 15:30:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DKi7J21015; Mon, 13 Jan 2003 15:44:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DKh1J20965 for ; Mon, 13 Jan 2003 15:43:01 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22943 for ; Mon, 13 Jan 2003 15:28:42 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0DKV6003110 for ; Mon, 13 Jan 2003 22:31:06 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 13 Jan 2003 22:31:54 +0200 Received: from daebh002.NOE.Nokia.com ([172.18.242.232]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 13 Jan 2003 22:31:53 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 13 Jan 2003 14:31:03 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CARD feeding TAR selection issue Date: Mon, 13 Jan 2003 15:31:02 -0500 Message-ID: Thread-Topic: [Seamoby] CARD feeding TAR selection issue Thread-Index: AcK7PWlA8uF2215BSbWqEnaClx+AegABMd7w To: , X-OriginalArrivalTime: 13 Jan 2003 20:31:03.0947 (UTC) FILETIME=[B1781DB0:01C2BB42] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0DKh1J20966 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Madjid: Some comments: -----Original Message----- From: ext Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] Sent: Monday, January 13, 2003 2:53 PM To: Chaskar Hemant (NRC/Boston); Seamoby@ietf.org Cc: Nakhjiri Madjid-MNAKHJI1 Subject: RE: [Seamoby] CARD feeding TAR selection issue Hi Hemant, Sorry for being a bit late in the discussion. I think we need to be careful in ruling one versus the other approach. As I recall, interdomain was a secondary concern for CARD, so why the most control is in the hand of the MN (network control is only optional?) I have a few concerns: 1-Air bandwidth: it is either very scarce, or tightly controlled. Sending a lot of gathered information in either direction is either not very economic, or needs prior QoS mechanism support. Sometimes the MN hears a lot of beacons (specially in an inter-domain/ access tech case) sometimes the network has most of the information (I think this is more often). [Hemant]In consideration to air bandwidth and MN processing power, I think we should at least have step 1A. That will curtail some overhead on link bandwidth and MN processing power. It also enables to define a large set of possible capability parameters. Either we need to allow both cases (selection at either MN or network, depending on where it is collected) or send only parts of the data (say: one side makes a partial decision and offers a few options to selecting party). [Hemant] For network to be able to make decision, we need to provide it with the information on MN requirements. This was the intent of step 1B. But, there was some complexity concern on mailing list as regards this step. 2-Network management: Networks that have tight (central and distributed) management approach, are more paranoid about their resources and don't want to have the MN make such decision (not to mention the denial of service issues this may have), would want to do the selection themselves. On the other for inter-domain cases, MN involvement maybe inevitable. It seems to me that a network based selection should be the base approach?? Regards, Madjid -----Original Message----- From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] Sent: Sunday, January 05, 2003 4:46 PM To: Seamoby@ietf.org Subject: [Seamoby] CARD feeding TAR selection issue Hi all: In order to proceed with next version of CARD draft, the design team would like to seek WG consensus on the following way of CARD operation, so that it can be used for TAR selection. TAR selection is defined as selecting a unique AR for handoff from a set of CARs. For this, TAR selection module needs access to CAR identities and their capabilities. TAR selection module resides in the MN. Base protocol: -------------- Step 1: MN collects the identities of CARs (after listening to AP beacons from them) and their capabilities using CARD protocol. For this, MN queries either current AR or new AR (depending upon whether is it doing CARD in MN orchestrated or network assisted mode) and receives this information. For a given CAR, its entire capability set is provided to MN. Step 2: MN runs TAR selection algorithm to choose TAR at the time of handoff. Optional optimizations to the base protocol: -------------------------------------------- Capability pre-filtering: Step 1A: To avoid sending whole capability set of any CAR to MN, especially if MN is not interested in all those capabilities, in the CARD query MN can specify the capabilities that it is interested in receiving (by specifying capability attributes). Step 1B: Even when capabilities of interest are specified by MN in query, to avoid sending information on CARs that MN is not obviously going to like, MN can also specify in the query to send CAR information if the capability of interest is above a threshold (attribute being greater than some value). Network policies: Network policies (in network assisted CARD) can be implemented indirectly by current AR. In other words, current AR may not send information about certain CARs to MN, if network policy in unfavorable to those CARs. In an extreme case, if network sends to MN information about only one CAR, it is tantamount to performing TAR selection on current AR. Please provide your feedback on this. Thanks, Hemant _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Jan 13 15:31:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23039 for ; Mon, 13 Jan 2003 15:31:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0DKjHO21102 for seamoby-archive@odin.ietf.org; Mon, 13 Jan 2003 15:45:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DKjHJ21099 for ; Mon, 13 Jan 2003 15:45:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22990 for ; Mon, 13 Jan 2003 15:30:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DKi7J21015; Mon, 13 Jan 2003 15:44:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DKh1J20965 for ; Mon, 13 Jan 2003 15:43:01 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22943 for ; Mon, 13 Jan 2003 15:28:42 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0DKV6003110 for ; Mon, 13 Jan 2003 22:31:06 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 13 Jan 2003 22:31:54 +0200 Received: from daebh002.NOE.Nokia.com ([172.18.242.232]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 13 Jan 2003 22:31:53 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 13 Jan 2003 14:31:03 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CARD feeding TAR selection issue Date: Mon, 13 Jan 2003 15:31:02 -0500 Message-ID: Thread-Topic: [Seamoby] CARD feeding TAR selection issue Thread-Index: AcK7PWlA8uF2215BSbWqEnaClx+AegABMd7w To: , X-OriginalArrivalTime: 13 Jan 2003 20:31:03.0947 (UTC) FILETIME=[B1781DB0:01C2BB42] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0DKh1J20966 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Madjid: Some comments: -----Original Message----- From: ext Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] Sent: Monday, January 13, 2003 2:53 PM To: Chaskar Hemant (NRC/Boston); Seamoby@ietf.org Cc: Nakhjiri Madjid-MNAKHJI1 Subject: RE: [Seamoby] CARD feeding TAR selection issue Hi Hemant, Sorry for being a bit late in the discussion. I think we need to be careful in ruling one versus the other approach. As I recall, interdomain was a secondary concern for CARD, so why the most control is in the hand of the MN (network control is only optional?) I have a few concerns: 1-Air bandwidth: it is either very scarce, or tightly controlled. Sending a lot of gathered information in either direction is either not very economic, or needs prior QoS mechanism support. Sometimes the MN hears a lot of beacons (specially in an inter-domain/ access tech case) sometimes the network has most of the information (I think this is more often). [Hemant]In consideration to air bandwidth and MN processing power, I think we should at least have step 1A. That will curtail some overhead on link bandwidth and MN processing power. It also enables to define a large set of possible capability parameters. Either we need to allow both cases (selection at either MN or network, depending on where it is collected) or send only parts of the data (say: one side makes a partial decision and offers a few options to selecting party). [Hemant] For network to be able to make decision, we need to provide it with the information on MN requirements. This was the intent of step 1B. But, there was some complexity concern on mailing list as regards this step. 2-Network management: Networks that have tight (central and distributed) management approach, are more paranoid about their resources and don't want to have the MN make such decision (not to mention the denial of service issues this may have), would want to do the selection themselves. On the other for inter-domain cases, MN involvement maybe inevitable. It seems to me that a network based selection should be the base approach?? Regards, Madjid -----Original Message----- From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] Sent: Sunday, January 05, 2003 4:46 PM To: Seamoby@ietf.org Subject: [Seamoby] CARD feeding TAR selection issue Hi all: In order to proceed with next version of CARD draft, the design team would like to seek WG consensus on the following way of CARD operation, so that it can be used for TAR selection. TAR selection is defined as selecting a unique AR for handoff from a set of CARs. For this, TAR selection module needs access to CAR identities and their capabilities. TAR selection module resides in the MN. Base protocol: -------------- Step 1: MN collects the identities of CARs (after listening to AP beacons from them) and their capabilities using CARD protocol. For this, MN queries either current AR or new AR (depending upon whether is it doing CARD in MN orchestrated or network assisted mode) and receives this information. For a given CAR, its entire capability set is provided to MN. Step 2: MN runs TAR selection algorithm to choose TAR at the time of handoff. Optional optimizations to the base protocol: -------------------------------------------- Capability pre-filtering: Step 1A: To avoid sending whole capability set of any CAR to MN, especially if MN is not interested in all those capabilities, in the CARD query MN can specify the capabilities that it is interested in receiving (by specifying capability attributes). Step 1B: Even when capabilities of interest are specified by MN in query, to avoid sending information on CARs that MN is not obviously going to like, MN can also specify in the query to send CAR information if the capability of interest is above a threshold (attribute being greater than some value). Network policies: Network policies (in network assisted CARD) can be implemented indirectly by current AR. In other words, current AR may not send information about certain CARs to MN, if network policy in unfavorable to those CARs. In an extreme case, if network sends to MN information about only one CAR, it is tantamount to performing TAR selection on current AR. Please provide your feedback on this. Thanks, Hemant _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Jan 13 15:34:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23252 for ; Mon, 13 Jan 2003 15:34:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DKm8J21256; Mon, 13 Jan 2003 15:48:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DKlqJ21221 for ; Mon, 13 Jan 2003 15:47:52 -0500 Received: from motgate.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23170 for ; Mon, 13 Jan 2003 15:33:34 -0500 (EST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h0DKaqW4029240 for ; Mon, 13 Jan 2003 13:36:52 -0700 (MST) Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id NAA29096 for ; Mon, 13 Jan 2003 13:36:14 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Mon, 13 Jan 2003 14:36:52 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD5C6E@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Hemant.Chaskar@nokia.com'" , Nakhjiri Madjid-MNAKHJI1 , Seamoby@ietf.org Subject: RE: [Seamoby] CARD feeding TAR selection issue Date: Mon, 13 Jan 2003 14:36:31 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Hi Hemant, Seems like we are in agreement. My reaction was to the word "optional" in "Optional optimizations to the base protocol" If optional means, you include it in your design but provide a switch for it, then I am fine. But if the procedure is not considered at all, then the protocol may be of limited use. Seems like it is former case, right? then I am fine, if the working group considers it too complex. Regards, Madjid -----Original Message----- From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] Sent: Monday, January 13, 2003 2:31 PM To: Madjid Nakhjiri; Seamoby@ietf.org Subject: RE: [Seamoby] CARD feeding TAR selection issue Hi Madjid: Some comments: -----Original Message----- From: ext Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] Sent: Monday, January 13, 2003 2:53 PM To: Chaskar Hemant (NRC/Boston); Seamoby@ietf.org Cc: Nakhjiri Madjid-MNAKHJI1 Subject: RE: [Seamoby] CARD feeding TAR selection issue Hi Hemant, Sorry for being a bit late in the discussion. I think we need to be careful in ruling one versus the other approach. As I recall, interdomain was a secondary concern for CARD, so why the most control is in the hand of the MN (network control is only optional?) I have a few concerns: 1-Air bandwidth: it is either very scarce, or tightly controlled. Sending a lot of gathered information in either direction is either not very economic, or needs prior QoS mechanism support. Sometimes the MN hears a lot of beacons (specially in an inter-domain/ access tech case) sometimes the network has most of the information (I think this is more often). [Hemant]In consideration to air bandwidth and MN processing power, I think we should at least have step 1A. That will curtail some overhead on link bandwidth and MN processing power. It also enables to define a large set of possible capability parameters. Either we need to allow both cases (selection at either MN or network, depending on where it is collected) or send only parts of the data (say: one side makes a partial decision and offers a few options to selecting party). [Hemant] For network to be able to make decision, we need to provide it with the information on MN requirements. This was the intent of step 1B. But, there was some complexity concern on mailing list as regards this step. 2-Network management: Networks that have tight (central and distributed) management approach, are more paranoid about their resources and don't want to have the MN make such decision (not to mention the denial of service issues this may have), would want to do the selection themselves. On the other for inter-domain cases, MN involvement maybe inevitable. It seems to me that a network based selection should be the base approach?? Regards, Madjid -----Original Message----- From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] Sent: Sunday, January 05, 2003 4:46 PM To: Seamoby@ietf.org Subject: [Seamoby] CARD feeding TAR selection issue Hi all: In order to proceed with next version of CARD draft, the design team would like to seek WG consensus on the following way of CARD operation, so that it can be used for TAR selection. TAR selection is defined as selecting a unique AR for handoff from a set of CARs. For this, TAR selection module needs access to CAR identities and their capabilities. TAR selection module resides in the MN. Base protocol: -------------- Step 1: MN collects the identities of CARs (after listening to AP beacons from them) and their capabilities using CARD protocol. For this, MN queries either current AR or new AR (depending upon whether is it doing CARD in MN orchestrated or network assisted mode) and receives this information. For a given CAR, its entire capability set is provided to MN. Step 2: MN runs TAR selection algorithm to choose TAR at the time of handoff. Optional optimizations to the base protocol: -------------------------------------------- Capability pre-filtering: Step 1A: To avoid sending whole capability set of any CAR to MN, especially if MN is not interested in all those capabilities, in the CARD query MN can specify the capabilities that it is interested in receiving (by specifying capability attributes). Step 1B: Even when capabilities of interest are specified by MN in query, to avoid sending information on CARs that MN is not obviously going to like, MN can also specify in the query to send CAR information if the capability of interest is above a threshold (attribute being greater than some value). Network policies: Network policies (in network assisted CARD) can be implemented indirectly by current AR. In other words, current AR may not send information about certain CARs to MN, if network policy in unfavorable to those CARs. In an extreme case, if network sends to MN information about only one CAR, it is tantamount to performing TAR selection on current AR. Please provide your feedback on this. Thanks, Hemant _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Jan 13 15:35:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23273 for ; Mon, 13 Jan 2003 15:35:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0DKnIZ21309 for seamoby-archive@odin.ietf.org; Mon, 13 Jan 2003 15:49:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DKnIJ21306 for ; Mon, 13 Jan 2003 15:49:18 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23255 for ; Mon, 13 Jan 2003 15:34:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DKm8J21256; Mon, 13 Jan 2003 15:48:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DKlqJ21221 for ; Mon, 13 Jan 2003 15:47:52 -0500 Received: from motgate.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23170 for ; Mon, 13 Jan 2003 15:33:34 -0500 (EST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h0DKaqW4029240 for ; Mon, 13 Jan 2003 13:36:52 -0700 (MST) Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id NAA29096 for ; Mon, 13 Jan 2003 13:36:14 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Mon, 13 Jan 2003 14:36:52 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD5C6E@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Hemant.Chaskar@nokia.com'" , Nakhjiri Madjid-MNAKHJI1 , Seamoby@ietf.org Subject: RE: [Seamoby] CARD feeding TAR selection issue Date: Mon, 13 Jan 2003 14:36:31 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Hi Hemant, Seems like we are in agreement. My reaction was to the word "optional" in "Optional optimizations to the base protocol" If optional means, you include it in your design but provide a switch for it, then I am fine. But if the procedure is not considered at all, then the protocol may be of limited use. Seems like it is former case, right? then I am fine, if the working group considers it too complex. Regards, Madjid -----Original Message----- From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] Sent: Monday, January 13, 2003 2:31 PM To: Madjid Nakhjiri; Seamoby@ietf.org Subject: RE: [Seamoby] CARD feeding TAR selection issue Hi Madjid: Some comments: -----Original Message----- From: ext Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] Sent: Monday, January 13, 2003 2:53 PM To: Chaskar Hemant (NRC/Boston); Seamoby@ietf.org Cc: Nakhjiri Madjid-MNAKHJI1 Subject: RE: [Seamoby] CARD feeding TAR selection issue Hi Hemant, Sorry for being a bit late in the discussion. I think we need to be careful in ruling one versus the other approach. As I recall, interdomain was a secondary concern for CARD, so why the most control is in the hand of the MN (network control is only optional?) I have a few concerns: 1-Air bandwidth: it is either very scarce, or tightly controlled. Sending a lot of gathered information in either direction is either not very economic, or needs prior QoS mechanism support. Sometimes the MN hears a lot of beacons (specially in an inter-domain/ access tech case) sometimes the network has most of the information (I think this is more often). [Hemant]In consideration to air bandwidth and MN processing power, I think we should at least have step 1A. That will curtail some overhead on link bandwidth and MN processing power. It also enables to define a large set of possible capability parameters. Either we need to allow both cases (selection at either MN or network, depending on where it is collected) or send only parts of the data (say: one side makes a partial decision and offers a few options to selecting party). [Hemant] For network to be able to make decision, we need to provide it with the information on MN requirements. This was the intent of step 1B. But, there was some complexity concern on mailing list as regards this step. 2-Network management: Networks that have tight (central and distributed) management approach, are more paranoid about their resources and don't want to have the MN make such decision (not to mention the denial of service issues this may have), would want to do the selection themselves. On the other for inter-domain cases, MN involvement maybe inevitable. It seems to me that a network based selection should be the base approach?? Regards, Madjid -----Original Message----- From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] Sent: Sunday, January 05, 2003 4:46 PM To: Seamoby@ietf.org Subject: [Seamoby] CARD feeding TAR selection issue Hi all: In order to proceed with next version of CARD draft, the design team would like to seek WG consensus on the following way of CARD operation, so that it can be used for TAR selection. TAR selection is defined as selecting a unique AR for handoff from a set of CARs. For this, TAR selection module needs access to CAR identities and their capabilities. TAR selection module resides in the MN. Base protocol: -------------- Step 1: MN collects the identities of CARs (after listening to AP beacons from them) and their capabilities using CARD protocol. For this, MN queries either current AR or new AR (depending upon whether is it doing CARD in MN orchestrated or network assisted mode) and receives this information. For a given CAR, its entire capability set is provided to MN. Step 2: MN runs TAR selection algorithm to choose TAR at the time of handoff. Optional optimizations to the base protocol: -------------------------------------------- Capability pre-filtering: Step 1A: To avoid sending whole capability set of any CAR to MN, especially if MN is not interested in all those capabilities, in the CARD query MN can specify the capabilities that it is interested in receiving (by specifying capability attributes). Step 1B: Even when capabilities of interest are specified by MN in query, to avoid sending information on CARs that MN is not obviously going to like, MN can also specify in the query to send CAR information if the capability of interest is above a threshold (attribute being greater than some value). Network policies: Network policies (in network assisted CARD) can be implemented indirectly by current AR. In other words, current AR may not send information about certain CARs to MN, if network policy in unfavorable to those CARs. In an extreme case, if network sends to MN information about only one CAR, it is tantamount to performing TAR selection on current AR. Please provide your feedback on this. Thanks, Hemant _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Jan 13 16:58:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25609 for ; Mon, 13 Jan 2003 16:58:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DMBeJ26914; Mon, 13 Jan 2003 17:11:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DMAXJ26870 for ; Mon, 13 Jan 2003 17:10:33 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25566 for ; Mon, 13 Jan 2003 16:56:13 -0500 (EST) Message-ID: <035101c2bb4e$d6883890$5c6015ac@T23KEMPF> From: "James Kempf" To: Date: Mon, 13 Jan 2003 13:58:00 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] CARD between Routers - will CT do? Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit So most of the discussion here has been about CARD between the Mobile Node and Access Router, and that's OK since it certainly is an important topic. However, equally important is how two Access Routers exchange information about the access points connected to them. This could be statically configured, but that would be very inconvenient. I'm wondering if this might be a good application of CT? The "context" here would be an authenticatable list of access points connected up to a particular router. Comments? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Jan 13 16:58:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25627 for ; Mon, 13 Jan 2003 16:58:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0DMCjf26947 for seamoby-archive@odin.ietf.org; Mon, 13 Jan 2003 17:12:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DMCjJ26944 for ; Mon, 13 Jan 2003 17:12:45 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25612 for ; Mon, 13 Jan 2003 16:58:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DMBeJ26914; Mon, 13 Jan 2003 17:11:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DMAXJ26870 for ; Mon, 13 Jan 2003 17:10:33 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25566 for ; Mon, 13 Jan 2003 16:56:13 -0500 (EST) Message-ID: <035101c2bb4e$d6883890$5c6015ac@T23KEMPF> From: "James Kempf" To: Date: Mon, 13 Jan 2003 13:58:00 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] CARD between Routers - will CT do? Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit So most of the discussion here has been about CARD between the Mobile Node and Access Router, and that's OK since it certainly is an important topic. However, equally important is how two Access Routers exchange information about the access points connected to them. This could be statically configured, but that would be very inconvenient. I'm wondering if this might be a good application of CT? The "context" here would be an authenticatable list of access points connected up to a particular router. Comments? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Jan 13 17:31:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26483 for ; Mon, 13 Jan 2003 17:31:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DMjDJ28919; Mon, 13 Jan 2003 17:45:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DMilJ28899 for ; Mon, 13 Jan 2003 17:44:47 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26432 for ; Mon, 13 Jan 2003 17:30:23 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0DMXmB20152 for ; Mon, 13 Jan 2003 16:33:49 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 13 Jan 2003 16:33:42 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 13 Jan 2003 14:33:41 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CARD between Routers - will CT do? Date: Mon, 13 Jan 2003 17:33:41 -0500 Message-ID: Thread-Topic: [Seamoby] CARD between Routers - will CT do? Thread-Index: AcK7UI/8PjjTAWn5S4GYa/ZQ+4bAMAAABXLA To: , X-OriginalArrivalTime: 13 Jan 2003 22:33:41.0912 (UTC) FILETIME=[D3287980:01C2BB53] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0DMilJ28900 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hello James, I wouldn't want to tie it up with CT for the following reason. This information may be needed to refreshed at times other than that during handovers, which is when CT happens. Infact, this information is more important prior to the handover process. How does an AR discover any change in the AP configuration? I think this should be stored as soft state and should be refreshed min(when an AR knows of an AP configuration change, lifetime expiration). Also, right now, contexts are MN specific. This is not MN specific context. Let me know if I have misunderstood your comment. Thanks, Govind. -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Monday, January 13, 2003 4:58 PM To: seamoby@ietf.org Subject: [Seamoby] CARD between Routers - will CT do? So most of the discussion here has been about CARD between the Mobile Node and Access Router, and that's OK since it certainly is an important topic. However, equally important is how two Access Routers exchange information about the access points connected to them. This could be statically configured, but that would be very inconvenient. I'm wondering if this might be a good application of CT? The "context" here would be an authenticatable list of access points connected up to a particular router. Comments? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Jan 13 17:32:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26505 for ; Mon, 13 Jan 2003 17:32:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0DMkJ228973 for seamoby-archive@odin.ietf.org; Mon, 13 Jan 2003 17:46:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DMkJJ28970 for ; Mon, 13 Jan 2003 17:46:19 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26486 for ; Mon, 13 Jan 2003 17:31:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DMjDJ28919; Mon, 13 Jan 2003 17:45:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DMilJ28899 for ; Mon, 13 Jan 2003 17:44:47 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26432 for ; Mon, 13 Jan 2003 17:30:23 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0DMXmB20152 for ; Mon, 13 Jan 2003 16:33:49 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 13 Jan 2003 16:33:42 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 13 Jan 2003 14:33:41 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CARD between Routers - will CT do? Date: Mon, 13 Jan 2003 17:33:41 -0500 Message-ID: Thread-Topic: [Seamoby] CARD between Routers - will CT do? Thread-Index: AcK7UI/8PjjTAWn5S4GYa/ZQ+4bAMAAABXLA To: , X-OriginalArrivalTime: 13 Jan 2003 22:33:41.0912 (UTC) FILETIME=[D3287980:01C2BB53] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0DMilJ28900 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hello James, I wouldn't want to tie it up with CT for the following reason. This information may be needed to refreshed at times other than that during handovers, which is when CT happens. Infact, this information is more important prior to the handover process. How does an AR discover any change in the AP configuration? I think this should be stored as soft state and should be refreshed min(when an AR knows of an AP configuration change, lifetime expiration). Also, right now, contexts are MN specific. This is not MN specific context. Let me know if I have misunderstood your comment. Thanks, Govind. -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Monday, January 13, 2003 4:58 PM To: seamoby@ietf.org Subject: [Seamoby] CARD between Routers - will CT do? So most of the discussion here has been about CARD between the Mobile Node and Access Router, and that's OK since it certainly is an important topic. However, equally important is how two Access Routers exchange information about the access points connected to them. This could be statically configured, but that would be very inconvenient. I'm wondering if this might be a good application of CT? The "context" here would be an authenticatable list of access points connected up to a particular router. Comments? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Jan 13 17:49:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27090 for ; Mon, 13 Jan 2003 17:49:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DN3IJ29892; Mon, 13 Jan 2003 18:03:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DN2pJ29830 for ; Mon, 13 Jan 2003 18:02:51 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27065 for ; Mon, 13 Jan 2003 17:48:30 -0500 (EST) Message-ID: <038101c2bb56$21ecbde0$5c6015ac@T23KEMPF> From: "James Kempf" To: , References: Subject: Re: [Seamoby] CARD between Routers - will CT do? Date: Mon, 13 Jan 2003 14:50:12 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Govind, > I wouldn't want to tie it up with CT for the following reason. This information > may be needed to refreshed at times other than that during handovers, which is when CT happens. Infact, this information is more important prior to the handover process. I don't think there are any restraints on CT being coupled to handover signaling. In fact, I believe that one of the requirements is that it can be sent at any time. I recall a very long discussion about this in Pittsburg, I believe. > How does an AR discover any change in the AP configuration? I think this should be stored as soft state and should be refreshed min(when an AR knows > of an AP configuration change, lifetime expiration). > Ideally, the APs would have a protocol built in that would allow them to notify the routers. But of course, we are stuck here because APs are not recognized as a network element within IETF. Only hosts (which are end nodes) and routers are. So we are dependent on other standards organizations to do this. I suppose one could use SNMP for this purpose. I believe IEEE 802.11 defines an SNMP MIB for 802.11 access points. > Also, right now, contexts are MN specific. This is not MN specific context. Let me > know if I have misunderstood your comment. > You are referring to the feature context having within it information about a specific MN? Yes, that is correct, so this would be a difference. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Jan 13 17:50:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27146 for ; Mon, 13 Jan 2003 17:50:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0DN4LZ29958 for seamoby-archive@odin.ietf.org; Mon, 13 Jan 2003 18:04:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DN4LJ29955 for ; Mon, 13 Jan 2003 18:04:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27094 for ; Mon, 13 Jan 2003 17:49:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DN3IJ29892; Mon, 13 Jan 2003 18:03:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DN2pJ29830 for ; Mon, 13 Jan 2003 18:02:51 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27065 for ; Mon, 13 Jan 2003 17:48:30 -0500 (EST) Message-ID: <038101c2bb56$21ecbde0$5c6015ac@T23KEMPF> From: "James Kempf" To: , References: Subject: Re: [Seamoby] CARD between Routers - will CT do? Date: Mon, 13 Jan 2003 14:50:12 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Govind, > I wouldn't want to tie it up with CT for the following reason. This information > may be needed to refreshed at times other than that during handovers, which is when CT happens. Infact, this information is more important prior to the handover process. I don't think there are any restraints on CT being coupled to handover signaling. In fact, I believe that one of the requirements is that it can be sent at any time. I recall a very long discussion about this in Pittsburg, I believe. > How does an AR discover any change in the AP configuration? I think this should be stored as soft state and should be refreshed min(when an AR knows > of an AP configuration change, lifetime expiration). > Ideally, the APs would have a protocol built in that would allow them to notify the routers. But of course, we are stuck here because APs are not recognized as a network element within IETF. Only hosts (which are end nodes) and routers are. So we are dependent on other standards organizations to do this. I suppose one could use SNMP for this purpose. I believe IEEE 802.11 defines an SNMP MIB for 802.11 access points. > Also, right now, contexts are MN specific. This is not MN specific context. Let me > know if I have misunderstood your comment. > You are referring to the feature context having within it information about a specific MN? Yes, that is correct, so this would be a difference. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Jan 13 22:29:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03101 for ; Mon, 13 Jan 2003 22:29:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E3gNJ13753; Mon, 13 Jan 2003 22:42:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E3fEJ13696 for ; Mon, 13 Jan 2003 22:41:14 -0500 Received: from slb-smtpout-01.boeing.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03017 for ; Mon, 13 Jan 2003 22:26:48 -0500 (EST) Received: from stl-av-02.boeing.com ([192.76.190.7]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id TAA13386; Mon, 13 Jan 2003 19:29:59 -0800 (PST) Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-02) with ESMTP id VAA13978; Mon, 13 Jan 2003 21:30:04 -0600 (CST) Received: from xch-nwbh-02.nw.nos.boeing.com (xch-nwbh-02.nw.nos.boeing.com [192.54.12.28]) by slb-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id h0E3U3Q21373; Mon, 13 Jan 2003 19:30:03 -0800 (PST) Received: by xch-nwbh-02.nw.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Mon, 13 Jan 2003 19:30:03 -0800 Message-ID: From: "Paine, Richard H" To: "'James Kempf'" , seamoby@ietf.org Cc: DL WTWG Subject: RE: [Seamoby] CARD between Routers - will CT do? Date: Mon, 13 Jan 2003 19:29:56 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , What might be more important to look at is between layer 2 access points in wireless LANs. IEEE 802.11f has essentially developed the context transfer protocol between access points. It won't be long before those access points include routers in them. In other words, CT does the handoff and then routes across an fixed or an autonomous wireless LAN. Richard H. Paine Success is getting what you want, happiness is liking what you get! IPPhone: 206.766.5808 Phone: 425.865.4921 Cellular: 206.854.8199 Pager: 206.797.4580 Email: richard.h.paine@boeing.com -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Monday, January 13, 2003 1:58 PM To: seamoby@ietf.org Subject: [Seamoby] CARD between Routers - will CT do? So most of the discussion here has been about CARD between the Mobile Node and Access Router, and that's OK since it certainly is an important topic. However, equally important is how two Access Routers exchange information about the access points connected to them. This could be statically configured, but that would be very inconvenient. I'm wondering if this might be a good application of CT? The "context" here would be an authenticatable list of access points connected up to a particular router. Comments? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Jan 13 22:29:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03133 for ; Mon, 13 Jan 2003 22:29:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0E3hca13817 for seamoby-archive@odin.ietf.org; Mon, 13 Jan 2003 22:43:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E3hcJ13814 for ; Mon, 13 Jan 2003 22:43:38 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03104 for ; Mon, 13 Jan 2003 22:29:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E3gNJ13753; Mon, 13 Jan 2003 22:42:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E3fEJ13696 for ; Mon, 13 Jan 2003 22:41:14 -0500 Received: from slb-smtpout-01.boeing.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03017 for ; Mon, 13 Jan 2003 22:26:48 -0500 (EST) Received: from stl-av-02.boeing.com ([192.76.190.7]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id TAA13386; Mon, 13 Jan 2003 19:29:59 -0800 (PST) Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-02) with ESMTP id VAA13978; Mon, 13 Jan 2003 21:30:04 -0600 (CST) Received: from xch-nwbh-02.nw.nos.boeing.com (xch-nwbh-02.nw.nos.boeing.com [192.54.12.28]) by slb-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id h0E3U3Q21373; Mon, 13 Jan 2003 19:30:03 -0800 (PST) Received: by xch-nwbh-02.nw.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Mon, 13 Jan 2003 19:30:03 -0800 Message-ID: From: "Paine, Richard H" To: "'James Kempf'" , seamoby@ietf.org Cc: DL WTWG Subject: RE: [Seamoby] CARD between Routers - will CT do? Date: Mon, 13 Jan 2003 19:29:56 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , What might be more important to look at is between layer 2 access points in wireless LANs. IEEE 802.11f has essentially developed the context transfer protocol between access points. It won't be long before those access points include routers in them. In other words, CT does the handoff and then routes across an fixed or an autonomous wireless LAN. Richard H. Paine Success is getting what you want, happiness is liking what you get! IPPhone: 206.766.5808 Phone: 425.865.4921 Cellular: 206.854.8199 Pager: 206.797.4580 Email: richard.h.paine@boeing.com -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Monday, January 13, 2003 1:58 PM To: seamoby@ietf.org Subject: [Seamoby] CARD between Routers - will CT do? So most of the discussion here has been about CARD between the Mobile Node and Access Router, and that's OK since it certainly is an important topic. However, equally important is how two Access Routers exchange information about the access points connected to them. This could be statically configured, but that would be very inconvenient. I'm wondering if this might be a good application of CT? The "context" here would be an authenticatable list of access points connected up to a particular router. Comments? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Jan 14 05:57:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20946 for ; Tue, 14 Jan 2003 05:57:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EBAZJ19830; Tue, 14 Jan 2003 06:10:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EB9iJ19781 for ; Tue, 14 Jan 2003 06:09:44 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20916 for ; Tue, 14 Jan 2003 05:55:08 -0500 (EST) Received: from eunsoo ([138.15.107.234]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 14 Jan 2003 05:58:29 -0500 Message-ID: <027401c2bbd5$59db2f00$ea6b0f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , References: <035101c2bb4e$d6883890$5c6015ac@T23KEMPF> Subject: Re: [Seamoby] CARD between Routers - will CT do? Date: Tue, 14 Jan 2003 06:00:52 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 14 Jan 2003 10:58:29.0109 (UTC) FILETIME=[DECD9A50:01C2BBBB] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, James, There should be two types of messages between ARs for CARD. - Discovery process related - Attributes (including information about access points) related And there can be two modes of attribute information exchange. - One time request-response - Periodic updates (one time request and follow-up periodic responses) I have two questions about your suggestion. 1) You are suggesting using CT for attribute information exchanges but not the discovery related signaling, aren't you? 2) Will CT support the above modes of attribute information exchange? My feeling is that we'd better identify the type of messages for CARD first and then can think about reusing any other protocol for the messages. And I think we need more discussion or output from the design team regarding the message types. Thanks. Eunsoo ----- Original Message ----- From: "James Kempf" To: Sent: Monday, January 13, 2003 1:58 PM Subject: [Seamoby] CARD between Routers - will CT do? > So most of the discussion here has been about CARD between the Mobile Node and > Access Router, and that's OK since it certainly is an important topic. > > However, equally important is how two Access Routers exchange information about > the access points connected to them. This could be statically configured, but > that would be very inconvenient. > > I'm wondering if this might be a good application of CT? The "context" here > would be an authenticatable list of access points connected up to a particular > router. > > Comments? > > jak > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Jan 14 05:57:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20975 for ; Tue, 14 Jan 2003 05:57:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0EBBc919898 for seamoby-archive@odin.ietf.org; Tue, 14 Jan 2003 06:11:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EBBcJ19895 for ; Tue, 14 Jan 2003 06:11:38 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20949 for ; Tue, 14 Jan 2003 05:57:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EBAZJ19830; Tue, 14 Jan 2003 06:10:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EB9iJ19781 for ; Tue, 14 Jan 2003 06:09:44 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20916 for ; Tue, 14 Jan 2003 05:55:08 -0500 (EST) Received: from eunsoo ([138.15.107.234]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 14 Jan 2003 05:58:29 -0500 Message-ID: <027401c2bbd5$59db2f00$ea6b0f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , References: <035101c2bb4e$d6883890$5c6015ac@T23KEMPF> Subject: Re: [Seamoby] CARD between Routers - will CT do? Date: Tue, 14 Jan 2003 06:00:52 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 14 Jan 2003 10:58:29.0109 (UTC) FILETIME=[DECD9A50:01C2BBBB] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, James, There should be two types of messages between ARs for CARD. - Discovery process related - Attributes (including information about access points) related And there can be two modes of attribute information exchange. - One time request-response - Periodic updates (one time request and follow-up periodic responses) I have two questions about your suggestion. 1) You are suggesting using CT for attribute information exchanges but not the discovery related signaling, aren't you? 2) Will CT support the above modes of attribute information exchange? My feeling is that we'd better identify the type of messages for CARD first and then can think about reusing any other protocol for the messages. And I think we need more discussion or output from the design team regarding the message types. Thanks. Eunsoo ----- Original Message ----- From: "James Kempf" To: Sent: Monday, January 13, 2003 1:58 PM Subject: [Seamoby] CARD between Routers - will CT do? > So most of the discussion here has been about CARD between the Mobile Node and > Access Router, and that's OK since it certainly is an important topic. > > However, equally important is how two Access Routers exchange information about > the access points connected to them. This could be statically configured, but > that would be very inconvenient. > > I'm wondering if this might be a good application of CT? The "context" here > would be an authenticatable list of access points connected up to a particular > router. > > Comments? > > jak > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Jan 14 09:53:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25798 for ; Tue, 14 Jan 2003 09:53:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EF6XJ01974; Tue, 14 Jan 2003 10:06:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EF5VJ01911 for ; Tue, 14 Jan 2003 10:05:31 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25705 for ; Tue, 14 Jan 2003 09:50:45 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0EErkB29654 for ; Tue, 14 Jan 2003 08:53:56 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 14 Jan 2003 08:53:39 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 14 Jan 2003 06:52:54 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CARD between Routers - will CT do? Date: Tue, 14 Jan 2003 09:52:53 -0500 Message-ID: Thread-Topic: [Seamoby] CARD between Routers - will CT do? Thread-Index: AcK7VniAvT+qB+zDScetQw2pA5fmnQAhXWQw To: , , X-OriginalArrivalTime: 14 Jan 2003 14:52:54.0350 (UTC) FILETIME=[9E570EE0:01C2BBDC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0EF5VJ01912 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi James, CAR will exchange information related to AR, such as AP information, capabilities (of APs but also of the AR), but it might even exchange discovery related infos. Any block exchange protocol will do as the "bearer" of the information. The actual bearer definition is not the key of CT, from my point. It is the application of this kind of exchange and its necessary triggers. The current work is currently focussing on handover and transfer of MN context. Hence, we have two differentiating factors, i.e., non-handover usage of CT (which is certainly possible and even to be supported, as you said) and AR-related information exchange. Again, in the context of CAR, it is the application logic (when do we send what) that matters. Re-using the plain "bearer" protocol, i.e., a protocol that transfers my block of bits from one AR to another, is not the big deal then. Regards, Dirk >-----Original Message----- >From: ext James Kempf [mailto:kempf@docomolabs-usa.com] >Sent: Monday, January 13, 2003 5:50 PM >To: Krishnamurthi Govind (NRC/Boston); seamoby@ietf.org >Subject: Re: [Seamoby] CARD between Routers - will CT do? > > >Hi Govind, > >> I wouldn't want to tie it up with CT for the following reason. This >information >> may be needed to refreshed at times other than that during >handovers, which >is when CT happens. Infact, this information is more important >prior to the >handover process. > >I don't think there are any restraints on CT being coupled to handover >signaling. In fact, I believe that one of the requirements is >that it can be >sent at any time. I recall a very long discussion about this >in Pittsburg, I >believe. > >> How does an AR discover any change in the AP configuration? >I think this >should be stored as soft state and should be refreshed >min(when an AR knows >> of an AP configuration change, lifetime expiration). >> > >Ideally, the APs would have a protocol built in that would >allow them to notify >the routers. But of course, we are stuck here because APs are >not recognized as >a network element within IETF. Only hosts (which are end >nodes) and routers are. >So we are dependent on other standards organizations to do this. > >I suppose one could use SNMP for this purpose. I believe IEEE >802.11 defines an >SNMP MIB for 802.11 access points. > >> Also, right now, contexts are MN specific. This is not MN >specific context. >Let me >> know if I have misunderstood your comment. >> > >You are referring to the feature context having within it >information about a >specific MN? Yes, that is correct, so this would be a difference. > > jak > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Jan 14 09:53:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25820 for ; Tue, 14 Jan 2003 09:53:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0EF7va02682 for seamoby-archive@odin.ietf.org; Tue, 14 Jan 2003 10:07:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EF7uJ02679 for ; Tue, 14 Jan 2003 10:07:56 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25801 for ; Tue, 14 Jan 2003 09:53:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EF6XJ01974; Tue, 14 Jan 2003 10:06:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EF5VJ01911 for ; Tue, 14 Jan 2003 10:05:31 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25705 for ; Tue, 14 Jan 2003 09:50:45 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0EErkB29654 for ; Tue, 14 Jan 2003 08:53:56 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 14 Jan 2003 08:53:39 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 14 Jan 2003 06:52:54 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CARD between Routers - will CT do? Date: Tue, 14 Jan 2003 09:52:53 -0500 Message-ID: Thread-Topic: [Seamoby] CARD between Routers - will CT do? Thread-Index: AcK7VniAvT+qB+zDScetQw2pA5fmnQAhXWQw To: , , X-OriginalArrivalTime: 14 Jan 2003 14:52:54.0350 (UTC) FILETIME=[9E570EE0:01C2BBDC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0EF5VJ01912 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi James, CAR will exchange information related to AR, such as AP information, capabilities (of APs but also of the AR), but it might even exchange discovery related infos. Any block exchange protocol will do as the "bearer" of the information. The actual bearer definition is not the key of CT, from my point. It is the application of this kind of exchange and its necessary triggers. The current work is currently focussing on handover and transfer of MN context. Hence, we have two differentiating factors, i.e., non-handover usage of CT (which is certainly possible and even to be supported, as you said) and AR-related information exchange. Again, in the context of CAR, it is the application logic (when do we send what) that matters. Re-using the plain "bearer" protocol, i.e., a protocol that transfers my block of bits from one AR to another, is not the big deal then. Regards, Dirk >-----Original Message----- >From: ext James Kempf [mailto:kempf@docomolabs-usa.com] >Sent: Monday, January 13, 2003 5:50 PM >To: Krishnamurthi Govind (NRC/Boston); seamoby@ietf.org >Subject: Re: [Seamoby] CARD between Routers - will CT do? > > >Hi Govind, > >> I wouldn't want to tie it up with CT for the following reason. This >information >> may be needed to refreshed at times other than that during >handovers, which >is when CT happens. Infact, this information is more important >prior to the >handover process. > >I don't think there are any restraints on CT being coupled to handover >signaling. In fact, I believe that one of the requirements is >that it can be >sent at any time. I recall a very long discussion about this >in Pittsburg, I >believe. > >> How does an AR discover any change in the AP configuration? >I think this >should be stored as soft state and should be refreshed >min(when an AR knows >> of an AP configuration change, lifetime expiration). >> > >Ideally, the APs would have a protocol built in that would >allow them to notify >the routers. But of course, we are stuck here because APs are >not recognized as >a network element within IETF. Only hosts (which are end >nodes) and routers are. >So we are dependent on other standards organizations to do this. > >I suppose one could use SNMP for this purpose. I believe IEEE >802.11 defines an >SNMP MIB for 802.11 access points. > >> Also, right now, contexts are MN specific. This is not MN >specific context. >Let me >> know if I have misunderstood your comment. >> > >You are referring to the feature context having within it >information about a >specific MN? Yes, that is correct, so this would be a difference. > > jak > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Jan 14 11:06:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29956 for ; Tue, 14 Jan 2003 11:06:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EGKBJ08427; Tue, 14 Jan 2003 11:20:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EGJmJ08366 for ; Tue, 14 Jan 2003 11:19:48 -0500 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29875 for ; Tue, 14 Jan 2003 11:05:06 -0500 (EST) Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id h0EG8LR83142; Tue, 14 Jan 2003 17:08:22 +0100 (CET) (envelope-from Marco.Liebsch@ccrle.nec.de) Received: from ccrle.nec.de (liebsch.office [10.1.1.153]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 0D9BB28A97; Tue, 14 Jan 2003 18:16:49 +0100 (CET) Message-ID: <3E243589.9020904@ccrle.nec.de> Date: Tue, 14 Jan 2003 17:06:33 +0100 From: Marco Liebsch Organization: NEC Europe Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf Cc: seamoby@ietf.org Subject: Re: [Seamoby] CARD between Routers - will CT do? References: <035101c2bb4e$d6883890$5c6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi James, I agree that info exchange between ARs is a big issue to be resolved. But I am not sure about CT to be the right way to go for and would rather de-couple CARD from the actual CT procedure, which is, in my opinion, currently related to mobile terminal context. So, we would run into similar discussion with CT as we are doing now for Fast MIPv6 when trying to extend CT with CARD attributes, isnt't it? Another issue I see is timing. Now, not all info (address resolution and caps exchange) is to be done necessarily at the same time, in particular not necessarily when CT is performed. Further, it's not clear to me how learning of dynamic capabilities should be handled, which could be a parameter handover decision might depend on? marco James Kempf wrote: >So most of the discussion here has been about CARD between the Mobile Node and >Access Router, and that's OK since it certainly is an important topic. > >However, equally important is how two Access Routers exchange information about >the access points connected to them. This could be statically configured, but >that would be very inconvenient. > >I'm wondering if this might be a good application of CT? The "context" here >would be an authenticatable list of access points connected up to a particular >router. > >Comments? > > jak > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Jan 14 11:07:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29986 for ; Tue, 14 Jan 2003 11:07:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0EGLfu08567 for seamoby-archive@odin.ietf.org; Tue, 14 Jan 2003 11:21:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EGLfJ08564 for ; Tue, 14 Jan 2003 11:21:41 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29959 for ; Tue, 14 Jan 2003 11:06:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EGKBJ08427; Tue, 14 Jan 2003 11:20:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EGJmJ08366 for ; Tue, 14 Jan 2003 11:19:48 -0500 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29875 for ; Tue, 14 Jan 2003 11:05:06 -0500 (EST) Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id h0EG8LR83142; Tue, 14 Jan 2003 17:08:22 +0100 (CET) (envelope-from Marco.Liebsch@ccrle.nec.de) Received: from ccrle.nec.de (liebsch.office [10.1.1.153]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 0D9BB28A97; Tue, 14 Jan 2003 18:16:49 +0100 (CET) Message-ID: <3E243589.9020904@ccrle.nec.de> Date: Tue, 14 Jan 2003 17:06:33 +0100 From: Marco Liebsch Organization: NEC Europe Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf Cc: seamoby@ietf.org Subject: Re: [Seamoby] CARD between Routers - will CT do? References: <035101c2bb4e$d6883890$5c6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi James, I agree that info exchange between ARs is a big issue to be resolved. But I am not sure about CT to be the right way to go for and would rather de-couple CARD from the actual CT procedure, which is, in my opinion, currently related to mobile terminal context. So, we would run into similar discussion with CT as we are doing now for Fast MIPv6 when trying to extend CT with CARD attributes, isnt't it? Another issue I see is timing. Now, not all info (address resolution and caps exchange) is to be done necessarily at the same time, in particular not necessarily when CT is performed. Further, it's not clear to me how learning of dynamic capabilities should be handled, which could be a parameter handover decision might depend on? marco James Kempf wrote: >So most of the discussion here has been about CARD between the Mobile Node and >Access Router, and that's OK since it certainly is an important topic. > >However, equally important is how two Access Routers exchange information about >the access points connected to them. This could be statically configured, but >that would be very inconvenient. > >I'm wondering if this might be a good application of CT? The "context" here >would be an authenticatable list of access points connected up to a particular >router. > >Comments? > > jak > > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Jan 14 11:39:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02488 for ; Tue, 14 Jan 2003 11:39:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EGrEJ11887; Tue, 14 Jan 2003 11:53:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EGqHJ11807 for ; Tue, 14 Jan 2003 11:52:17 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02394 for ; Tue, 14 Jan 2003 11:37:33 -0500 (EST) Message-ID: <003f01c2bbeb$7b3e8a00$956015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , References: <035101c2bb4e$d6883890$5c6015ac@T23KEMPF> <027401c2bbd5$59db2f00$ea6b0f8a@eunsoo> Subject: Re: [Seamoby] CARD between Routers - will CT do? Date: Tue, 14 Jan 2003 08:39:15 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Eunsoo, There is no need for discovery related messages between ARs. Routers know where they are, the routing protocol tells them. There is, of course, an issue of the AR finding APs attached to it, but that is a different question. That would probably benefit by some protocol, but, of course, we have this problem about APs being invisible as far as IP is concerned. The idea of using CT for CARD between routers came out of some discussions we've been having here about how best to implement these protocols. Having a generic framework within which all the inter-AR signaling can fit could make the implementation cleaner. For example, one could view the HI/HAck signaling of FMIP as another instance of CT. One could imagine extending the routing protocol to do implement the framework, but having a separate protocol might be better. Anyway, maybe this is boiling the ocean. We are already having enough trouble getting the specs done on CT and CARD for MNs. Maybe we ought to finish that first, then revisit the issue when we have more experience with implementing these protocols. jak ----- Original Message ----- From: "Eunsoo Shim" To: "James Kempf" ; Sent: Tuesday, January 14, 2003 6:00 AM Subject: Re: [Seamoby] CARD between Routers - will CT do? > Hi, James, > > There should be two types of messages between ARs for CARD. > - Discovery process related > - Attributes (including information about access points) related > > And there can be two modes of attribute information exchange. > - One time request-response > - Periodic updates (one time request and follow-up periodic responses) > > I have two questions about your suggestion. > 1) You are suggesting using CT for attribute information exchanges but not > the discovery related signaling, aren't you? > 2) Will CT support the above modes of attribute information exchange? > > My feeling is that we'd better identify the type of messages for CARD first > and then can think about reusing any other protocol for the messages. And I > think we need more discussion or output from the design team regarding the > message types. > Thanks. > > Eunsoo > > ----- Original Message ----- > From: "James Kempf" > To: > Sent: Monday, January 13, 2003 1:58 PM > Subject: [Seamoby] CARD between Routers - will CT do? > > > > So most of the discussion here has been about CARD between the Mobile Node > and > > Access Router, and that's OK since it certainly is an important topic. > > > > However, equally important is how two Access Routers exchange information > about > > the access points connected to them. This could be statically configured, > but > > that would be very inconvenient. > > > > I'm wondering if this might be a good application of CT? The "context" > here > > would be an authenticatable list of access points connected up to a > particular > > router. > > > > Comments? > > > > jak > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Jan 14 11:40:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02509 for ; Tue, 14 Jan 2003 11:40:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0EGsVd11967 for seamoby-archive@odin.ietf.org; Tue, 14 Jan 2003 11:54:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EGsUJ11964 for ; Tue, 14 Jan 2003 11:54:30 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02491 for ; Tue, 14 Jan 2003 11:39:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EGrEJ11887; Tue, 14 Jan 2003 11:53:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EGqHJ11807 for ; Tue, 14 Jan 2003 11:52:17 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02394 for ; Tue, 14 Jan 2003 11:37:33 -0500 (EST) Message-ID: <003f01c2bbeb$7b3e8a00$956015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , References: <035101c2bb4e$d6883890$5c6015ac@T23KEMPF> <027401c2bbd5$59db2f00$ea6b0f8a@eunsoo> Subject: Re: [Seamoby] CARD between Routers - will CT do? Date: Tue, 14 Jan 2003 08:39:15 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Eunsoo, There is no need for discovery related messages between ARs. Routers know where they are, the routing protocol tells them. There is, of course, an issue of the AR finding APs attached to it, but that is a different question. That would probably benefit by some protocol, but, of course, we have this problem about APs being invisible as far as IP is concerned. The idea of using CT for CARD between routers came out of some discussions we've been having here about how best to implement these protocols. Having a generic framework within which all the inter-AR signaling can fit could make the implementation cleaner. For example, one could view the HI/HAck signaling of FMIP as another instance of CT. One could imagine extending the routing protocol to do implement the framework, but having a separate protocol might be better. Anyway, maybe this is boiling the ocean. We are already having enough trouble getting the specs done on CT and CARD for MNs. Maybe we ought to finish that first, then revisit the issue when we have more experience with implementing these protocols. jak ----- Original Message ----- From: "Eunsoo Shim" To: "James Kempf" ; Sent: Tuesday, January 14, 2003 6:00 AM Subject: Re: [Seamoby] CARD between Routers - will CT do? > Hi, James, > > There should be two types of messages between ARs for CARD. > - Discovery process related > - Attributes (including information about access points) related > > And there can be two modes of attribute information exchange. > - One time request-response > - Periodic updates (one time request and follow-up periodic responses) > > I have two questions about your suggestion. > 1) You are suggesting using CT for attribute information exchanges but not > the discovery related signaling, aren't you? > 2) Will CT support the above modes of attribute information exchange? > > My feeling is that we'd better identify the type of messages for CARD first > and then can think about reusing any other protocol for the messages. And I > think we need more discussion or output from the design team regarding the > message types. > Thanks. > > Eunsoo > > ----- Original Message ----- > From: "James Kempf" > To: > Sent: Monday, January 13, 2003 1:58 PM > Subject: [Seamoby] CARD between Routers - will CT do? > > > > So most of the discussion here has been about CARD between the Mobile Node > and > > Access Router, and that's OK since it certainly is an important topic. > > > > However, equally important is how two Access Routers exchange information > about > > the access points connected to them. This could be statically configured, > but > > that would be very inconvenient. > > > > I'm wondering if this might be a good application of CT? The "context" > here > > would be an authenticatable list of access points connected up to a > particular > > router. > > > > Comments? > > > > jak > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Jan 14 12:42:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04349 for ; Tue, 14 Jan 2003 12:42:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EHuGJ16422; Tue, 14 Jan 2003 12:56:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EHt1J16351 for ; Tue, 14 Jan 2003 12:55:01 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04302 for ; Tue, 14 Jan 2003 12:40:16 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0EHjit24996 for ; Tue, 14 Jan 2003 19:45:44 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 14 Jan 2003 19:43:35 +0200 Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 14 Jan 2003 19:43:35 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 14 Jan 2003 09:43:33 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CARD between Routers - will CT do? Date: Tue, 14 Jan 2003 12:43:31 -0500 Message-ID: Thread-Topic: [Seamoby] CARD between Routers - will CT do? Thread-Index: AcK77DpAjnPm4ictRe6ZAufBR30D3AAB5TvQ To: , , X-OriginalArrivalTime: 14 Jan 2003 17:43:33.0025 (UTC) FILETIME=[7510E110:01C2BBF4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0EHt1J16357 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi James: One comment below: -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Tuesday, January 14, 2003 11:39 AM To: Eunsoo Shim; seamoby@ietf.org Subject: Re: [Seamoby] CARD between Routers - will CT do? Eunsoo, There is no need for discovery related messages between ARs. Routers know where they are, the routing protocol tells them. [Hemant] Routing protocol does not tell physical neighborhood. It tells logical neighborhood. So a router one hop away from me could actually be far away physically and no candidate for handoff. Turning it around, routers physically next to each other can be in different BGP domains and BGP aggregated (or otherwise) exchanges do not have this information. So, I think discovery related message are very much required and issues draft has emphasized it. How you do it is open for discussion though. There is, of course, an issue of the AR finding APs attached to it, but that is a different question. That would probably benefit by some protocol, but, of course, we have this problem about APs being invisible as far as IP is concerned. [Hemant] Agreed, I think we can delegate this task to link layer standardization bodies. The idea of using CT for CARD between routers came out of some discussions we've been having here about how best to implement these protocols. Having a generic framework within which all the inter-AR signaling can fit could make the implementation cleaner. For example, one could view the HI/HAck signaling of FMIP as another instance of CT. One could imagine extending the routing protocol to do implement the framework, but having a separate protocol might be better. Anyway, maybe this is boiling the ocean. We are already having enough trouble getting the specs done on CT and CARD for MNs. Maybe we ought to finish that first, then revisit the issue when we have more experience with implementing these protocols. jak ----- Original Message ----- From: "Eunsoo Shim" To: "James Kempf" ; Sent: Tuesday, January 14, 2003 6:00 AM Subject: Re: [Seamoby] CARD between Routers - will CT do? > Hi, James, > > There should be two types of messages between ARs for CARD. > - Discovery process related > - Attributes (including information about access points) related > > And there can be two modes of attribute information exchange. > - One time request-response > - Periodic updates (one time request and follow-up periodic responses) > > I have two questions about your suggestion. > 1) You are suggesting using CT for attribute information exchanges but not > the discovery related signaling, aren't you? > 2) Will CT support the above modes of attribute information exchange? > > My feeling is that we'd better identify the type of messages for CARD first > and then can think about reusing any other protocol for the messages. And I > think we need more discussion or output from the design team regarding the > message types. > Thanks. > > Eunsoo > > ----- Original Message ----- > From: "James Kempf" > To: > Sent: Monday, January 13, 2003 1:58 PM > Subject: [Seamoby] CARD between Routers - will CT do? > > > > So most of the discussion here has been about CARD between the Mobile Node > and > > Access Router, and that's OK since it certainly is an important topic. > > > > However, equally important is how two Access Routers exchange information > about > > the access points connected to them. This could be statically configured, > but > > that would be very inconvenient. > > > > I'm wondering if this might be a good application of CT? The "context" > here > > would be an authenticatable list of access points connected up to a > particular > > router. > > > > Comments? > > > > jak > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Jan 14 12:43:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04407 for ; Tue, 14 Jan 2003 12:43:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0EHvIN16468 for seamoby-archive@odin.ietf.org; Tue, 14 Jan 2003 12:57:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EHvIJ16465 for ; Tue, 14 Jan 2003 12:57:18 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04363 for ; Tue, 14 Jan 2003 12:42:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EHuGJ16422; Tue, 14 Jan 2003 12:56:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EHt1J16351 for ; Tue, 14 Jan 2003 12:55:01 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04302 for ; Tue, 14 Jan 2003 12:40:16 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0EHjit24996 for ; Tue, 14 Jan 2003 19:45:44 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 14 Jan 2003 19:43:35 +0200 Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 14 Jan 2003 19:43:35 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 14 Jan 2003 09:43:33 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CARD between Routers - will CT do? Date: Tue, 14 Jan 2003 12:43:31 -0500 Message-ID: Thread-Topic: [Seamoby] CARD between Routers - will CT do? Thread-Index: AcK77DpAjnPm4ictRe6ZAufBR30D3AAB5TvQ To: , , X-OriginalArrivalTime: 14 Jan 2003 17:43:33.0025 (UTC) FILETIME=[7510E110:01C2BBF4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0EHt1J16357 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi James: One comment below: -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Tuesday, January 14, 2003 11:39 AM To: Eunsoo Shim; seamoby@ietf.org Subject: Re: [Seamoby] CARD between Routers - will CT do? Eunsoo, There is no need for discovery related messages between ARs. Routers know where they are, the routing protocol tells them. [Hemant] Routing protocol does not tell physical neighborhood. It tells logical neighborhood. So a router one hop away from me could actually be far away physically and no candidate for handoff. Turning it around, routers physically next to each other can be in different BGP domains and BGP aggregated (or otherwise) exchanges do not have this information. So, I think discovery related message are very much required and issues draft has emphasized it. How you do it is open for discussion though. There is, of course, an issue of the AR finding APs attached to it, but that is a different question. That would probably benefit by some protocol, but, of course, we have this problem about APs being invisible as far as IP is concerned. [Hemant] Agreed, I think we can delegate this task to link layer standardization bodies. The idea of using CT for CARD between routers came out of some discussions we've been having here about how best to implement these protocols. Having a generic framework within which all the inter-AR signaling can fit could make the implementation cleaner. For example, one could view the HI/HAck signaling of FMIP as another instance of CT. One could imagine extending the routing protocol to do implement the framework, but having a separate protocol might be better. Anyway, maybe this is boiling the ocean. We are already having enough trouble getting the specs done on CT and CARD for MNs. Maybe we ought to finish that first, then revisit the issue when we have more experience with implementing these protocols. jak ----- Original Message ----- From: "Eunsoo Shim" To: "James Kempf" ; Sent: Tuesday, January 14, 2003 6:00 AM Subject: Re: [Seamoby] CARD between Routers - will CT do? > Hi, James, > > There should be two types of messages between ARs for CARD. > - Discovery process related > - Attributes (including information about access points) related > > And there can be two modes of attribute information exchange. > - One time request-response > - Periodic updates (one time request and follow-up periodic responses) > > I have two questions about your suggestion. > 1) You are suggesting using CT for attribute information exchanges but not > the discovery related signaling, aren't you? > 2) Will CT support the above modes of attribute information exchange? > > My feeling is that we'd better identify the type of messages for CARD first > and then can think about reusing any other protocol for the messages. And I > think we need more discussion or output from the design team regarding the > message types. > Thanks. > > Eunsoo > > ----- Original Message ----- > From: "James Kempf" > To: > Sent: Monday, January 13, 2003 1:58 PM > Subject: [Seamoby] CARD between Routers - will CT do? > > > > So most of the discussion here has been about CARD between the Mobile Node > and > > Access Router, and that's OK since it certainly is an important topic. > > > > However, equally important is how two Access Routers exchange information > about > > the access points connected to them. This could be statically configured, > but > > that would be very inconvenient. > > > > I'm wondering if this might be a good application of CT? The "context" > here > > would be an authenticatable list of access points connected up to a > particular > > router. > > > > Comments? > > > > jak > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Jan 14 14:27:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08499 for ; Tue, 14 Jan 2003 14:27:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EJfGJ25165; Tue, 14 Jan 2003 14:41:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EJeDJ25098 for ; Tue, 14 Jan 2003 14:40:13 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08358 for ; Tue, 14 Jan 2003 14:25:26 -0500 (EST) Received: from eunsoo ([138.15.107.234]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 14 Jan 2003 14:28:47 -0500 Message-ID: <005f01c2bc1c$a2cec040$ea6b0f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , References: <035101c2bb4e$d6883890$5c6015ac@T23KEMPF> <027401c2bbd5$59db2f00$ea6b0f8a@eunsoo> <003f01c2bbeb$7b3e8a00$956015ac@T23KEMPF> Subject: Re: [Seamoby] CARD between Routers - will CT do? Date: Tue, 14 Jan 2003 14:31:09 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 14 Jan 2003 19:28:47.0502 (UTC) FILETIME=[28C99AE0:01C2BC03] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, James, The need to transport discovery related information is an important piece for CARD as Hermant pointed out. So let me skip about it. I understand your motivation. It seems to me also that there are many protocols with some overlapping regarding mobility management. It would be nice to clean up them and end up with a less number of protocols in the end. Such thought also came to me in the past but it seems to me that we might have to go a longer way to reach such protocol sets. I hope it is possible to do it later. Regards. Eunsoo ----- Original Message ----- From: "James Kempf" To: "Eunsoo Shim" ; Sent: Tuesday, January 14, 2003 8:39 AM Subject: Re: [Seamoby] CARD between Routers - will CT do? > Eunsoo, > > There is no need for discovery related messages between ARs. Routers know where > they are, the routing protocol tells them. There is, of course, an issue of the > AR finding APs attached to it, but that is a different question. That would > probably benefit by some protocol, but, of course, we have this problem about > APs being invisible as far as IP is concerned. > > The idea of using CT for CARD between routers came out of some discussions we've > been having here about how best to implement these protocols. Having a generic > framework within which all the inter-AR signaling can fit could make the > implementation cleaner. For example, one could view the HI/HAck signaling of > FMIP as another instance of CT. One could imagine extending the routing > protocol to do implement the framework, but having a separate protocol might be > better. > > Anyway, maybe this is boiling the ocean. We are already having enough trouble > getting the specs done on CT and CARD for MNs. Maybe we ought to finish that > first, then revisit the issue when we have more experience with implementing > these protocols. > > jak > > ----- Original Message ----- > From: "Eunsoo Shim" > To: "James Kempf" ; > Sent: Tuesday, January 14, 2003 6:00 AM > Subject: Re: [Seamoby] CARD between Routers - will CT do? > > > > Hi, James, > > > > There should be two types of messages between ARs for CARD. > > - Discovery process related > > - Attributes (including information about access points) related > > > > And there can be two modes of attribute information exchange. > > - One time request-response > > - Periodic updates (one time request and follow-up periodic responses) > > > > I have two questions about your suggestion. > > 1) You are suggesting using CT for attribute information exchanges but not > > the discovery related signaling, aren't you? > > 2) Will CT support the above modes of attribute information exchange? > > > > My feeling is that we'd better identify the type of messages for CARD first > > and then can think about reusing any other protocol for the messages. And I > > think we need more discussion or output from the design team regarding the > > message types. > > Thanks. > > > > Eunsoo > > > > ----- Original Message ----- > > From: "James Kempf" > > To: > > Sent: Monday, January 13, 2003 1:58 PM > > Subject: [Seamoby] CARD between Routers - will CT do? > > > > > > > So most of the discussion here has been about CARD between the Mobile Node > > and > > > Access Router, and that's OK since it certainly is an important topic. > > > > > > However, equally important is how two Access Routers exchange information > > about > > > the access points connected to them. This could be statically configured, > > but > > > that would be very inconvenient. > > > > > > I'm wondering if this might be a good application of CT? The "context" > > here > > > would be an authenticatable list of access points connected up to a > > particular > > > router. > > > > > > Comments? > > > > > > jak > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Jan 14 14:28:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08532 for ; Tue, 14 Jan 2003 14:28:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0EJgln25254 for seamoby-archive@odin.ietf.org; Tue, 14 Jan 2003 14:42:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EJglJ25251 for ; Tue, 14 Jan 2003 14:42:47 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08509 for ; Tue, 14 Jan 2003 14:27:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EJfGJ25165; Tue, 14 Jan 2003 14:41:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EJeDJ25098 for ; Tue, 14 Jan 2003 14:40:13 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08358 for ; Tue, 14 Jan 2003 14:25:26 -0500 (EST) Received: from eunsoo ([138.15.107.234]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 14 Jan 2003 14:28:47 -0500 Message-ID: <005f01c2bc1c$a2cec040$ea6b0f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , References: <035101c2bb4e$d6883890$5c6015ac@T23KEMPF> <027401c2bbd5$59db2f00$ea6b0f8a@eunsoo> <003f01c2bbeb$7b3e8a00$956015ac@T23KEMPF> Subject: Re: [Seamoby] CARD between Routers - will CT do? Date: Tue, 14 Jan 2003 14:31:09 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 14 Jan 2003 19:28:47.0502 (UTC) FILETIME=[28C99AE0:01C2BC03] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, James, The need to transport discovery related information is an important piece for CARD as Hermant pointed out. So let me skip about it. I understand your motivation. It seems to me also that there are many protocols with some overlapping regarding mobility management. It would be nice to clean up them and end up with a less number of protocols in the end. Such thought also came to me in the past but it seems to me that we might have to go a longer way to reach such protocol sets. I hope it is possible to do it later. Regards. Eunsoo ----- Original Message ----- From: "James Kempf" To: "Eunsoo Shim" ; Sent: Tuesday, January 14, 2003 8:39 AM Subject: Re: [Seamoby] CARD between Routers - will CT do? > Eunsoo, > > There is no need for discovery related messages between ARs. Routers know where > they are, the routing protocol tells them. There is, of course, an issue of the > AR finding APs attached to it, but that is a different question. That would > probably benefit by some protocol, but, of course, we have this problem about > APs being invisible as far as IP is concerned. > > The idea of using CT for CARD between routers came out of some discussions we've > been having here about how best to implement these protocols. Having a generic > framework within which all the inter-AR signaling can fit could make the > implementation cleaner. For example, one could view the HI/HAck signaling of > FMIP as another instance of CT. One could imagine extending the routing > protocol to do implement the framework, but having a separate protocol might be > better. > > Anyway, maybe this is boiling the ocean. We are already having enough trouble > getting the specs done on CT and CARD for MNs. Maybe we ought to finish that > first, then revisit the issue when we have more experience with implementing > these protocols. > > jak > > ----- Original Message ----- > From: "Eunsoo Shim" > To: "James Kempf" ; > Sent: Tuesday, January 14, 2003 6:00 AM > Subject: Re: [Seamoby] CARD between Routers - will CT do? > > > > Hi, James, > > > > There should be two types of messages between ARs for CARD. > > - Discovery process related > > - Attributes (including information about access points) related > > > > And there can be two modes of attribute information exchange. > > - One time request-response > > - Periodic updates (one time request and follow-up periodic responses) > > > > I have two questions about your suggestion. > > 1) You are suggesting using CT for attribute information exchanges but not > > the discovery related signaling, aren't you? > > 2) Will CT support the above modes of attribute information exchange? > > > > My feeling is that we'd better identify the type of messages for CARD first > > and then can think about reusing any other protocol for the messages. And I > > think we need more discussion or output from the design team regarding the > > message types. > > Thanks. > > > > Eunsoo > > > > ----- Original Message ----- > > From: "James Kempf" > > To: > > Sent: Monday, January 13, 2003 1:58 PM > > Subject: [Seamoby] CARD between Routers - will CT do? > > > > > > > So most of the discussion here has been about CARD between the Mobile Node > > and > > > Access Router, and that's OK since it certainly is an important topic. > > > > > > However, equally important is how two Access Routers exchange information > > about > > > the access points connected to them. This could be statically configured, > > but > > > that would be very inconvenient. > > > > > > I'm wondering if this might be a good application of CT? The "context" > > here > > > would be an authenticatable list of access points connected up to a > > particular > > > router. > > > > > > Comments? > > > > > > jak > > > > > > > > > _______________________________________________ > > > Seamoby mailing list > > > Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Jan 14 15:31:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10581 for ; Tue, 14 Jan 2003 15:31:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EKiYJ30465; Tue, 14 Jan 2003 15:44:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EKhSJ30390 for ; Tue, 14 Jan 2003 15:43:28 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10504 for ; Tue, 14 Jan 2003 15:28:38 -0500 (EST) Message-ID: <009801c2bc0b$c1be94f0$5c6015ac@T23KEMPF> From: "James Kempf" To: , , References: Subject: Re: [Seamoby] CARD between Routers - will CT do? Date: Tue, 14 Jan 2003 12:30:17 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hemant, > [Hemant] Routing protocol does not tell physical neighborhood. It tells logical neighborhood. So a router one hop away from me could actually be far away physically and no candidate for handoff. Turning it around, routers physically next to each other can be in different BGP domains and BGP aggregated (or otherwise) exchanges do not have this information. So, I think discovery related message are very much required and issues draft has emphasized it. How you do it is open for discussion though. > As I mentioned at the ATL meeting, interdomain CARD is not possible unless the ISP exposes some part of the internal routing tables to the other domain, namely the access routers. The access routers are not border routers, they are internal routers. BCP in the Internet today is to not expose such information to peering ISPs. Are you proposing that we change this practice? As for your point about physical v.s. logical, my recollection of past conversations on this was that we had concluded that it is possible to determine whether a router is in the geographical neighborhood of another only if a) the information is configured in b) both routers have access to some source of geographical information about the other and can calculate the geographical distance somehow (but that still doesn't tell whether it's possible to move from a cell of an access point connnected up to one router to a cell connected to the other router, i.e. wireless connectivity between routers) or c) a mobile node which can hear both routers tells one about the other either before handoff or afterwards (which does give wireless connectivity). Of these three a) is of course always possible, b) is impractical and still needs some way to determine wireless connectivity, and c) is possible using MN to AR CARD, together with an inter-router protocol that allows the access router to tell if the MN is telling the truth. Therefore, I'm curious where you see a need for additional information to be exchanged about routers about wireless connectivity, and how that could be determined? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Jan 14 15:31:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10601 for ; Tue, 14 Jan 2003 15:31:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0EKk8V30509 for seamoby-archive@odin.ietf.org; Tue, 14 Jan 2003 15:46:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EKk8J30506 for ; Tue, 14 Jan 2003 15:46:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10584 for ; Tue, 14 Jan 2003 15:31:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EKiYJ30465; Tue, 14 Jan 2003 15:44:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EKhSJ30390 for ; Tue, 14 Jan 2003 15:43:28 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10504 for ; Tue, 14 Jan 2003 15:28:38 -0500 (EST) Message-ID: <009801c2bc0b$c1be94f0$5c6015ac@T23KEMPF> From: "James Kempf" To: , , References: Subject: Re: [Seamoby] CARD between Routers - will CT do? Date: Tue, 14 Jan 2003 12:30:17 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hemant, > [Hemant] Routing protocol does not tell physical neighborhood. It tells logical neighborhood. So a router one hop away from me could actually be far away physically and no candidate for handoff. Turning it around, routers physically next to each other can be in different BGP domains and BGP aggregated (or otherwise) exchanges do not have this information. So, I think discovery related message are very much required and issues draft has emphasized it. How you do it is open for discussion though. > As I mentioned at the ATL meeting, interdomain CARD is not possible unless the ISP exposes some part of the internal routing tables to the other domain, namely the access routers. The access routers are not border routers, they are internal routers. BCP in the Internet today is to not expose such information to peering ISPs. Are you proposing that we change this practice? As for your point about physical v.s. logical, my recollection of past conversations on this was that we had concluded that it is possible to determine whether a router is in the geographical neighborhood of another only if a) the information is configured in b) both routers have access to some source of geographical information about the other and can calculate the geographical distance somehow (but that still doesn't tell whether it's possible to move from a cell of an access point connnected up to one router to a cell connected to the other router, i.e. wireless connectivity between routers) or c) a mobile node which can hear both routers tells one about the other either before handoff or afterwards (which does give wireless connectivity). Of these three a) is of course always possible, b) is impractical and still needs some way to determine wireless connectivity, and c) is possible using MN to AR CARD, together with an inter-router protocol that allows the access router to tell if the MN is telling the truth. Therefore, I'm curious where you see a need for additional information to be exchanged about routers about wireless connectivity, and how that could be determined? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Jan 14 15:48:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11144 for ; Tue, 14 Jan 2003 15:48:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EL1LJ32461; Tue, 14 Jan 2003 16:01:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EL0PJ32272 for ; Tue, 14 Jan 2003 16:00:25 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11007 for ; Tue, 14 Jan 2003 15:45:26 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0EKmVB05137 for ; Tue, 14 Jan 2003 14:48:42 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 14 Jan 2003 14:48:25 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 14 Jan 2003 12:48:21 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CARD between Routers - will CT do? Date: Tue, 14 Jan 2003 15:48:20 -0500 Message-ID: Thread-Topic: [Seamoby] CARD between Routers - will CT do? Thread-Index: AcK8C/2N56/UdC9ZS0ecracyfyROuQAACj/Q To: , , X-OriginalArrivalTime: 14 Jan 2003 20:48:21.0260 (UTC) FILETIME=[462B44C0:01C2BC0E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0EL0PJ32273 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi James: See below: -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Tuesday, January 14, 2003 3:30 PM To: Chaskar Hemant (NRC/Boston); eunsoo@nec-lab.com; seamoby@ietf.org Subject: Re: [Seamoby] CARD between Routers - will CT do? Hemant, > [Hemant] Routing protocol does not tell physical neighborhood. It tells logical neighborhood. So a router one hop away from me could actually be far away physically and no candidate for handoff. Turning it around, routers physically next to each other can be in different BGP domains and BGP aggregated (or otherwise) exchanges do not have this information. So, I think discovery related message are very much required and issues draft has emphasized it. How you do it is open for discussion though. > As I mentioned at the ATL meeting, interdomain CARD is not possible unless the ISP exposes some part of the internal routing tables to the other domain, namely the access routers. The access routers are not border routers, they are internal routers. BCP in the Internet today is to not expose such information to peering ISPs. Are you proposing that we change this practice? Hemant --> I agree with you that CARD should not mess with Internet routing infrastructure. With Mobile IP, MN will know its old router and new router. Thus, information about their geographical adjacency is already exposed to third party. CARD should only be concerned about this information (however you distribute it and use it) without impacting routing infrastructure in any way. CARD is an edge phenomenon. As for your point about physical v.s. logical, my recollection of past conversations on this was that we had concluded that it is possible to determine whether a router is in the geographical neighborhood of another only if a) the information is configured in b) both routers have access to some source of geographical information about the other and can calculate the geographical distance somehow (but that still doesn't tell whether it's possible to move from a cell of an access point connnected up to one router to a cell connected to the other router, i.e. wireless connectivity between routers) or c) a mobile node which can hear both routers tells one about the other either before handoff or afterwards (which does give wireless connectivity). Of these three a) is of course always possible, b) is impractical and still needs some way to determine wireless connectivity, and c) is possible using MN to AR CARD, together with an inter-router protocol that allows the access router to tell if the MN is telling the truth. Therefore, I'm curious where you see a need for additional information to be exchanged about routers about wireless connectivity, and how that could be determined? Hemant --> I generally agree with your points a), b), c) above. The information of the kind you mention here is what I was referring to, in addition to capability exchange between ARs. Regards, Hemant jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Jan 14 15:48:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11167 for ; Tue, 14 Jan 2003 15:48:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0EL2qG00370 for seamoby-archive@odin.ietf.org; Tue, 14 Jan 2003 16:02:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EL2qJ00367 for ; Tue, 14 Jan 2003 16:02:52 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11147 for ; Tue, 14 Jan 2003 15:48:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EL1LJ32461; Tue, 14 Jan 2003 16:01:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EL0PJ32272 for ; Tue, 14 Jan 2003 16:00:25 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11007 for ; Tue, 14 Jan 2003 15:45:26 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0EKmVB05137 for ; Tue, 14 Jan 2003 14:48:42 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 14 Jan 2003 14:48:25 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 14 Jan 2003 12:48:21 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CARD between Routers - will CT do? Date: Tue, 14 Jan 2003 15:48:20 -0500 Message-ID: Thread-Topic: [Seamoby] CARD between Routers - will CT do? Thread-Index: AcK8C/2N56/UdC9ZS0ecracyfyROuQAACj/Q To: , , X-OriginalArrivalTime: 14 Jan 2003 20:48:21.0260 (UTC) FILETIME=[462B44C0:01C2BC0E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0EL0PJ32273 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi James: See below: -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Tuesday, January 14, 2003 3:30 PM To: Chaskar Hemant (NRC/Boston); eunsoo@nec-lab.com; seamoby@ietf.org Subject: Re: [Seamoby] CARD between Routers - will CT do? Hemant, > [Hemant] Routing protocol does not tell physical neighborhood. It tells logical neighborhood. So a router one hop away from me could actually be far away physically and no candidate for handoff. Turning it around, routers physically next to each other can be in different BGP domains and BGP aggregated (or otherwise) exchanges do not have this information. So, I think discovery related message are very much required and issues draft has emphasized it. How you do it is open for discussion though. > As I mentioned at the ATL meeting, interdomain CARD is not possible unless the ISP exposes some part of the internal routing tables to the other domain, namely the access routers. The access routers are not border routers, they are internal routers. BCP in the Internet today is to not expose such information to peering ISPs. Are you proposing that we change this practice? Hemant --> I agree with you that CARD should not mess with Internet routing infrastructure. With Mobile IP, MN will know its old router and new router. Thus, information about their geographical adjacency is already exposed to third party. CARD should only be concerned about this information (however you distribute it and use it) without impacting routing infrastructure in any way. CARD is an edge phenomenon. As for your point about physical v.s. logical, my recollection of past conversations on this was that we had concluded that it is possible to determine whether a router is in the geographical neighborhood of another only if a) the information is configured in b) both routers have access to some source of geographical information about the other and can calculate the geographical distance somehow (but that still doesn't tell whether it's possible to move from a cell of an access point connnected up to one router to a cell connected to the other router, i.e. wireless connectivity between routers) or c) a mobile node which can hear both routers tells one about the other either before handoff or afterwards (which does give wireless connectivity). Of these three a) is of course always possible, b) is impractical and still needs some way to determine wireless connectivity, and c) is possible using MN to AR CARD, together with an inter-router protocol that allows the access router to tell if the MN is telling the truth. Therefore, I'm curious where you see a need for additional information to be exchanged about routers about wireless connectivity, and how that could be determined? Hemant --> I generally agree with your points a), b), c) above. The information of the kind you mention here is what I was referring to, in addition to capability exchange between ARs. Regards, Hemant jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Jan 14 15:54:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11314 for ; Tue, 14 Jan 2003 15:54:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EL82J01859; Tue, 14 Jan 2003 16:08:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EL7jJ01822 for ; Tue, 14 Jan 2003 16:07:45 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11278 for ; Tue, 14 Jan 2003 15:52:55 -0500 (EST) Received: from eunsoo ([138.15.107.234]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 14 Jan 2003 15:56:17 -0500 Message-ID: <00bd01c2bc28$dbb45ee0$ea6b0f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , , References: <009801c2bc0b$c1be94f0$5c6015ac@T23KEMPF> Subject: Re: [Seamoby] CARD between Routers - will CT do? Date: Tue, 14 Jan 2003 15:58:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 14 Jan 2003 20:56:17.0320 (UTC) FILETIME=[61EC4280:01C2BC0F] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit James, Actually designing the way to discover Candidate Access Routers is, at least, one of the core problems for CARD. And the two proposals (I-Ds) submitted before the design team was formed contained two ideas for the problem. As the name "CAR Discovery" suggests, this work started since we looked for dynamic discovery mechanisms rather than sticking to the static configuration. So I think the working group needs to discuss possible solutions and reach a consensus. If two ISPs are not willing to disclose even the IP addresses and the MAC addresses of their access points and access routers to each other, well, the dynamic discovery mechanism won't be used for inter-domain CAR discovery. But they might do it for seamless roaming between the wireless networks of theirs as a part of the roaming agreements and there can be business benefits for them in doing that. So I'd suggest we look for technical solutions even for inter-domain CAR discovery. And intra-domain discovery of CARs is beneficial for the wireless ISPs anyway since it reduces their management overhead. So I think inter-AR signaling for dynamic discovery should be under our consideration. Regards, Eunsoo ----- Original Message ----- From: "James Kempf" To: ; ; Sent: Tuesday, January 14, 2003 12:30 PM Subject: Re: [Seamoby] CARD between Routers - will CT do? > Hemant, > > > [Hemant] Routing protocol does not tell physical neighborhood. It tells > logical neighborhood. So a router one hop away from me could actually be far > away physically and no candidate for handoff. Turning it around, routers > physically next to each other can be in different BGP domains and BGP aggregated > (or otherwise) exchanges do not have this information. So, I think discovery > related message are very much required and issues draft has emphasized it. How > you do it is open for discussion though. > > > > As I mentioned at the ATL meeting, interdomain CARD is not possible unless the > ISP exposes some part of the internal routing tables to the other domain, namely > the access routers. The access routers are not border routers, they are internal > routers. BCP in the Internet today is to not expose such information to peering > ISPs. Are you proposing that we change this practice? > > As for your point about physical v.s. logical, my recollection of past > conversations on this was that we had concluded that it is possible to determine > whether a router is in the geographical neighborhood of another only if a) the > information is configured in b) both routers have access to some source of > geographical information about the other and can calculate the geographical > distance somehow (but that still doesn't tell whether it's possible to move from > a cell of an access point connnected up to one router to a cell connected to the > other router, i.e. wireless connectivity between routers) or c) a mobile node > which can hear both routers tells one about the other either before handoff or > afterwards (which does give wireless connectivity). > > Of these three a) is of course always possible, b) is impractical and still > needs some way to determine wireless connectivity, and c) is possible using MN > to AR CARD, together with an inter-router protocol that allows the access router > to tell if the MN is telling the truth. Therefore, I'm curious where you see a > need for additional information to be exchanged about routers about wireless > connectivity, and how that could be determined? > > jak > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Jan 14 15:55:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11355 for ; Tue, 14 Jan 2003 15:55:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0EL9KI02025 for seamoby-archive@odin.ietf.org; Tue, 14 Jan 2003 16:09:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EL9KJ02022 for ; Tue, 14 Jan 2003 16:09:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11317 for ; Tue, 14 Jan 2003 15:54:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EL82J01859; Tue, 14 Jan 2003 16:08:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EL7jJ01822 for ; Tue, 14 Jan 2003 16:07:45 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11278 for ; Tue, 14 Jan 2003 15:52:55 -0500 (EST) Received: from eunsoo ([138.15.107.234]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 14 Jan 2003 15:56:17 -0500 Message-ID: <00bd01c2bc28$dbb45ee0$ea6b0f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , , References: <009801c2bc0b$c1be94f0$5c6015ac@T23KEMPF> Subject: Re: [Seamoby] CARD between Routers - will CT do? Date: Tue, 14 Jan 2003 15:58:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 14 Jan 2003 20:56:17.0320 (UTC) FILETIME=[61EC4280:01C2BC0F] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit James, Actually designing the way to discover Candidate Access Routers is, at least, one of the core problems for CARD. And the two proposals (I-Ds) submitted before the design team was formed contained two ideas for the problem. As the name "CAR Discovery" suggests, this work started since we looked for dynamic discovery mechanisms rather than sticking to the static configuration. So I think the working group needs to discuss possible solutions and reach a consensus. If two ISPs are not willing to disclose even the IP addresses and the MAC addresses of their access points and access routers to each other, well, the dynamic discovery mechanism won't be used for inter-domain CAR discovery. But they might do it for seamless roaming between the wireless networks of theirs as a part of the roaming agreements and there can be business benefits for them in doing that. So I'd suggest we look for technical solutions even for inter-domain CAR discovery. And intra-domain discovery of CARs is beneficial for the wireless ISPs anyway since it reduces their management overhead. So I think inter-AR signaling for dynamic discovery should be under our consideration. Regards, Eunsoo ----- Original Message ----- From: "James Kempf" To: ; ; Sent: Tuesday, January 14, 2003 12:30 PM Subject: Re: [Seamoby] CARD between Routers - will CT do? > Hemant, > > > [Hemant] Routing protocol does not tell physical neighborhood. It tells > logical neighborhood. So a router one hop away from me could actually be far > away physically and no candidate for handoff. Turning it around, routers > physically next to each other can be in different BGP domains and BGP aggregated > (or otherwise) exchanges do not have this information. So, I think discovery > related message are very much required and issues draft has emphasized it. How > you do it is open for discussion though. > > > > As I mentioned at the ATL meeting, interdomain CARD is not possible unless the > ISP exposes some part of the internal routing tables to the other domain, namely > the access routers. The access routers are not border routers, they are internal > routers. BCP in the Internet today is to not expose such information to peering > ISPs. Are you proposing that we change this practice? > > As for your point about physical v.s. logical, my recollection of past > conversations on this was that we had concluded that it is possible to determine > whether a router is in the geographical neighborhood of another only if a) the > information is configured in b) both routers have access to some source of > geographical information about the other and can calculate the geographical > distance somehow (but that still doesn't tell whether it's possible to move from > a cell of an access point connnected up to one router to a cell connected to the > other router, i.e. wireless connectivity between routers) or c) a mobile node > which can hear both routers tells one about the other either before handoff or > afterwards (which does give wireless connectivity). > > Of these three a) is of course always possible, b) is impractical and still > needs some way to determine wireless connectivity, and c) is possible using MN > to AR CARD, together with an inter-router protocol that allows the access router > to tell if the MN is telling the truth. Therefore, I'm curious where you see a > need for additional information to be exchanged about routers about wireless > connectivity, and how that could be determined? > > jak > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Jan 14 17:44:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14545 for ; Tue, 14 Jan 2003 17:44:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EMwdJ09029; Tue, 14 Jan 2003 17:58:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EMvXJ08980 for ; Tue, 14 Jan 2003 17:57:33 -0500 Received: from motgate2.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14473 for ; Tue, 14 Jan 2003 17:42:42 -0500 (EST) Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h0EMkUEQ005409 for ; Tue, 14 Jan 2003 15:46:30 -0700 (MST) Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id PAA03562 for ; Tue, 14 Jan 2003 15:46:03 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Tue, 14 Jan 2003 16:46:02 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD5C81@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Govind.Krishnamurthi@nokia.com'" , kempf@docomolabs-usa.com, seamoby@ietf.org Subject: RE: [Seamoby] CARD between Routers - will CT do? Date: Tue, 14 Jan 2003 16:45:53 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Govind, Jim, I am starting from the beginning of the thread, forgive me if this has been brought up in the following emails (I will know soon). Capability information was brought up early on as one legitimate type of information that can be handled by CT. I guess, this fell through the cracks somehow. As Jim said, CT is not limited to "during" handovers, we are considering pre-handover CTs as a scenario. CT does not have to be MN specific, we can certainly design it that way. But why is it not MN specific? Isn't capability discovery done to find a good home for a specific MN? If Capability discovery is just done for statistics/ network management purpose, then it can be handled in many different ways (including through a specialized entity). I can understand the CARD folks not wanting to make their protocol independent of CT signaling, but that does not prevent people from using CT to carry capability information. Regards, Madjid -----Original Message----- From: Govind.Krishnamurthi@nokia.com [mailto:Govind.Krishnamurthi@nokia.com] Sent: Monday, January 13, 2003 4:34 PM To: kempf@docomolabs-usa.com; seamoby@ietf.org Subject: RE: [Seamoby] CARD between Routers - will CT do? Hello James, I wouldn't want to tie it up with CT for the following reason. This information may be needed to refreshed at times other than that during handovers, which is when CT happens. Infact, this information is more important prior to the handover process. How does an AR discover any change in the AP configuration? I think this should be stored as soft state and should be refreshed min(when an AR knows of an AP configuration change, lifetime expiration). Also, right now, contexts are MN specific. This is not MN specific context. Let me know if I have misunderstood your comment. Thanks, Govind. -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Monday, January 13, 2003 4:58 PM To: seamoby@ietf.org Subject: [Seamoby] CARD between Routers - will CT do? So most of the discussion here has been about CARD between the Mobile Node and Access Router, and that's OK since it certainly is an important topic. However, equally important is how two Access Routers exchange information about the access points connected to them. This could be statically configured, but that would be very inconvenient. I'm wondering if this might be a good application of CT? The "context" here would be an authenticatable list of access points connected up to a particular router. Comments? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Jan 14 17:45:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14569 for ; Tue, 14 Jan 2003 17:45:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0EMxh709131 for seamoby-archive@odin.ietf.org; Tue, 14 Jan 2003 17:59:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EMxhJ09128 for ; Tue, 14 Jan 2003 17:59:43 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14548 for ; Tue, 14 Jan 2003 17:44:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EMwdJ09029; Tue, 14 Jan 2003 17:58:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EMvXJ08980 for ; Tue, 14 Jan 2003 17:57:33 -0500 Received: from motgate2.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14473 for ; Tue, 14 Jan 2003 17:42:42 -0500 (EST) Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h0EMkUEQ005409 for ; Tue, 14 Jan 2003 15:46:30 -0700 (MST) Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id PAA03562 for ; Tue, 14 Jan 2003 15:46:03 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Tue, 14 Jan 2003 16:46:02 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD5C81@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Govind.Krishnamurthi@nokia.com'" , kempf@docomolabs-usa.com, seamoby@ietf.org Subject: RE: [Seamoby] CARD between Routers - will CT do? Date: Tue, 14 Jan 2003 16:45:53 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Govind, Jim, I am starting from the beginning of the thread, forgive me if this has been brought up in the following emails (I will know soon). Capability information was brought up early on as one legitimate type of information that can be handled by CT. I guess, this fell through the cracks somehow. As Jim said, CT is not limited to "during" handovers, we are considering pre-handover CTs as a scenario. CT does not have to be MN specific, we can certainly design it that way. But why is it not MN specific? Isn't capability discovery done to find a good home for a specific MN? If Capability discovery is just done for statistics/ network management purpose, then it can be handled in many different ways (including through a specialized entity). I can understand the CARD folks not wanting to make their protocol independent of CT signaling, but that does not prevent people from using CT to carry capability information. Regards, Madjid -----Original Message----- From: Govind.Krishnamurthi@nokia.com [mailto:Govind.Krishnamurthi@nokia.com] Sent: Monday, January 13, 2003 4:34 PM To: kempf@docomolabs-usa.com; seamoby@ietf.org Subject: RE: [Seamoby] CARD between Routers - will CT do? Hello James, I wouldn't want to tie it up with CT for the following reason. This information may be needed to refreshed at times other than that during handovers, which is when CT happens. Infact, this information is more important prior to the handover process. How does an AR discover any change in the AP configuration? I think this should be stored as soft state and should be refreshed min(when an AR knows of an AP configuration change, lifetime expiration). Also, right now, contexts are MN specific. This is not MN specific context. Let me know if I have misunderstood your comment. Thanks, Govind. -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Monday, January 13, 2003 4:58 PM To: seamoby@ietf.org Subject: [Seamoby] CARD between Routers - will CT do? So most of the discussion here has been about CARD between the Mobile Node and Access Router, and that's OK since it certainly is an important topic. However, equally important is how two Access Routers exchange information about the access points connected to them. This could be statically configured, but that would be very inconvenient. I'm wondering if this might be a good application of CT? The "context" here would be an authenticatable list of access points connected up to a particular router. Comments? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Jan 14 17:49:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14662 for ; Tue, 14 Jan 2003 17:49:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EN37J09340; Tue, 14 Jan 2003 18:03:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EN2rJ09314 for ; Tue, 14 Jan 2003 18:02:53 -0500 Received: from motgate2.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14631 for ; Tue, 14 Jan 2003 17:48:02 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h0EMpoEQ006976 for ; Tue, 14 Jan 2003 15:51:50 -0700 (MST) Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id PAA26254 for ; Tue, 14 Jan 2003 15:51:23 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Tue, 14 Jan 2003 16:50:33 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD5C82@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Paine, Richard H'" , "'James Kempf'" , seamoby@ietf.org Cc: DL WTWG Subject: RE: [Seamoby] CARD between Routers - will CT do? Date: Tue, 14 Jan 2003 16:50:28 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , I have been forced to debate against using IAPP for generic context transfer over and over again. IAPP only does Radius authentication and is not suitable for dynamic context, it is not based on good triggers. -----Original Message----- From: Paine, Richard H [mailto:richard.h.paine@boeing.com] Sent: Monday, January 13, 2003 9:30 PM To: 'James Kempf'; seamoby@ietf.org Cc: DL WTWG Subject: RE: [Seamoby] CARD between Routers - will CT do? What might be more important to look at is between layer 2 access points in wireless LANs. IEEE 802.11f has essentially developed the context transfer protocol between access points. It won't be long before those access points include routers in them. In other words, CT does the handoff and then routes across an fixed or an autonomous wireless LAN. Richard H. Paine Success is getting what you want, happiness is liking what you get! IPPhone: 206.766.5808 Phone: 425.865.4921 Cellular: 206.854.8199 Pager: 206.797.4580 Email: richard.h.paine@boeing.com -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Monday, January 13, 2003 1:58 PM To: seamoby@ietf.org Subject: [Seamoby] CARD between Routers - will CT do? So most of the discussion here has been about CARD between the Mobile Node and Access Router, and that's OK since it certainly is an important topic. However, equally important is how two Access Routers exchange information about the access points connected to them. This could be statically configured, but that would be very inconvenient. I'm wondering if this might be a good application of CT? The "context" here would be an authenticatable list of access points connected up to a particular router. Comments? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Jan 14 17:49:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14693 for ; Tue, 14 Jan 2003 17:49:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0EN41g09372 for seamoby-archive@odin.ietf.org; Tue, 14 Jan 2003 18:04:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EN41J09369 for ; Tue, 14 Jan 2003 18:04:01 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14665 for ; Tue, 14 Jan 2003 17:49:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EN37J09340; Tue, 14 Jan 2003 18:03:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EN2rJ09314 for ; Tue, 14 Jan 2003 18:02:53 -0500 Received: from motgate2.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14631 for ; Tue, 14 Jan 2003 17:48:02 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h0EMpoEQ006976 for ; Tue, 14 Jan 2003 15:51:50 -0700 (MST) Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id PAA26254 for ; Tue, 14 Jan 2003 15:51:23 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Tue, 14 Jan 2003 16:50:33 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD5C82@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Paine, Richard H'" , "'James Kempf'" , seamoby@ietf.org Cc: DL WTWG Subject: RE: [Seamoby] CARD between Routers - will CT do? Date: Tue, 14 Jan 2003 16:50:28 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , I have been forced to debate against using IAPP for generic context transfer over and over again. IAPP only does Radius authentication and is not suitable for dynamic context, it is not based on good triggers. -----Original Message----- From: Paine, Richard H [mailto:richard.h.paine@boeing.com] Sent: Monday, January 13, 2003 9:30 PM To: 'James Kempf'; seamoby@ietf.org Cc: DL WTWG Subject: RE: [Seamoby] CARD between Routers - will CT do? What might be more important to look at is between layer 2 access points in wireless LANs. IEEE 802.11f has essentially developed the context transfer protocol between access points. It won't be long before those access points include routers in them. In other words, CT does the handoff and then routes across an fixed or an autonomous wireless LAN. Richard H. Paine Success is getting what you want, happiness is liking what you get! IPPhone: 206.766.5808 Phone: 425.865.4921 Cellular: 206.854.8199 Pager: 206.797.4580 Email: richard.h.paine@boeing.com -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Monday, January 13, 2003 1:58 PM To: seamoby@ietf.org Subject: [Seamoby] CARD between Routers - will CT do? So most of the discussion here has been about CARD between the Mobile Node and Access Router, and that's OK since it certainly is an important topic. However, equally important is how two Access Routers exchange information about the access points connected to them. This could be statically configured, but that would be very inconvenient. I'm wondering if this might be a good application of CT? The "context" here would be an authenticatable list of access points connected up to a particular router. Comments? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Jan 14 17:59:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14918 for ; Tue, 14 Jan 2003 17:59:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ENDYJ10428; Tue, 14 Jan 2003 18:13:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ENCSJ10364 for ; Tue, 14 Jan 2003 18:12:28 -0500 Received: from motgate.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14878 for ; Tue, 14 Jan 2003 17:57:36 -0500 (EST) Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h0EN0vK8025262 for ; Tue, 14 Jan 2003 16:00:57 -0700 (MST) Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id QAA08242 for ; Tue, 14 Jan 2003 16:00:57 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Tue, 14 Jan 2003 17:00:56 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD5C83@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'James Kempf'" , Eunsoo Shim , seamoby@ietf.org Subject: RE: [Seamoby] CARD between Routers - will CT do? Date: Tue, 14 Jan 2003 17:00:48 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Jim, I agree with you. It is not boiling the ocean. I don't intend to run 250 different protocols right before a handover. If I can get two birds with one stone, I will. CT can be extended to carry capability info and designing a mobility framework, I may just use that, if I have other selection procedures. I can understand CARD people's concern about relying on CT, but I also never understood, why TAR selection and address translation should be done by one and same protocol. I thought in Atlanta we were talking about separating the two? Madjid -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Tuesday, January 14, 2003 10:39 AM To: Eunsoo Shim; seamoby@ietf.org Subject: Re: [Seamoby] CARD between Routers - will CT do? Eunsoo, There is no need for discovery related messages between ARs. Routers know where they are, the routing protocol tells them. There is, of course, an issue of the AR finding APs attached to it, but that is a different question. That would probably benefit by some protocol, but, of course, we have this problem about APs being invisible as far as IP is concerned. The idea of using CT for CARD between routers came out of some discussions we've been having here about how best to implement these protocols. Having a generic framework within which all the inter-AR signaling can fit could make the implementation cleaner. For example, one could view the HI/HAck signaling of FMIP as another instance of CT. One could imagine extending the routing protocol to do implement the framework, but having a separate protocol might be better. Anyway, maybe this is boiling the ocean. We are already having enough trouble getting the specs done on CT and CARD for MNs. Maybe we ought to finish that first, then revisit the issue when we have more experience with implementing these protocols. jak ----- Original Message ----- From: "Eunsoo Shim" To: "James Kempf" ; Sent: Tuesday, January 14, 2003 6:00 AM Subject: Re: [Seamoby] CARD between Routers - will CT do? > Hi, James, > > There should be two types of messages between ARs for CARD. > - Discovery process related > - Attributes (including information about access points) related > > And there can be two modes of attribute information exchange. > - One time request-response > - Periodic updates (one time request and follow-up periodic responses) > > I have two questions about your suggestion. > 1) You are suggesting using CT for attribute information exchanges but not > the discovery related signaling, aren't you? > 2) Will CT support the above modes of attribute information exchange? > > My feeling is that we'd better identify the type of messages for CARD first > and then can think about reusing any other protocol for the messages. And I > think we need more discussion or output from the design team regarding the > message types. > Thanks. > > Eunsoo > > ----- Original Message ----- > From: "James Kempf" > To: > Sent: Monday, January 13, 2003 1:58 PM > Subject: [Seamoby] CARD between Routers - will CT do? > > > > So most of the discussion here has been about CARD between the Mobile Node > and > > Access Router, and that's OK since it certainly is an important topic. > > > > However, equally important is how two Access Routers exchange information > about > > the access points connected to them. This could be statically configured, > but > > that would be very inconvenient. > > > > I'm wondering if this might be a good application of CT? The "context" > here > > would be an authenticatable list of access points connected up to a > particular > > router. > > > > Comments? > > > > jak > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Jan 14 18:00:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14953 for ; Tue, 14 Jan 2003 18:00:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0ENEXh10495 for seamoby-archive@odin.ietf.org; Tue, 14 Jan 2003 18:14:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ENEXJ10492 for ; Tue, 14 Jan 2003 18:14:33 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14921 for ; Tue, 14 Jan 2003 17:59:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ENDYJ10428; Tue, 14 Jan 2003 18:13:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ENCSJ10364 for ; Tue, 14 Jan 2003 18:12:28 -0500 Received: from motgate.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14878 for ; Tue, 14 Jan 2003 17:57:36 -0500 (EST) Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h0EN0vK8025262 for ; Tue, 14 Jan 2003 16:00:57 -0700 (MST) Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id QAA08242 for ; Tue, 14 Jan 2003 16:00:57 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Tue, 14 Jan 2003 17:00:56 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD5C83@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'James Kempf'" , Eunsoo Shim , seamoby@ietf.org Subject: RE: [Seamoby] CARD between Routers - will CT do? Date: Tue, 14 Jan 2003 17:00:48 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Jim, I agree with you. It is not boiling the ocean. I don't intend to run 250 different protocols right before a handover. If I can get two birds with one stone, I will. CT can be extended to carry capability info and designing a mobility framework, I may just use that, if I have other selection procedures. I can understand CARD people's concern about relying on CT, but I also never understood, why TAR selection and address translation should be done by one and same protocol. I thought in Atlanta we were talking about separating the two? Madjid -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Tuesday, January 14, 2003 10:39 AM To: Eunsoo Shim; seamoby@ietf.org Subject: Re: [Seamoby] CARD between Routers - will CT do? Eunsoo, There is no need for discovery related messages between ARs. Routers know where they are, the routing protocol tells them. There is, of course, an issue of the AR finding APs attached to it, but that is a different question. That would probably benefit by some protocol, but, of course, we have this problem about APs being invisible as far as IP is concerned. The idea of using CT for CARD between routers came out of some discussions we've been having here about how best to implement these protocols. Having a generic framework within which all the inter-AR signaling can fit could make the implementation cleaner. For example, one could view the HI/HAck signaling of FMIP as another instance of CT. One could imagine extending the routing protocol to do implement the framework, but having a separate protocol might be better. Anyway, maybe this is boiling the ocean. We are already having enough trouble getting the specs done on CT and CARD for MNs. Maybe we ought to finish that first, then revisit the issue when we have more experience with implementing these protocols. jak ----- Original Message ----- From: "Eunsoo Shim" To: "James Kempf" ; Sent: Tuesday, January 14, 2003 6:00 AM Subject: Re: [Seamoby] CARD between Routers - will CT do? > Hi, James, > > There should be two types of messages between ARs for CARD. > - Discovery process related > - Attributes (including information about access points) related > > And there can be two modes of attribute information exchange. > - One time request-response > - Periodic updates (one time request and follow-up periodic responses) > > I have two questions about your suggestion. > 1) You are suggesting using CT for attribute information exchanges but not > the discovery related signaling, aren't you? > 2) Will CT support the above modes of attribute information exchange? > > My feeling is that we'd better identify the type of messages for CARD first > and then can think about reusing any other protocol for the messages. And I > think we need more discussion or output from the design team regarding the > message types. > Thanks. > > Eunsoo > > ----- Original Message ----- > From: "James Kempf" > To: > Sent: Monday, January 13, 2003 1:58 PM > Subject: [Seamoby] CARD between Routers - will CT do? > > > > So most of the discussion here has been about CARD between the Mobile Node > and > > Access Router, and that's OK since it certainly is an important topic. > > > > However, equally important is how two Access Routers exchange information > about > > the access points connected to them. This could be statically configured, > but > > that would be very inconvenient. > > > > I'm wondering if this might be a good application of CT? The "context" > here > > would be an authenticatable list of access points connected up to a > particular > > router. > > > > Comments? > > > > jak > > > > > > _______________________________________________ > > Seamoby mailing list > > Seamoby@ietf.org > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Jan 14 18:07:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15252 for ; Tue, 14 Jan 2003 18:07:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ENL6J10721; Tue, 14 Jan 2003 18:21:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ENKTJ10695 for ; Tue, 14 Jan 2003 18:20:29 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15225 for ; Tue, 14 Jan 2003 18:05:27 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0EN87B07352 for ; Tue, 14 Jan 2003 17:08:18 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 14 Jan 2003 17:07:59 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 14 Jan 2003 15:07:17 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CARD between Routers - will CT do? Date: Tue, 14 Jan 2003 18:07:16 -0500 Message-ID: Thread-Topic: [Seamoby] CARD between Routers - will CT do? Thread-Index: AcK8HrupBqw5WZZNQfCEJiYDL+u5OQAACjJg To: , , X-OriginalArrivalTime: 14 Jan 2003 23:07:17.0626 (UTC) FILETIME=[AF07C5A0:01C2BC21] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0ENKTJ10696 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Madjid, My initial mail was because of the following reason. First, the triggers may be totally different. When I said around CT happens around handover time, as far as I remember these triggers for CT happened around handover time (I might be wrong here and I must accept its been sometime since I read the CT requirements/issues doc). If CT were to be the bearer for CARD capability discovery it should be adapted to accept CARD triggers. Thats all I meant. This can be done, but I don't know whether this exists. Though capability discovery is to find a good home for the MN, the capabilities in question pertain to ARs not MNs, thats what I meant by AR-specific and not MN-specific. Again, these are optmizations that Jim suggested. If the design team for CARD discovery comes with generic ICMP options for CARD for inter AR excahnges, it can be sent along with CT messaging, I don't deny it. I guess we will have to go through the same cycle of discussions as we had with FMIPv6 and CARD interaction. Cheers, Govind. -----Original Message----- From: ext Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] Sent: Tuesday, January 14, 2003 5:46 PM To: Krishnamurthi Govind (NRC/Boston); kempf@docomolabs-usa.com; seamoby@ietf.org Subject: RE: [Seamoby] CARD between Routers - will CT do? Govind, Jim, I am starting from the beginning of the thread, forgive me if this has been brought up in the following emails (I will know soon). Capability information was brought up early on as one legitimate type of information that can be handled by CT. I guess, this fell through the cracks somehow. As Jim said, CT is not limited to "during" handovers, we are considering pre-handover CTs as a scenario. CT does not have to be MN specific, we can certainly design it that way. But why is it not MN specific? Isn't capability discovery done to find a good home for a specific MN? If Capability discovery is just done for statistics/ network management purpose, then it can be handled in many different ways (including through a specialized entity). I can understand the CARD folks not wanting to make their protocol independent of CT signaling, but that does not prevent people from using CT to carry capability information. Regards, Madjid -----Original Message----- From: Govind.Krishnamurthi@nokia.com [mailto:Govind.Krishnamurthi@nokia.com] Sent: Monday, January 13, 2003 4:34 PM To: kempf@docomolabs-usa.com; seamoby@ietf.org Subject: RE: [Seamoby] CARD between Routers - will CT do? Hello James, I wouldn't want to tie it up with CT for the following reason. This information may be needed to refreshed at times other than that during handovers, which is when CT happens. Infact, this information is more important prior to the handover process. How does an AR discover any change in the AP configuration? I think this should be stored as soft state and should be refreshed min(when an AR knows of an AP configuration change, lifetime expiration). Also, right now, contexts are MN specific. This is not MN specific context. Let me know if I have misunderstood your comment. Thanks, Govind. -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Monday, January 13, 2003 4:58 PM To: seamoby@ietf.org Subject: [Seamoby] CARD between Routers - will CT do? So most of the discussion here has been about CARD between the Mobile Node and Access Router, and that's OK since it certainly is an important topic. However, equally important is how two Access Routers exchange information about the access points connected to them. This could be statically configured, but that would be very inconvenient. I'm wondering if this might be a good application of CT? The "context" here would be an authenticatable list of access points connected up to a particular router. Comments? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Jan 14 18:07:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15328 for ; Tue, 14 Jan 2003 18:07:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0ENMAu10771 for seamoby-archive@odin.ietf.org; Tue, 14 Jan 2003 18:22:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ENMAJ10768 for ; Tue, 14 Jan 2003 18:22:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15255 for ; Tue, 14 Jan 2003 18:07:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ENL6J10721; Tue, 14 Jan 2003 18:21:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ENKTJ10695 for ; Tue, 14 Jan 2003 18:20:29 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15225 for ; Tue, 14 Jan 2003 18:05:27 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0EN87B07352 for ; Tue, 14 Jan 2003 17:08:18 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 14 Jan 2003 17:07:59 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 14 Jan 2003 15:07:17 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CARD between Routers - will CT do? Date: Tue, 14 Jan 2003 18:07:16 -0500 Message-ID: Thread-Topic: [Seamoby] CARD between Routers - will CT do? Thread-Index: AcK8HrupBqw5WZZNQfCEJiYDL+u5OQAACjJg To: , , X-OriginalArrivalTime: 14 Jan 2003 23:07:17.0626 (UTC) FILETIME=[AF07C5A0:01C2BC21] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0ENKTJ10696 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Madjid, My initial mail was because of the following reason. First, the triggers may be totally different. When I said around CT happens around handover time, as far as I remember these triggers for CT happened around handover time (I might be wrong here and I must accept its been sometime since I read the CT requirements/issues doc). If CT were to be the bearer for CARD capability discovery it should be adapted to accept CARD triggers. Thats all I meant. This can be done, but I don't know whether this exists. Though capability discovery is to find a good home for the MN, the capabilities in question pertain to ARs not MNs, thats what I meant by AR-specific and not MN-specific. Again, these are optmizations that Jim suggested. If the design team for CARD discovery comes with generic ICMP options for CARD for inter AR excahnges, it can be sent along with CT messaging, I don't deny it. I guess we will have to go through the same cycle of discussions as we had with FMIPv6 and CARD interaction. Cheers, Govind. -----Original Message----- From: ext Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] Sent: Tuesday, January 14, 2003 5:46 PM To: Krishnamurthi Govind (NRC/Boston); kempf@docomolabs-usa.com; seamoby@ietf.org Subject: RE: [Seamoby] CARD between Routers - will CT do? Govind, Jim, I am starting from the beginning of the thread, forgive me if this has been brought up in the following emails (I will know soon). Capability information was brought up early on as one legitimate type of information that can be handled by CT. I guess, this fell through the cracks somehow. As Jim said, CT is not limited to "during" handovers, we are considering pre-handover CTs as a scenario. CT does not have to be MN specific, we can certainly design it that way. But why is it not MN specific? Isn't capability discovery done to find a good home for a specific MN? If Capability discovery is just done for statistics/ network management purpose, then it can be handled in many different ways (including through a specialized entity). I can understand the CARD folks not wanting to make their protocol independent of CT signaling, but that does not prevent people from using CT to carry capability information. Regards, Madjid -----Original Message----- From: Govind.Krishnamurthi@nokia.com [mailto:Govind.Krishnamurthi@nokia.com] Sent: Monday, January 13, 2003 4:34 PM To: kempf@docomolabs-usa.com; seamoby@ietf.org Subject: RE: [Seamoby] CARD between Routers - will CT do? Hello James, I wouldn't want to tie it up with CT for the following reason. This information may be needed to refreshed at times other than that during handovers, which is when CT happens. Infact, this information is more important prior to the handover process. How does an AR discover any change in the AP configuration? I think this should be stored as soft state and should be refreshed min(when an AR knows of an AP configuration change, lifetime expiration). Also, right now, contexts are MN specific. This is not MN specific context. Let me know if I have misunderstood your comment. Thanks, Govind. -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Monday, January 13, 2003 4:58 PM To: seamoby@ietf.org Subject: [Seamoby] CARD between Routers - will CT do? So most of the discussion here has been about CARD between the Mobile Node and Access Router, and that's OK since it certainly is an important topic. However, equally important is how two Access Routers exchange information about the access points connected to them. This could be statically configured, but that would be very inconvenient. I'm wondering if this might be a good application of CT? The "context" here would be an authenticatable list of access points connected up to a particular router. Comments? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Jan 14 18:23:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15814 for ; Tue, 14 Jan 2003 18:23:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ENbMJ12271; Tue, 14 Jan 2003 18:37:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ENa2J11728 for ; Tue, 14 Jan 2003 18:36:02 -0500 Received: from ftpbox.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15760 for ; Tue, 14 Jan 2003 18:21:11 -0500 (EST) Received: from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h0ENOVp5000304 for ; Tue, 14 Jan 2003 16:24:31 -0700 (MST) Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id QAA20413 for ; Tue, 14 Jan 2003 16:24:31 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Tue, 14 Jan 2003 17:24:30 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD5C85@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Govind.Krishnamurthi@nokia.com'" , Nakhjiri Madjid-MNAKHJI1 , kempf@docomolabs-usa.com, seamoby@ietf.org Subject: RE: [Seamoby] CARD between Routers - will CT do? Date: Tue, 14 Jan 2003 17:24:25 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Govind, I agree, the triggers are in general case different and I understand, you not wanting to rely on CT for your messaging. In fact I myself am in favor of not using FMIP or CT for your CARD protocol design to keep your hands open, but at same time, you need to keep the users options open. I personally will not use standalone CARD in my design (due to complexity). All I am saying is that carrying capability was something in fact I kept advocating in early days of CT (when CARD DT was called micromobility :) ) I guess this is a matter of taste, I think AR-specific capability signaling if not for assisting handovers can be part of network management that may be handled through specialized entities. This is especially inevitable when you are dealing with inter-admin domain cases (just as James was talking about different ISPs), this is a very important scenario. You can't just expect ISPs to let ARs spill their guts to other ISPs freely.... Madjid -----Original Message----- From: Govind.Krishnamurthi@nokia.com [mailto:Govind.Krishnamurthi@nokia.com] Sent: Tuesday, January 14, 2003 5:07 PM To: Madjid Nakhjiri; kempf@docomolabs-usa.com; seamoby@ietf.org Subject: RE: [Seamoby] CARD between Routers - will CT do? Madjid, My initial mail was because of the following reason. First, the triggers may be totally different. When I said around CT happens around handover time, as far as I remember these triggers for CT happened around handover time (I might be wrong here and I must accept its been sometime since I read the CT requirements/issues doc). If CT were to be the bearer for CARD capability discovery it should be adapted to accept CARD triggers. Thats all I meant. This can be done, but I don't know whether this exists. Though capability discovery is to find a good home for the MN, the capabilities in question pertain to ARs not MNs, thats what I meant by AR-specific and not MN-specific. Again, these are optmizations that Jim suggested. If the design team for CARD discovery comes with generic ICMP options for CARD for inter AR excahnges, it can be sent along with CT messaging, I don't deny it. I guess we will have to go through the same cycle of discussions as we had with FMIPv6 and CARD interaction. Cheers, Govind. -----Original Message----- From: ext Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] Sent: Tuesday, January 14, 2003 5:46 PM To: Krishnamurthi Govind (NRC/Boston); kempf@docomolabs-usa.com; seamoby@ietf.org Subject: RE: [Seamoby] CARD between Routers - will CT do? Govind, Jim, I am starting from the beginning of the thread, forgive me if this has been brought up in the following emails (I will know soon). Capability information was brought up early on as one legitimate type of information that can be handled by CT. I guess, this fell through the cracks somehow. As Jim said, CT is not limited to "during" handovers, we are considering pre-handover CTs as a scenario. CT does not have to be MN specific, we can certainly design it that way. But why is it not MN specific? Isn't capability discovery done to find a good home for a specific MN? If Capability discovery is just done for statistics/ network management purpose, then it can be handled in many different ways (including through a specialized entity). I can understand the CARD folks not wanting to make their protocol independent of CT signaling, but that does not prevent people from using CT to carry capability information. Regards, Madjid -----Original Message----- From: Govind.Krishnamurthi@nokia.com [mailto:Govind.Krishnamurthi@nokia.com] Sent: Monday, January 13, 2003 4:34 PM To: kempf@docomolabs-usa.com; seamoby@ietf.org Subject: RE: [Seamoby] CARD between Routers - will CT do? Hello James, I wouldn't want to tie it up with CT for the following reason. This information may be needed to refreshed at times other than that during handovers, which is when CT happens. Infact, this information is more important prior to the handover process. How does an AR discover any change in the AP configuration? I think this should be stored as soft state and should be refreshed min(when an AR knows of an AP configuration change, lifetime expiration). Also, right now, contexts are MN specific. This is not MN specific context. Let me know if I have misunderstood your comment. Thanks, Govind. -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Monday, January 13, 2003 4:58 PM To: seamoby@ietf.org Subject: [Seamoby] CARD between Routers - will CT do? So most of the discussion here has been about CARD between the Mobile Node and Access Router, and that's OK since it certainly is an important topic. However, equally important is how two Access Routers exchange information about the access points connected to them. This could be statically configured, but that would be very inconvenient. I'm wondering if this might be a good application of CT? The "context" here would be an authenticatable list of access points connected up to a particular router. Comments? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Jan 14 18:24:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15840 for ; Tue, 14 Jan 2003 18:24:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0ENcPI12526 for seamoby-archive@odin.ietf.org; Tue, 14 Jan 2003 18:38:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ENcPJ12523 for ; Tue, 14 Jan 2003 18:38:25 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15817 for ; Tue, 14 Jan 2003 18:23:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ENbMJ12271; Tue, 14 Jan 2003 18:37:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ENa2J11728 for ; Tue, 14 Jan 2003 18:36:02 -0500 Received: from ftpbox.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15760 for ; Tue, 14 Jan 2003 18:21:11 -0500 (EST) Received: from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h0ENOVp5000304 for ; Tue, 14 Jan 2003 16:24:31 -0700 (MST) Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id QAA20413 for ; Tue, 14 Jan 2003 16:24:31 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2656.59) id ; Tue, 14 Jan 2003 17:24:30 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B08AD5C85@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'Govind.Krishnamurthi@nokia.com'" , Nakhjiri Madjid-MNAKHJI1 , kempf@docomolabs-usa.com, seamoby@ietf.org Subject: RE: [Seamoby] CARD between Routers - will CT do? Date: Tue, 14 Jan 2003 17:24:25 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Govind, I agree, the triggers are in general case different and I understand, you not wanting to rely on CT for your messaging. In fact I myself am in favor of not using FMIP or CT for your CARD protocol design to keep your hands open, but at same time, you need to keep the users options open. I personally will not use standalone CARD in my design (due to complexity). All I am saying is that carrying capability was something in fact I kept advocating in early days of CT (when CARD DT was called micromobility :) ) I guess this is a matter of taste, I think AR-specific capability signaling if not for assisting handovers can be part of network management that may be handled through specialized entities. This is especially inevitable when you are dealing with inter-admin domain cases (just as James was talking about different ISPs), this is a very important scenario. You can't just expect ISPs to let ARs spill their guts to other ISPs freely.... Madjid -----Original Message----- From: Govind.Krishnamurthi@nokia.com [mailto:Govind.Krishnamurthi@nokia.com] Sent: Tuesday, January 14, 2003 5:07 PM To: Madjid Nakhjiri; kempf@docomolabs-usa.com; seamoby@ietf.org Subject: RE: [Seamoby] CARD between Routers - will CT do? Madjid, My initial mail was because of the following reason. First, the triggers may be totally different. When I said around CT happens around handover time, as far as I remember these triggers for CT happened around handover time (I might be wrong here and I must accept its been sometime since I read the CT requirements/issues doc). If CT were to be the bearer for CARD capability discovery it should be adapted to accept CARD triggers. Thats all I meant. This can be done, but I don't know whether this exists. Though capability discovery is to find a good home for the MN, the capabilities in question pertain to ARs not MNs, thats what I meant by AR-specific and not MN-specific. Again, these are optmizations that Jim suggested. If the design team for CARD discovery comes with generic ICMP options for CARD for inter AR excahnges, it can be sent along with CT messaging, I don't deny it. I guess we will have to go through the same cycle of discussions as we had with FMIPv6 and CARD interaction. Cheers, Govind. -----Original Message----- From: ext Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] Sent: Tuesday, January 14, 2003 5:46 PM To: Krishnamurthi Govind (NRC/Boston); kempf@docomolabs-usa.com; seamoby@ietf.org Subject: RE: [Seamoby] CARD between Routers - will CT do? Govind, Jim, I am starting from the beginning of the thread, forgive me if this has been brought up in the following emails (I will know soon). Capability information was brought up early on as one legitimate type of information that can be handled by CT. I guess, this fell through the cracks somehow. As Jim said, CT is not limited to "during" handovers, we are considering pre-handover CTs as a scenario. CT does not have to be MN specific, we can certainly design it that way. But why is it not MN specific? Isn't capability discovery done to find a good home for a specific MN? If Capability discovery is just done for statistics/ network management purpose, then it can be handled in many different ways (including through a specialized entity). I can understand the CARD folks not wanting to make their protocol independent of CT signaling, but that does not prevent people from using CT to carry capability information. Regards, Madjid -----Original Message----- From: Govind.Krishnamurthi@nokia.com [mailto:Govind.Krishnamurthi@nokia.com] Sent: Monday, January 13, 2003 4:34 PM To: kempf@docomolabs-usa.com; seamoby@ietf.org Subject: RE: [Seamoby] CARD between Routers - will CT do? Hello James, I wouldn't want to tie it up with CT for the following reason. This information may be needed to refreshed at times other than that during handovers, which is when CT happens. Infact, this information is more important prior to the handover process. How does an AR discover any change in the AP configuration? I think this should be stored as soft state and should be refreshed min(when an AR knows of an AP configuration change, lifetime expiration). Also, right now, contexts are MN specific. This is not MN specific context. Let me know if I have misunderstood your comment. Thanks, Govind. -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Monday, January 13, 2003 4:58 PM To: seamoby@ietf.org Subject: [Seamoby] CARD between Routers - will CT do? So most of the discussion here has been about CARD between the Mobile Node and Access Router, and that's OK since it certainly is an important topic. However, equally important is how two Access Routers exchange information about the access points connected to them. This could be statically configured, but that would be very inconvenient. I'm wondering if this might be a good application of CT? The "context" here would be an authenticatable list of access points connected up to a particular router. Comments? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Jan 14 19:06:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16655 for ; Tue, 14 Jan 2003 19:06:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F0KSJ14637; Tue, 14 Jan 2003 19:20:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F0JCJ14553 for ; Tue, 14 Jan 2003 19:19:12 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16651 for ; Tue, 14 Jan 2003 19:04:20 -0500 (EST) Message-ID: <011701c2bc29$e4924f30$5c6015ac@T23KEMPF> From: "James Kempf" To: "Nakhjiri Madjid-MNAKHJI1" , "Eunsoo Shim" , References: <35DBB8B7AC89D4118E98009027B1009B08AD5C83@IL27EXM10.cig.mot.com> Subject: Re: [Seamoby] CARD between Routers - will CT do? Date: Tue, 14 Jan 2003 16:06:01 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > I can understand CARD people's concern about relying on CT, but > I also never understood, why TAR selection and address translation > should be done by one and same protocol. I thought in Atlanta we were > talking about separating the two? > I don't recall that the conclusion of the discussion was to separate. The concern I expressed there was involving more about the mobile node's preferences in the TAR decision. Specifically, that it could be inferred from the information provided by the CAR protocol, and that such information be extremely simple. For example, I don't think there is any need for a Turing complete language to describe preferences, nor should there be a complicated AAA interface to get the preferences there. Simple AVPs should be enough. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Jan 14 19:07:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16684 for ; Tue, 14 Jan 2003 19:07:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0F0LUc14667 for seamoby-archive@odin.ietf.org; Tue, 14 Jan 2003 19:21:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F0LUJ14664 for ; Tue, 14 Jan 2003 19:21:30 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16658 for ; Tue, 14 Jan 2003 19:06:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F0KSJ14637; Tue, 14 Jan 2003 19:20:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F0JCJ14553 for ; Tue, 14 Jan 2003 19:19:12 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16651 for ; Tue, 14 Jan 2003 19:04:20 -0500 (EST) Message-ID: <011701c2bc29$e4924f30$5c6015ac@T23KEMPF> From: "James Kempf" To: "Nakhjiri Madjid-MNAKHJI1" , "Eunsoo Shim" , References: <35DBB8B7AC89D4118E98009027B1009B08AD5C83@IL27EXM10.cig.mot.com> Subject: Re: [Seamoby] CARD between Routers - will CT do? Date: Tue, 14 Jan 2003 16:06:01 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I can understand CARD people's concern about relying on CT, but > I also never understood, why TAR selection and address translation > should be done by one and same protocol. I thought in Atlanta we were > talking about separating the two? > I don't recall that the conclusion of the discussion was to separate. The concern I expressed there was involving more about the mobile node's preferences in the TAR decision. Specifically, that it could be inferred from the information provided by the CAR protocol, and that such information be extremely simple. For example, I don't think there is any need for a Turing complete language to describe preferences, nor should there be a complicated AAA interface to get the preferences there. Simple AVPs should be enough. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Jan 15 09:59:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29103 for ; Wed, 15 Jan 2003 09:59:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FF8aJ16348; Wed, 15 Jan 2003 10:08:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FF7kJ16309 for ; Wed, 15 Jan 2003 10:07:46 -0500 Received: from bsn-mail-01.bstormnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28918 for ; Wed, 15 Jan 2003 09:52:34 -0500 (EST) Subject: RE: [Seamoby] CARD between Routers - will CT do? From: Pat Calhoun To: Hemant.Chaskar@nokia.com Cc: James Kempf , eunsoo@nec-lab.com, seamoby@ietf.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1042642544.3514.92.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 15 Jan 2003 06:55:44 -0800 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > The access routers are not border routers, they are internal > routers. BCP in the Internet today is to not expose such information to peering > ISPs. Are you proposing that we change this practice? > > Hemant --> I agree with you that CARD should not mess with Internet routing infrastructure. With Mobile IP, MN will know its old router and new router. Thus, information about their geographical adjacency is already exposed to third party. CARD should only be concerned about this information (however you distribute it and use it) without impacting routing infrastructure in any way. CARD is an edge phenomenon. > Doesn't this fly in the face of Mobile IPvx, which requires that internal topological information be known outside the AS? How else would foreign and home agents be contacted? How is this case different? PatC _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Jan 15 10:00:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29137 for ; Wed, 15 Jan 2003 10:00:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FFEn716612 for seamoby-archive@odin.ietf.org; Wed, 15 Jan 2003 10:14:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FFEnJ16609 for ; Wed, 15 Jan 2003 10:14:49 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29106 for ; Wed, 15 Jan 2003 09:59:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FF8aJ16348; Wed, 15 Jan 2003 10:08:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FF7kJ16309 for ; Wed, 15 Jan 2003 10:07:46 -0500 Received: from bsn-mail-01.bstormnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28918 for ; Wed, 15 Jan 2003 09:52:34 -0500 (EST) Subject: RE: [Seamoby] CARD between Routers - will CT do? From: Pat Calhoun To: Hemant.Chaskar@nokia.com Cc: James Kempf , eunsoo@nec-lab.com, seamoby@ietf.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1042642544.3514.92.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 15 Jan 2003 06:55:44 -0800 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > The access routers are not border routers, they are internal > routers. BCP in the Internet today is to not expose such information to peering > ISPs. Are you proposing that we change this practice? > > Hemant --> I agree with you that CARD should not mess with Internet routing infrastructure. With Mobile IP, MN will know its old router and new router. Thus, information about their geographical adjacency is already exposed to third party. CARD should only be concerned about this information (however you distribute it and use it) without impacting routing infrastructure in any way. CARD is an edge phenomenon. > Doesn't this fly in the face of Mobile IPvx, which requires that internal topological information be known outside the AS? How else would foreign and home agents be contacted? How is this case different? PatC _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Jan 15 11:19:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01783 for ; Wed, 15 Jan 2003 11:19:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGXIJ22530; Wed, 15 Jan 2003 11:33:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGR9J22075 for ; Wed, 15 Jan 2003 11:27:09 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01451 for ; Wed, 15 Jan 2003 11:11:57 -0500 (EST) Message-ID: <007c01c2bcb1$0dd91900$5c6015ac@T23KEMPF> From: "James Kempf" To: "Pat Calhoun" , Cc: , References: <1042642544.3514.92.camel@localhost.localdomain> Subject: Re: [Seamoby] CARD between Routers - will CT do? Date: Wed, 15 Jan 2003 08:13:34 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Pat, I assume you're talking about MIPv4, right? In that case, the HA sees the FA's address in the case where the MN sends the RegRqst via the FA instead of directly to the HA. Since the FA's address is also typically the care of address for the MN, the difference isn't all that great. The source address on the forwarded RegRqst will be the care of address, so it looks as if the RegRqst is coming from the MN. In MIPv6, this isn't a problem because there is no FA. jak ----- Original Message ----- From: "Pat Calhoun" To: Cc: "James Kempf" ; ; Sent: Wednesday, January 15, 2003 6:55 AM Subject: RE: [Seamoby] CARD between Routers - will CT do? > > The access routers are not border routers, they are internal > > routers. BCP in the Internet today is to not expose such information to peering > > ISPs. Are you proposing that we change this practice? > > > > Hemant --> I agree with you that CARD should not mess with Internet routing infrastructure. With Mobile IP, MN will know its old router and new router. Thus, information about their geographical adjacency is already exposed to third party. CARD should only be concerned about this information (however you distribute it and use it) without impacting routing infrastructure in any way. CARD is an edge phenomenon. > > > > Doesn't this fly in the face of Mobile IPvx, which requires that > internal topological information be known outside the AS? How else would > foreign and home agents be contacted? How is this case different? > > PatC > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Jan 15 11:19:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01828 for ; Wed, 15 Jan 2003 11:19:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FGYZI22674 for seamoby-archive@odin.ietf.org; Wed, 15 Jan 2003 11:34:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGYZJ22671 for ; Wed, 15 Jan 2003 11:34:35 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01786 for ; Wed, 15 Jan 2003 11:19:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGXIJ22530; Wed, 15 Jan 2003 11:33:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGR9J22075 for ; Wed, 15 Jan 2003 11:27:09 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01451 for ; Wed, 15 Jan 2003 11:11:57 -0500 (EST) Message-ID: <007c01c2bcb1$0dd91900$5c6015ac@T23KEMPF> From: "James Kempf" To: "Pat Calhoun" , Cc: , References: <1042642544.3514.92.camel@localhost.localdomain> Subject: Re: [Seamoby] CARD between Routers - will CT do? Date: Wed, 15 Jan 2003 08:13:34 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pat, I assume you're talking about MIPv4, right? In that case, the HA sees the FA's address in the case where the MN sends the RegRqst via the FA instead of directly to the HA. Since the FA's address is also typically the care of address for the MN, the difference isn't all that great. The source address on the forwarded RegRqst will be the care of address, so it looks as if the RegRqst is coming from the MN. In MIPv6, this isn't a problem because there is no FA. jak ----- Original Message ----- From: "Pat Calhoun" To: Cc: "James Kempf" ; ; Sent: Wednesday, January 15, 2003 6:55 AM Subject: RE: [Seamoby] CARD between Routers - will CT do? > > The access routers are not border routers, they are internal > > routers. BCP in the Internet today is to not expose such information to peering > > ISPs. Are you proposing that we change this practice? > > > > Hemant --> I agree with you that CARD should not mess with Internet routing infrastructure. With Mobile IP, MN will know its old router and new router. Thus, information about their geographical adjacency is already exposed to third party. CARD should only be concerned about this information (however you distribute it and use it) without impacting routing infrastructure in any way. CARD is an edge phenomenon. > > > > Doesn't this fly in the face of Mobile IPvx, which requires that > internal topological information be known outside the AS? How else would > foreign and home agents be contacted? How is this case different? > > PatC > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Jan 15 11:20:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01841 for ; Wed, 15 Jan 2003 11:20:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGY3J22593; Wed, 15 Jan 2003 11:34:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGVbJ22367 for ; Wed, 15 Jan 2003 11:31:37 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01648 for ; Wed, 15 Jan 2003 11:16:25 -0500 (EST) Message-ID: <008e01c2bcb1$b0b83250$5c6015ac@T23KEMPF> From: "James Kempf" To: , , References: Subject: Re: [Seamoby] CARD between Routers - will CT do? Date: Wed, 15 Jan 2003 08:18:06 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Hemant --> I agree with you that CARD should not mess with Internet routing infrastructure. With Mobile IP, MN will know its old router and new router. Thus, information about their geographical adjacency is already exposed to third party. CARD should only be concerned about this information (however you distribute it and use it) without impacting routing infrastructure in any way. CARD is an edge phenomenon. > The MN only knows the AP identifier, it doesn't know the router. For example, suppose I have an MN with an 802.11b card and two hotspot providers, in different ASs, are providing service in the airport I happen to be in: one does the United lounge and the other does the rest of the airport. If I am standing next to the United lounge and using the provider for the rest of the airport, my laptop may be able to see the BSSID for the United lounge but it won't know anything about the IP routing infrastructure, unless, of course, CARD or some other protocol tells it. Similarly, the routers in the other provider won't know anything about the routers in the United provider. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Jan 15 11:20:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01879 for ; Wed, 15 Jan 2003 11:20:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FGZFh22737 for seamoby-archive@odin.ietf.org; Wed, 15 Jan 2003 11:35:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGZFJ22734 for ; Wed, 15 Jan 2003 11:35:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01844 for ; Wed, 15 Jan 2003 11:20:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGY3J22593; Wed, 15 Jan 2003 11:34:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGVbJ22367 for ; Wed, 15 Jan 2003 11:31:37 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01648 for ; Wed, 15 Jan 2003 11:16:25 -0500 (EST) Message-ID: <008e01c2bcb1$b0b83250$5c6015ac@T23KEMPF> From: "James Kempf" To: , , References: Subject: Re: [Seamoby] CARD between Routers - will CT do? Date: Wed, 15 Jan 2003 08:18:06 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Hemant --> I agree with you that CARD should not mess with Internet routing infrastructure. With Mobile IP, MN will know its old router and new router. Thus, information about their geographical adjacency is already exposed to third party. CARD should only be concerned about this information (however you distribute it and use it) without impacting routing infrastructure in any way. CARD is an edge phenomenon. > The MN only knows the AP identifier, it doesn't know the router. For example, suppose I have an MN with an 802.11b card and two hotspot providers, in different ASs, are providing service in the airport I happen to be in: one does the United lounge and the other does the rest of the airport. If I am standing next to the United lounge and using the provider for the rest of the airport, my laptop may be able to see the BSSID for the United lounge but it won't know anything about the IP routing infrastructure, unless, of course, CARD or some other protocol tells it. Similarly, the routers in the other provider won't know anything about the routers in the United provider. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Jan 15 11:23:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01970 for ; Wed, 15 Jan 2003 11:23:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGc3J23587; Wed, 15 Jan 2003 11:38:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGbHJ23227 for ; Wed, 15 Jan 2003 11:37:17 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01946 for ; Wed, 15 Jan 2003 11:22:05 -0500 (EST) Message-ID: <009401c2bcb2$7b02b210$5c6015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , , References: <009801c2bc0b$c1be94f0$5c6015ac@T23KEMPF> <00bd01c2bc28$dbb45ee0$ea6b0f8a@eunsoo> Subject: Re: [Seamoby] CARD between Routers - will CT do? Date: Wed, 15 Jan 2003 08:23:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > If two ISPs are not willing to disclose even the IP addresses and the MAC > addresses of their access points and access routers to each other, well, the > dynamic discovery mechanism won't be used for inter-domain CAR discovery. > But they might do it for seamless roaming between the wireless networks of > theirs as a part of the roaming agreements and there can be business > benefits for them in doing that. So I'd suggest we look for technical > solutions even for inter-domain CAR discovery. > And intra-domain discovery of CARs is beneficial for the wireless ISPs > anyway since it reduces their management overhead. > > So I think inter-AR signaling for dynamic discovery should be under our > consideration. > How do you propose to authenticate this information? The current theory of how intra-domain CARD authentication works, if I understand correctly, is that the MN provides unauthenticated observations of AP identifiers that it can hear to the AR, and the AR then uses authenticated information obtained via Radius or perhap an inter-AR CARD protocol or static configuration about what APs are actually connected to the network, to deduce that the MN is telling the truth that the AP is an authorized AP (though the AR can't determine the truth of wireless connectivity this way). If we admit information from other ASs, then there needs to be some kind of inter-AS protocol for obtaining authenticated information about the internal topology of the other AS. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Jan 15 11:24:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02005 for ; Wed, 15 Jan 2003 11:24:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FGd3A23626 for seamoby-archive@odin.ietf.org; Wed, 15 Jan 2003 11:39:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGd2J23619 for ; Wed, 15 Jan 2003 11:39:02 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01973 for ; Wed, 15 Jan 2003 11:23:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGc3J23587; Wed, 15 Jan 2003 11:38:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGbHJ23227 for ; Wed, 15 Jan 2003 11:37:17 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01946 for ; Wed, 15 Jan 2003 11:22:05 -0500 (EST) Message-ID: <009401c2bcb2$7b02b210$5c6015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , , References: <009801c2bc0b$c1be94f0$5c6015ac@T23KEMPF> <00bd01c2bc28$dbb45ee0$ea6b0f8a@eunsoo> Subject: Re: [Seamoby] CARD between Routers - will CT do? Date: Wed, 15 Jan 2003 08:23:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > If two ISPs are not willing to disclose even the IP addresses and the MAC > addresses of their access points and access routers to each other, well, the > dynamic discovery mechanism won't be used for inter-domain CAR discovery. > But they might do it for seamless roaming between the wireless networks of > theirs as a part of the roaming agreements and there can be business > benefits for them in doing that. So I'd suggest we look for technical > solutions even for inter-domain CAR discovery. > And intra-domain discovery of CARs is beneficial for the wireless ISPs > anyway since it reduces their management overhead. > > So I think inter-AR signaling for dynamic discovery should be under our > consideration. > How do you propose to authenticate this information? The current theory of how intra-domain CARD authentication works, if I understand correctly, is that the MN provides unauthenticated observations of AP identifiers that it can hear to the AR, and the AR then uses authenticated information obtained via Radius or perhap an inter-AR CARD protocol or static configuration about what APs are actually connected to the network, to deduce that the MN is telling the truth that the AP is an authorized AP (though the AR can't determine the truth of wireless connectivity this way). If we admit information from other ASs, then there needs to be some kind of inter-AS protocol for obtaining authenticated information about the internal topology of the other AS. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Jan 15 11:24:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02018 for ; Wed, 15 Jan 2003 11:24:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGd3J23640; Wed, 15 Jan 2003 11:39:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGc4J23596 for ; Wed, 15 Jan 2003 11:38:04 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01956 for ; Wed, 15 Jan 2003 11:22:41 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0FGPkB16749 for ; Wed, 15 Jan 2003 10:25:57 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 15 Jan 2003 10:25:39 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 15 Jan 2003 08:25:38 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CARD between Routers - will CT do? Date: Wed, 15 Jan 2003 11:25:37 -0500 Message-ID: Thread-Topic: [Seamoby] CARD between Routers - will CT do? Thread-Index: AcK8sfDgONCD2Je7QH2C94ptgsG4MAAAIyIg To: , , X-OriginalArrivalTime: 15 Jan 2003 16:25:38.0912 (UTC) FILETIME=[BD7D9600:01C2BCB2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0FGc4J23597 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi James: In event of IP-layer handoff, at some point MN needs to know IP address of router it is going to connect to. So, MN will know IP address of new AR, latest after handoff. I am not sure if I understood your example below. Hemant -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Wednesday, January 15, 2003 11:18 AM To: Chaskar Hemant (NRC/Boston); eunsoo@nec-lab.com; seamoby@ietf.org Subject: Re: [Seamoby] CARD between Routers - will CT do? > Hemant --> I agree with you that CARD should not mess with Internet routing infrastructure. With Mobile IP, MN will know its old router and new router. Thus, information about their geographical adjacency is already exposed to third party. CARD should only be concerned about this information (however you distribute it and use it) without impacting routing infrastructure in any way. CARD is an edge phenomenon. > The MN only knows the AP identifier, it doesn't know the router. For example, suppose I have an MN with an 802.11b card and two hotspot providers, in different ASs, are providing service in the airport I happen to be in: one does the United lounge and the other does the rest of the airport. If I am standing next to the United lounge and using the provider for the rest of the airport, my laptop may be able to see the BSSID for the United lounge but it won't know anything about the IP routing infrastructure, unless, of course, CARD or some other protocol tells it. Similarly, the routers in the other provider won't know anything about the routers in the United provider. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Jan 15 11:25:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02045 for ; Wed, 15 Jan 2003 11:25:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FGe3c23700 for seamoby-archive@odin.ietf.org; Wed, 15 Jan 2003 11:40:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGe3J23697 for ; Wed, 15 Jan 2003 11:40:03 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02021 for ; Wed, 15 Jan 2003 11:24:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGd3J23640; Wed, 15 Jan 2003 11:39:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGc4J23596 for ; Wed, 15 Jan 2003 11:38:04 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01956 for ; Wed, 15 Jan 2003 11:22:41 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0FGPkB16749 for ; Wed, 15 Jan 2003 10:25:57 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 15 Jan 2003 10:25:39 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 15 Jan 2003 08:25:38 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CARD between Routers - will CT do? Date: Wed, 15 Jan 2003 11:25:37 -0500 Message-ID: Thread-Topic: [Seamoby] CARD between Routers - will CT do? Thread-Index: AcK8sfDgONCD2Je7QH2C94ptgsG4MAAAIyIg To: , , X-OriginalArrivalTime: 15 Jan 2003 16:25:38.0912 (UTC) FILETIME=[BD7D9600:01C2BCB2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0FGc4J23597 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi James: In event of IP-layer handoff, at some point MN needs to know IP address of router it is going to connect to. So, MN will know IP address of new AR, latest after handoff. I am not sure if I understood your example below. Hemant -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Wednesday, January 15, 2003 11:18 AM To: Chaskar Hemant (NRC/Boston); eunsoo@nec-lab.com; seamoby@ietf.org Subject: Re: [Seamoby] CARD between Routers - will CT do? > Hemant --> I agree with you that CARD should not mess with Internet routing infrastructure. With Mobile IP, MN will know its old router and new router. Thus, information about their geographical adjacency is already exposed to third party. CARD should only be concerned about this information (however you distribute it and use it) without impacting routing infrastructure in any way. CARD is an edge phenomenon. > The MN only knows the AP identifier, it doesn't know the router. For example, suppose I have an MN with an 802.11b card and two hotspot providers, in different ASs, are providing service in the airport I happen to be in: one does the United lounge and the other does the rest of the airport. If I am standing next to the United lounge and using the provider for the rest of the airport, my laptop may be able to see the BSSID for the United lounge but it won't know anything about the IP routing infrastructure, unless, of course, CARD or some other protocol tells it. Similarly, the routers in the other provider won't know anything about the routers in the United provider. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Jan 15 11:28:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02237 for ; Wed, 15 Jan 2003 11:28:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGh4J23839; Wed, 15 Jan 2003 11:43:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGgwJ23823 for ; Wed, 15 Jan 2003 11:42:58 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02185 for ; Wed, 15 Jan 2003 11:27:36 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0FGUlB18193 for ; Wed, 15 Jan 2003 10:30:57 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 15 Jan 2003 10:30:39 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 15 Jan 2003 08:30:32 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CARD between Routers - will CT do? Date: Wed, 15 Jan 2003 11:30:32 -0500 Message-ID: Thread-Topic: [Seamoby] CARD between Routers - will CT do? Thread-Index: AcK8srdPTO6KPBrzR5a2y/+/isNPmAAACIgQ To: , , X-OriginalArrivalTime: 15 Jan 2003 16:30:32.0898 (UTC) FILETIME=[6CB84A20:01C2BCB3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0FGgwJ23824 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi James: One comment below: -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Wednesday, January 15, 2003 11:24 AM To: Eunsoo Shim; Chaskar Hemant (NRC/Boston); seamoby@ietf.org Subject: Re: [Seamoby] CARD between Routers - will CT do? > If two ISPs are not willing to disclose even the IP addresses and the MAC > addresses of their access points and access routers to each other, well, the > dynamic discovery mechanism won't be used for inter-domain CAR discovery. > But they might do it for seamless roaming between the wireless networks of > theirs as a part of the roaming agreements and there can be business > benefits for them in doing that. So I'd suggest we look for technical > solutions even for inter-domain CAR discovery. > And intra-domain discovery of CARs is beneficial for the wireless ISPs > anyway since it reduces their management overhead. > > So I think inter-AR signaling for dynamic discovery should be under our > consideration. > How do you propose to authenticate this information? The current theory of how intra-domain CARD authentication works, if I understand correctly, is that the MN provides unauthenticated observations of AP identifiers that it can hear to the AR, and the AR then uses authenticated information obtained via Radius or perhap an inter-AR CARD protocol or static configuration about what APs are actually connected to the network, to deduce that the MN is telling the truth that the AP is an authorized AP (though the AR can't determine the truth of wireless connectivity this way). Hemant --> Yes, this will what happen at handoff time. Further, the truth of wireless connectivity can be obtained if MNs that undergo handoff before this MN upload this observation to their new ARs. The new AR of previous MN can then ask the old AR of previous MN if MN was indeed connected to old AR. If we admit information from other ASs, then there needs to be some kind of inter-AS protocol for obtaining authenticated information about the internal topology of the other AS. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Jan 15 11:29:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02286 for ; Wed, 15 Jan 2003 11:29:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FGi3j23901 for seamoby-archive@odin.ietf.org; Wed, 15 Jan 2003 11:44:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGi3J23898 for ; Wed, 15 Jan 2003 11:44:03 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02240 for ; Wed, 15 Jan 2003 11:28:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGh4J23839; Wed, 15 Jan 2003 11:43:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGgwJ23823 for ; Wed, 15 Jan 2003 11:42:58 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02185 for ; Wed, 15 Jan 2003 11:27:36 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0FGUlB18193 for ; Wed, 15 Jan 2003 10:30:57 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 15 Jan 2003 10:30:39 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 15 Jan 2003 08:30:32 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CARD between Routers - will CT do? Date: Wed, 15 Jan 2003 11:30:32 -0500 Message-ID: Thread-Topic: [Seamoby] CARD between Routers - will CT do? Thread-Index: AcK8srdPTO6KPBrzR5a2y/+/isNPmAAACIgQ To: , , X-OriginalArrivalTime: 15 Jan 2003 16:30:32.0898 (UTC) FILETIME=[6CB84A20:01C2BCB3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0FGgwJ23824 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi James: One comment below: -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Wednesday, January 15, 2003 11:24 AM To: Eunsoo Shim; Chaskar Hemant (NRC/Boston); seamoby@ietf.org Subject: Re: [Seamoby] CARD between Routers - will CT do? > If two ISPs are not willing to disclose even the IP addresses and the MAC > addresses of their access points and access routers to each other, well, the > dynamic discovery mechanism won't be used for inter-domain CAR discovery. > But they might do it for seamless roaming between the wireless networks of > theirs as a part of the roaming agreements and there can be business > benefits for them in doing that. So I'd suggest we look for technical > solutions even for inter-domain CAR discovery. > And intra-domain discovery of CARs is beneficial for the wireless ISPs > anyway since it reduces their management overhead. > > So I think inter-AR signaling for dynamic discovery should be under our > consideration. > How do you propose to authenticate this information? The current theory of how intra-domain CARD authentication works, if I understand correctly, is that the MN provides unauthenticated observations of AP identifiers that it can hear to the AR, and the AR then uses authenticated information obtained via Radius or perhap an inter-AR CARD protocol or static configuration about what APs are actually connected to the network, to deduce that the MN is telling the truth that the AP is an authorized AP (though the AR can't determine the truth of wireless connectivity this way). Hemant --> Yes, this will what happen at handoff time. Further, the truth of wireless connectivity can be obtained if MNs that undergo handoff before this MN upload this observation to their new ARs. The new AR of previous MN can then ask the old AR of previous MN if MN was indeed connected to old AR. If we admit information from other ASs, then there needs to be some kind of inter-AS protocol for obtaining authenticated information about the internal topology of the other AS. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Jan 15 11:32:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02499 for ; Wed, 15 Jan 2003 11:32:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGl3J24215; Wed, 15 Jan 2003 11:47:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGk7J24141 for ; Wed, 15 Jan 2003 11:46:07 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02422 for ; Wed, 15 Jan 2003 11:30:38 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0FGXmB19792 for ; Wed, 15 Jan 2003 10:33:58 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 15 Jan 2003 10:33:41 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 15 Jan 2003 08:33:18 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CARD between Routers - will CT do? Date: Wed, 15 Jan 2003 11:33:16 -0500 Message-ID: Thread-Topic: [Seamoby] CARD between Routers - will CT do? Thread-Index: AcK8sUzxzuaon8KFSly9zyd2H4aYCQAAkGpg To: , Cc: , X-OriginalArrivalTime: 15 Jan 2003 16:33:18.0305 (UTC) FILETIME=[CF4F6510:01C2BCB3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0FGk7J24142 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi James: Even in MIPv6, MN needs to interact with AR to obtain IP address, AAA purposes etc. Also, AR may need to create state for MN for say CT in event of handoff. Now if AR's IP address is revealed to MN (which is not operator owned), the information is already disclosed to external parties. So, why can't this information be provided to other routers. Hemant -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Wednesday, January 15, 2003 11:14 AM To: Pat Calhoun; Chaskar Hemant (NRC/Boston) Cc: eunsoo@nec-lab.com; seamoby@ietf.org Subject: Re: [Seamoby] CARD between Routers - will CT do? Pat, I assume you're talking about MIPv4, right? In that case, the HA sees the FA's address in the case where the MN sends the RegRqst via the FA instead of directly to the HA. Since the FA's address is also typically the care of address for the MN, the difference isn't all that great. The source address on the forwarded RegRqst will be the care of address, so it looks as if the RegRqst is coming from the MN. In MIPv6, this isn't a problem because there is no FA. jak ----- Original Message ----- From: "Pat Calhoun" To: Cc: "James Kempf" ; ; Sent: Wednesday, January 15, 2003 6:55 AM Subject: RE: [Seamoby] CARD between Routers - will CT do? > > The access routers are not border routers, they are internal > > routers. BCP in the Internet today is to not expose such information to peering > > ISPs. Are you proposing that we change this practice? > > > > Hemant --> I agree with you that CARD should not mess with Internet routing infrastructure. With Mobile IP, MN will know its old router and new router. Thus, information about their geographical adjacency is already exposed to third party. CARD should only be concerned about this information (however you distribute it and use it) without impacting routing infrastructure in any way. CARD is an edge phenomenon. > > > > Doesn't this fly in the face of Mobile IPvx, which requires that > internal topological information be known outside the AS? How else would > foreign and home agents be contacted? How is this case different? > > PatC > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Jan 15 11:33:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02544 for ; Wed, 15 Jan 2003 11:33:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FGm6A24321 for seamoby-archive@odin.ietf.org; Wed, 15 Jan 2003 11:48:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGm6J24318 for ; Wed, 15 Jan 2003 11:48:06 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02502 for ; Wed, 15 Jan 2003 11:32:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGl3J24215; Wed, 15 Jan 2003 11:47:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGk7J24141 for ; Wed, 15 Jan 2003 11:46:07 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02422 for ; Wed, 15 Jan 2003 11:30:38 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0FGXmB19792 for ; Wed, 15 Jan 2003 10:33:58 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 15 Jan 2003 10:33:41 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 15 Jan 2003 08:33:18 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CARD between Routers - will CT do? Date: Wed, 15 Jan 2003 11:33:16 -0500 Message-ID: Thread-Topic: [Seamoby] CARD between Routers - will CT do? Thread-Index: AcK8sUzxzuaon8KFSly9zyd2H4aYCQAAkGpg To: , Cc: , X-OriginalArrivalTime: 15 Jan 2003 16:33:18.0305 (UTC) FILETIME=[CF4F6510:01C2BCB3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0FGk7J24142 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi James: Even in MIPv6, MN needs to interact with AR to obtain IP address, AAA purposes etc. Also, AR may need to create state for MN for say CT in event of handoff. Now if AR's IP address is revealed to MN (which is not operator owned), the information is already disclosed to external parties. So, why can't this information be provided to other routers. Hemant -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Wednesday, January 15, 2003 11:14 AM To: Pat Calhoun; Chaskar Hemant (NRC/Boston) Cc: eunsoo@nec-lab.com; seamoby@ietf.org Subject: Re: [Seamoby] CARD between Routers - will CT do? Pat, I assume you're talking about MIPv4, right? In that case, the HA sees the FA's address in the case where the MN sends the RegRqst via the FA instead of directly to the HA. Since the FA's address is also typically the care of address for the MN, the difference isn't all that great. The source address on the forwarded RegRqst will be the care of address, so it looks as if the RegRqst is coming from the MN. In MIPv6, this isn't a problem because there is no FA. jak ----- Original Message ----- From: "Pat Calhoun" To: Cc: "James Kempf" ; ; Sent: Wednesday, January 15, 2003 6:55 AM Subject: RE: [Seamoby] CARD between Routers - will CT do? > > The access routers are not border routers, they are internal > > routers. BCP in the Internet today is to not expose such information to peering > > ISPs. Are you proposing that we change this practice? > > > > Hemant --> I agree with you that CARD should not mess with Internet routing infrastructure. With Mobile IP, MN will know its old router and new router. Thus, information about their geographical adjacency is already exposed to third party. CARD should only be concerned about this information (however you distribute it and use it) without impacting routing infrastructure in any way. CARD is an edge phenomenon. > > > > Doesn't this fly in the face of Mobile IPvx, which requires that > internal topological information be known outside the AS? How else would > foreign and home agents be contacted? How is this case different? > > PatC > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Jan 15 12:17:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03934 for ; Wed, 15 Jan 2003 12:17:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FHQcJ27186; Wed, 15 Jan 2003 12:26:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FHA9J26400 for ; Wed, 15 Jan 2003 12:10:09 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03144 for ; Wed, 15 Jan 2003 11:54:45 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0FGvuB24744 for ; Wed, 15 Jan 2003 10:58:07 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 15 Jan 2003 10:57:50 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 15 Jan 2003 08:56:55 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CARD between Routers - will CT do? Date: Wed, 15 Jan 2003 11:56:52 -0500 Message-ID: Thread-Topic: [Seamoby] CARD between Routers - will CT do? Thread-Index: AcK8sxI13vFYLqzBTES6rHzwqvk7kwAA0JYg To: , , , X-OriginalArrivalTime: 15 Jan 2003 16:56:55.0752 (UTC) FILETIME=[1C2CA480:01C2BCB7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0FHA9J26401 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit James, I agree that authenticating ARs in other domains is a difficult problem. For inter-domain handovers to happen, there needs to be some kind of an SLA that needs to exist. Can't we tag on some information in the SLA to authenticate routers in each other's domain? -Govind. -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Wednesday, January 15, 2003 11:24 AM To: Eunsoo Shim; Chaskar Hemant (NRC/Boston); seamoby@ietf.org Subject: Re: [Seamoby] CARD between Routers - will CT do? > If two ISPs are not willing to disclose even the IP addresses and the MAC > addresses of their access points and access routers to each other, well, the > dynamic discovery mechanism won't be used for inter-domain CAR discovery. > But they might do it for seamless roaming between the wireless networks of > theirs as a part of the roaming agreements and there can be business > benefits for them in doing that. So I'd suggest we look for technical > solutions even for inter-domain CAR discovery. > And intra-domain discovery of CARs is beneficial for the wireless ISPs > anyway since it reduces their management overhead. > > So I think inter-AR signaling for dynamic discovery should be under our > consideration. > How do you propose to authenticate this information? The current theory of how intra-domain CARD authentication works, if I understand correctly, is that the MN provides unauthenticated observations of AP identifiers that it can hear to the AR, and the AR then uses authenticated information obtained via Radius or perhap an inter-AR CARD protocol or static configuration about what APs are actually connected to the network, to deduce that the MN is telling the truth that the AP is an authorized AP (though the AR can't determine the truth of wireless connectivity this way). If we admit information from other ASs, then there needs to be some kind of inter-AS protocol for obtaining authenticated information about the internal topology of the other AS. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Jan 15 12:18:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03953 for ; Wed, 15 Jan 2003 12:18:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FHWpM27560 for seamoby-archive@odin.ietf.org; Wed, 15 Jan 2003 12:32:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FHWpJ27557 for ; Wed, 15 Jan 2003 12:32:51 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03937 for ; Wed, 15 Jan 2003 12:17:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FHQcJ27186; Wed, 15 Jan 2003 12:26:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FHA9J26400 for ; Wed, 15 Jan 2003 12:10:09 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03144 for ; Wed, 15 Jan 2003 11:54:45 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0FGvuB24744 for ; Wed, 15 Jan 2003 10:58:07 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 15 Jan 2003 10:57:50 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 15 Jan 2003 08:56:55 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CARD between Routers - will CT do? Date: Wed, 15 Jan 2003 11:56:52 -0500 Message-ID: Thread-Topic: [Seamoby] CARD between Routers - will CT do? Thread-Index: AcK8sxI13vFYLqzBTES6rHzwqvk7kwAA0JYg To: , , , X-OriginalArrivalTime: 15 Jan 2003 16:56:55.0752 (UTC) FILETIME=[1C2CA480:01C2BCB7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0FHA9J26401 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit James, I agree that authenticating ARs in other domains is a difficult problem. For inter-domain handovers to happen, there needs to be some kind of an SLA that needs to exist. Can't we tag on some information in the SLA to authenticate routers in each other's domain? -Govind. -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Wednesday, January 15, 2003 11:24 AM To: Eunsoo Shim; Chaskar Hemant (NRC/Boston); seamoby@ietf.org Subject: Re: [Seamoby] CARD between Routers - will CT do? > If two ISPs are not willing to disclose even the IP addresses and the MAC > addresses of their access points and access routers to each other, well, the > dynamic discovery mechanism won't be used for inter-domain CAR discovery. > But they might do it for seamless roaming between the wireless networks of > theirs as a part of the roaming agreements and there can be business > benefits for them in doing that. So I'd suggest we look for technical > solutions even for inter-domain CAR discovery. > And intra-domain discovery of CARs is beneficial for the wireless ISPs > anyway since it reduces their management overhead. > > So I think inter-AR signaling for dynamic discovery should be under our > consideration. > How do you propose to authenticate this information? The current theory of how intra-domain CARD authentication works, if I understand correctly, is that the MN provides unauthenticated observations of AP identifiers that it can hear to the AR, and the AR then uses authenticated information obtained via Radius or perhap an inter-AR CARD protocol or static configuration about what APs are actually connected to the network, to deduce that the MN is telling the truth that the AP is an authorized AP (though the AR can't determine the truth of wireless connectivity this way). If we admit information from other ASs, then there needs to be some kind of inter-AS protocol for obtaining authenticated information about the internal topology of the other AS. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Jan 15 16:17:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10349 for ; Wed, 15 Jan 2003 16:17:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FLWGJ10482; Wed, 15 Jan 2003 16:32:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FLU5J10341 for ; Wed, 15 Jan 2003 16:30:05 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10260 for ; Wed, 15 Jan 2003 16:14:46 -0500 (EST) Message-ID: <00fe01c2bcdb$5c9f2af0$5c6015ac@T23KEMPF> From: "James Kempf" To: , , References: Subject: Re: [Seamoby] CARD between Routers - will CT do? Date: Wed, 15 Jan 2003 13:16:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The MN only knows the other router after it has a link connection with the other ISP. And that typically requires the MN to negotiate an authentication exchange with the other ISP's NAS. In the example, the MN can hear the other ISP's AP layer 2 id, but, because it hasn't negotiated an authentication exchange, it cannot discover the address of the router. The router in the current ISP's network doesn't learn the other ISP's router at all. Anyway, I'm not saying necessarily that the topic of interprovider CARD should not be examined at some point, I just think that the problem is harder than intraprovider CARD, and so probably ought to wait. jak ----- Original Message ----- From: To: ; ; Sent: Wednesday, January 15, 2003 8:25 AM Subject: RE: [Seamoby] CARD between Routers - will CT do? > Hi James: > > In event of IP-layer handoff, at some point MN needs to know IP address of router it is going to connect to. So, MN will know IP address of new AR, latest after handoff. > > I am not sure if I understood your example below. > > Hemant > > -----Original Message----- > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Wednesday, January 15, 2003 11:18 AM > To: Chaskar Hemant (NRC/Boston); eunsoo@nec-lab.com; seamoby@ietf.org > Subject: Re: [Seamoby] CARD between Routers - will CT do? > > > > Hemant --> I agree with you that CARD should not mess with Internet routing > infrastructure. With Mobile IP, MN will know its old router and new router. > Thus, information about their geographical adjacency is already exposed to third > party. CARD should only be concerned about this information (however you > distribute it and use it) without impacting routing infrastructure in any way. > CARD is an edge phenomenon. > > > > The MN only knows the AP identifier, it doesn't know the router. > > For example, suppose I have an MN with an 802.11b card and two hotspot > providers, in different ASs, are providing service in the airport I happen to be > in: one does the United lounge and the other does the rest of the airport. If I > am standing next to the United lounge and using the provider for the rest of the > airport, my laptop may be able to see the BSSID for the United lounge but it > won't know anything about the IP routing infrastructure, unless, of course, CARD > or some other protocol tells it. Similarly, the routers in the other provider > won't know anything about the routers in the United provider. > > jak > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Jan 15 16:18:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10384 for ; Wed, 15 Jan 2003 16:18:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FLXKo10566 for seamoby-archive@odin.ietf.org; Wed, 15 Jan 2003 16:33:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FLXKJ10563 for ; Wed, 15 Jan 2003 16:33:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10363 for ; Wed, 15 Jan 2003 16:18:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FLWGJ10482; Wed, 15 Jan 2003 16:32:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FLU5J10341 for ; Wed, 15 Jan 2003 16:30:05 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10260 for ; Wed, 15 Jan 2003 16:14:46 -0500 (EST) Message-ID: <00fe01c2bcdb$5c9f2af0$5c6015ac@T23KEMPF> From: "James Kempf" To: , , References: Subject: Re: [Seamoby] CARD between Routers - will CT do? Date: Wed, 15 Jan 2003 13:16:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The MN only knows the other router after it has a link connection with the other ISP. And that typically requires the MN to negotiate an authentication exchange with the other ISP's NAS. In the example, the MN can hear the other ISP's AP layer 2 id, but, because it hasn't negotiated an authentication exchange, it cannot discover the address of the router. The router in the current ISP's network doesn't learn the other ISP's router at all. Anyway, I'm not saying necessarily that the topic of interprovider CARD should not be examined at some point, I just think that the problem is harder than intraprovider CARD, and so probably ought to wait. jak ----- Original Message ----- From: To: ; ; Sent: Wednesday, January 15, 2003 8:25 AM Subject: RE: [Seamoby] CARD between Routers - will CT do? > Hi James: > > In event of IP-layer handoff, at some point MN needs to know IP address of router it is going to connect to. So, MN will know IP address of new AR, latest after handoff. > > I am not sure if I understood your example below. > > Hemant > > -----Original Message----- > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Wednesday, January 15, 2003 11:18 AM > To: Chaskar Hemant (NRC/Boston); eunsoo@nec-lab.com; seamoby@ietf.org > Subject: Re: [Seamoby] CARD between Routers - will CT do? > > > > Hemant --> I agree with you that CARD should not mess with Internet routing > infrastructure. With Mobile IP, MN will know its old router and new router. > Thus, information about their geographical adjacency is already exposed to third > party. CARD should only be concerned about this information (however you > distribute it and use it) without impacting routing infrastructure in any way. > CARD is an edge phenomenon. > > > > The MN only knows the AP identifier, it doesn't know the router. > > For example, suppose I have an MN with an 802.11b card and two hotspot > providers, in different ASs, are providing service in the airport I happen to be > in: one does the United lounge and the other does the rest of the airport. If I > am standing next to the United lounge and using the provider for the rest of the > airport, my laptop may be able to see the BSSID for the United lounge but it > won't know anything about the IP routing infrastructure, unless, of course, CARD > or some other protocol tells it. Similarly, the routers in the other provider > won't know anything about the routers in the United provider. > > jak > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Jan 15 17:08:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11640 for ; Wed, 15 Jan 2003 17:08:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FMMOJ14315; Wed, 15 Jan 2003 17:22:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FMD3J13782 for ; Wed, 15 Jan 2003 17:13:03 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11277 for ; Wed, 15 Jan 2003 16:57:43 -0500 (EST) Received: from eunsoo ([138.15.107.234]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 15 Jan 2003 17:01:06 -0500 Message-ID: <014701c2bcfb$128cb660$ea6b0f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , , References: <00fe01c2bcdb$5c9f2af0$5c6015ac@T23KEMPF> Subject: Re: [Seamoby] CARD between Routers - will CT do? Date: Wed, 15 Jan 2003 17:03:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 15 Jan 2003 22:01:06.0153 (UTC) FILETIME=[9A42D590:01C2BCE1] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I certainly agree that the inter-provider CARD should be more tricky than the intra-provider CARD case. BTW, the example given by Hemant is the following in my understanding. "The MN hands over from an AR of an ISP to an AR of another ISP (inter-provider handoff). Then the MN can remember the IP address of the previous AR ( AR of the previous ISP) and inform it to the new AR (AR of the new ISP to which the MN is currently attached). So regardless of the willingness of the ISPs, the MN can distribute the IP addresses and L2 IDs of the ARs of one ISP to another ISP." Now the question is how the AR can verify the information delivered by the MN, in particular, about the ARs of a different ISP. That is the key security problem we have to tackle. And this is the question James asked me, I think. In the case the two ISPs are cooperative, the problem becomes similar to that of the intra-provider CARD. If not, well, then, each ISP should decide what to do. Since the IP address and the L2 IDs can be disclosed anyway, I think, the ISPs can get more benefits by cooperating with each other to verify the information delivered by the MN. So I'd suggest we work on the protocol design assuming/requiring the cooperation first. Eunsoo ----- Original Message ----- From: "James Kempf" To: ; ; Sent: Wednesday, January 15, 2003 1:16 PM Subject: Re: [Seamoby] CARD between Routers - will CT do? > The MN only knows the other router after it has a link connection with the other > ISP. And that typically requires the MN to negotiate an authentication exchange > with the other ISP's NAS. > > In the example, the MN can hear the other ISP's AP layer 2 id, but, because it > hasn't negotiated an authentication exchange, it cannot discover the address of > the router. > > The router in the current ISP's network doesn't learn the other ISP's router at > all. > > Anyway, I'm not saying necessarily that the topic of interprovider CARD should > not be examined at some point, I just think that the problem is harder than > intraprovider CARD, and so probably ought to wait. > > jak > > ----- Original Message ----- > From: > To: ; ; > Sent: Wednesday, January 15, 2003 8:25 AM > Subject: RE: [Seamoby] CARD between Routers - will CT do? > > > > Hi James: > > > > In event of IP-layer handoff, at some point MN needs to know IP address of > router it is going to connect to. So, MN will know IP address of new AR, latest > after handoff. > > > > I am not sure if I understood your example below. > > > > Hemant > > > > -----Original Message----- > > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: Wednesday, January 15, 2003 11:18 AM > > To: Chaskar Hemant (NRC/Boston); eunsoo@nec-lab.com; seamoby@ietf.org > > Subject: Re: [Seamoby] CARD between Routers - will CT do? > > > > > > > Hemant --> I agree with you that CARD should not mess with Internet routing > > infrastructure. With Mobile IP, MN will know its old router and new router. > > Thus, information about their geographical adjacency is already exposed to > third > > party. CARD should only be concerned about this information (however you > > distribute it and use it) without impacting routing infrastructure in any way. > > CARD is an edge phenomenon. > > > > > > > The MN only knows the AP identifier, it doesn't know the router. > > > > For example, suppose I have an MN with an 802.11b card and two hotspot > > providers, in different ASs, are providing service in the airport I happen to > be > > in: one does the United lounge and the other does the rest of the airport. If > I > > am standing next to the United lounge and using the provider for the rest of > the > > airport, my laptop may be able to see the BSSID for the United lounge but it > > won't know anything about the IP routing infrastructure, unless, of course, > CARD > > or some other protocol tells it. Similarly, the routers in the other provider > > won't know anything about the routers in the United provider. > > > > jak > > > > > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Jan 15 17:08:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11665 for ; Wed, 15 Jan 2003 17:08:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FMNRr14411 for seamoby-archive@odin.ietf.org; Wed, 15 Jan 2003 17:23:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FMNRJ14408 for ; Wed, 15 Jan 2003 17:23:27 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11655 for ; Wed, 15 Jan 2003 17:08:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FMMOJ14315; Wed, 15 Jan 2003 17:22:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FMD3J13782 for ; Wed, 15 Jan 2003 17:13:03 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11277 for ; Wed, 15 Jan 2003 16:57:43 -0500 (EST) Received: from eunsoo ([138.15.107.234]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 15 Jan 2003 17:01:06 -0500 Message-ID: <014701c2bcfb$128cb660$ea6b0f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , , References: <00fe01c2bcdb$5c9f2af0$5c6015ac@T23KEMPF> Subject: Re: [Seamoby] CARD between Routers - will CT do? Date: Wed, 15 Jan 2003 17:03:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 15 Jan 2003 22:01:06.0153 (UTC) FILETIME=[9A42D590:01C2BCE1] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I certainly agree that the inter-provider CARD should be more tricky than the intra-provider CARD case. BTW, the example given by Hemant is the following in my understanding. "The MN hands over from an AR of an ISP to an AR of another ISP (inter-provider handoff). Then the MN can remember the IP address of the previous AR ( AR of the previous ISP) and inform it to the new AR (AR of the new ISP to which the MN is currently attached). So regardless of the willingness of the ISPs, the MN can distribute the IP addresses and L2 IDs of the ARs of one ISP to another ISP." Now the question is how the AR can verify the information delivered by the MN, in particular, about the ARs of a different ISP. That is the key security problem we have to tackle. And this is the question James asked me, I think. In the case the two ISPs are cooperative, the problem becomes similar to that of the intra-provider CARD. If not, well, then, each ISP should decide what to do. Since the IP address and the L2 IDs can be disclosed anyway, I think, the ISPs can get more benefits by cooperating with each other to verify the information delivered by the MN. So I'd suggest we work on the protocol design assuming/requiring the cooperation first. Eunsoo ----- Original Message ----- From: "James Kempf" To: ; ; Sent: Wednesday, January 15, 2003 1:16 PM Subject: Re: [Seamoby] CARD between Routers - will CT do? > The MN only knows the other router after it has a link connection with the other > ISP. And that typically requires the MN to negotiate an authentication exchange > with the other ISP's NAS. > > In the example, the MN can hear the other ISP's AP layer 2 id, but, because it > hasn't negotiated an authentication exchange, it cannot discover the address of > the router. > > The router in the current ISP's network doesn't learn the other ISP's router at > all. > > Anyway, I'm not saying necessarily that the topic of interprovider CARD should > not be examined at some point, I just think that the problem is harder than > intraprovider CARD, and so probably ought to wait. > > jak > > ----- Original Message ----- > From: > To: ; ; > Sent: Wednesday, January 15, 2003 8:25 AM > Subject: RE: [Seamoby] CARD between Routers - will CT do? > > > > Hi James: > > > > In event of IP-layer handoff, at some point MN needs to know IP address of > router it is going to connect to. So, MN will know IP address of new AR, latest > after handoff. > > > > I am not sure if I understood your example below. > > > > Hemant > > > > -----Original Message----- > > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: Wednesday, January 15, 2003 11:18 AM > > To: Chaskar Hemant (NRC/Boston); eunsoo@nec-lab.com; seamoby@ietf.org > > Subject: Re: [Seamoby] CARD between Routers - will CT do? > > > > > > > Hemant --> I agree with you that CARD should not mess with Internet routing > > infrastructure. With Mobile IP, MN will know its old router and new router. > > Thus, information about their geographical adjacency is already exposed to > third > > party. CARD should only be concerned about this information (however you > > distribute it and use it) without impacting routing infrastructure in any way. > > CARD is an edge phenomenon. > > > > > > > The MN only knows the AP identifier, it doesn't know the router. > > > > For example, suppose I have an MN with an 802.11b card and two hotspot > > providers, in different ASs, are providing service in the airport I happen to > be > > in: one does the United lounge and the other does the rest of the airport. If > I > > am standing next to the United lounge and using the provider for the rest of > the > > airport, my laptop may be able to see the BSSID for the United lounge but it > > won't know anything about the IP routing infrastructure, unless, of course, > CARD > > or some other protocol tells it. Similarly, the routers in the other provider > > won't know anything about the routers in the United provider. > > > > jak > > > > > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Jan 15 17:22:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12182 for ; Wed, 15 Jan 2003 17:22:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FMaHJ15466; Wed, 15 Jan 2003 17:36:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FMZqJ15402 for ; Wed, 15 Jan 2003 17:35:52 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12118 for ; Wed, 15 Jan 2003 17:20:22 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0FMNEB12776 for ; Wed, 15 Jan 2003 16:23:25 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 15 Jan 2003 16:23:07 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 15 Jan 2003 14:22:23 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CARD between Routers - will CT do? Date: Wed, 15 Jan 2003 17:22:21 -0500 Message-ID: Thread-Topic: [Seamoby] CARD between Routers - will CT do? Thread-Index: AcK84aPxuVwcqyXSSQmeyI7GX5dxHgAAI//A To: , , X-OriginalArrivalTime: 15 Jan 2003 22:22:23.0104 (UTC) FILETIME=[93621800:01C2BCE4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0FMZqJ15403 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Eunsoo: See below. -----Original Message----- From: ext Eunsoo Shim [mailto:eunsoo@nec-lab.com] Sent: Wednesday, January 15, 2003 8:03 PM To: James Kempf; Chaskar Hemant (NRC/Boston); seamoby@ietf.org Subject: Re: [Seamoby] CARD between Routers - will CT do? I certainly agree that the inter-provider CARD should be more tricky than the intra-provider CARD case. BTW, the example given by Hemant is the following in my understanding. "The MN hands over from an AR of an ISP to an AR of another ISP (inter-provider handoff). Then the MN can remember the IP address of the previous AR ( AR of the previous ISP) and inform it to the new AR (AR of the new ISP to which the MN is currently attached). So regardless of the willingness of the ISPs, the MN can distribute the IP addresses and L2 IDs of the ARs of one ISP to another ISP." Hemant --> I agree. Now the question is how the AR can verify the information delivered by the MN, in particular, about the ARs of a different ISP. That is the key security problem we have to tackle. Hemant --> If ARs in two ISP domains have to co-operate, we may require some kind of handoff SLA between them. If that is given, then it is reasonable to assume that ARs in two ISP domains can establish SA between them. If ARs could establish SA between them (either because of same domain ownership or because of handoff SLA), one security measure could be that new AR asks old AR if MN was indeed attached to it in a reasonable past (say 1 s). If old AR says yes, new AR and old AR conclude that they are physical neighbors exchange IP address to L2 ID mapping info and continue to exchange capability info. The subsequent MNs handing off between them get seamless handoff experience. And this is the question James asked me, I think. Hemant --> I think we can start protocol design under the assumptions that (i) old and new ARs can establish SA between them, (ii) they are willing to participate in CARD protocol. Then, there may not be any need for intra-domain / inter-domain classification. Hemant In the case the two ISPs are cooperative, the problem becomes similar to that of the intra-provider CARD. If not, well, then, each ISP should decide what to do. Since the IP address and the L2 IDs can be disclosed anyway, I think, the ISPs can get more benefits by cooperating with each other to verify the information delivered by the MN. So I'd suggest we work on the protocol design assuming/requiring the cooperation first. Eunsoo ----- Original Message ----- From: "James Kempf" To: ; ; Sent: Wednesday, January 15, 2003 1:16 PM Subject: Re: [Seamoby] CARD between Routers - will CT do? > The MN only knows the other router after it has a link connection with the other > ISP. And that typically requires the MN to negotiate an authentication exchange > with the other ISP's NAS. > > In the example, the MN can hear the other ISP's AP layer 2 id, but, because it > hasn't negotiated an authentication exchange, it cannot discover the address of > the router. > > The router in the current ISP's network doesn't learn the other ISP's router at > all. > > Anyway, I'm not saying necessarily that the topic of interprovider CARD should > not be examined at some point, I just think that the problem is harder than > intraprovider CARD, and so probably ought to wait. > > jak > > ----- Original Message ----- > From: > To: ; ; > Sent: Wednesday, January 15, 2003 8:25 AM > Subject: RE: [Seamoby] CARD between Routers - will CT do? > > > > Hi James: > > > > In event of IP-layer handoff, at some point MN needs to know IP address of > router it is going to connect to. So, MN will know IP address of new AR, latest > after handoff. > > > > I am not sure if I understood your example below. > > > > Hemant > > > > -----Original Message----- > > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: Wednesday, January 15, 2003 11:18 AM > > To: Chaskar Hemant (NRC/Boston); eunsoo@nec-lab.com; seamoby@ietf.org > > Subject: Re: [Seamoby] CARD between Routers - will CT do? > > > > > > > Hemant --> I agree with you that CARD should not mess with Internet routing > > infrastructure. With Mobile IP, MN will know its old router and new router. > > Thus, information about their geographical adjacency is already exposed to > third > > party. CARD should only be concerned about this information (however you > > distribute it and use it) without impacting routing infrastructure in any way. > > CARD is an edge phenomenon. > > > > > > > The MN only knows the AP identifier, it doesn't know the router. > > > > For example, suppose I have an MN with an 802.11b card and two hotspot > > providers, in different ASs, are providing service in the airport I happen to > be > > in: one does the United lounge and the other does the rest of the airport. If > I > > am standing next to the United lounge and using the provider for the rest of > the > > airport, my laptop may be able to see the BSSID for the United lounge but it > > won't know anything about the IP routing infrastructure, unless, of course, > CARD > > or some other protocol tells it. Similarly, the routers in the other provider > > won't know anything about the routers in the United provider. > > > > jak > > > > > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Jan 15 17:22:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12239 for ; Wed, 15 Jan 2003 17:22:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FMbNO16033 for seamoby-archive@odin.ietf.org; Wed, 15 Jan 2003 17:37:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FMbNJ16022 for ; Wed, 15 Jan 2003 17:37:23 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12196 for ; Wed, 15 Jan 2003 17:22:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FMaHJ15466; Wed, 15 Jan 2003 17:36:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FMZqJ15402 for ; Wed, 15 Jan 2003 17:35:52 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12118 for ; Wed, 15 Jan 2003 17:20:22 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0FMNEB12776 for ; Wed, 15 Jan 2003 16:23:25 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 15 Jan 2003 16:23:07 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 15 Jan 2003 14:22:23 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CARD between Routers - will CT do? Date: Wed, 15 Jan 2003 17:22:21 -0500 Message-ID: Thread-Topic: [Seamoby] CARD between Routers - will CT do? Thread-Index: AcK84aPxuVwcqyXSSQmeyI7GX5dxHgAAI//A To: , , X-OriginalArrivalTime: 15 Jan 2003 22:22:23.0104 (UTC) FILETIME=[93621800:01C2BCE4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0FMZqJ15403 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Eunsoo: See below. -----Original Message----- From: ext Eunsoo Shim [mailto:eunsoo@nec-lab.com] Sent: Wednesday, January 15, 2003 8:03 PM To: James Kempf; Chaskar Hemant (NRC/Boston); seamoby@ietf.org Subject: Re: [Seamoby] CARD between Routers - will CT do? I certainly agree that the inter-provider CARD should be more tricky than the intra-provider CARD case. BTW, the example given by Hemant is the following in my understanding. "The MN hands over from an AR of an ISP to an AR of another ISP (inter-provider handoff). Then the MN can remember the IP address of the previous AR ( AR of the previous ISP) and inform it to the new AR (AR of the new ISP to which the MN is currently attached). So regardless of the willingness of the ISPs, the MN can distribute the IP addresses and L2 IDs of the ARs of one ISP to another ISP." Hemant --> I agree. Now the question is how the AR can verify the information delivered by the MN, in particular, about the ARs of a different ISP. That is the key security problem we have to tackle. Hemant --> If ARs in two ISP domains have to co-operate, we may require some kind of handoff SLA between them. If that is given, then it is reasonable to assume that ARs in two ISP domains can establish SA between them. If ARs could establish SA between them (either because of same domain ownership or because of handoff SLA), one security measure could be that new AR asks old AR if MN was indeed attached to it in a reasonable past (say 1 s). If old AR says yes, new AR and old AR conclude that they are physical neighbors exchange IP address to L2 ID mapping info and continue to exchange capability info. The subsequent MNs handing off between them get seamless handoff experience. And this is the question James asked me, I think. Hemant --> I think we can start protocol design under the assumptions that (i) old and new ARs can establish SA between them, (ii) they are willing to participate in CARD protocol. Then, there may not be any need for intra-domain / inter-domain classification. Hemant In the case the two ISPs are cooperative, the problem becomes similar to that of the intra-provider CARD. If not, well, then, each ISP should decide what to do. Since the IP address and the L2 IDs can be disclosed anyway, I think, the ISPs can get more benefits by cooperating with each other to verify the information delivered by the MN. So I'd suggest we work on the protocol design assuming/requiring the cooperation first. Eunsoo ----- Original Message ----- From: "James Kempf" To: ; ; Sent: Wednesday, January 15, 2003 1:16 PM Subject: Re: [Seamoby] CARD between Routers - will CT do? > The MN only knows the other router after it has a link connection with the other > ISP. And that typically requires the MN to negotiate an authentication exchange > with the other ISP's NAS. > > In the example, the MN can hear the other ISP's AP layer 2 id, but, because it > hasn't negotiated an authentication exchange, it cannot discover the address of > the router. > > The router in the current ISP's network doesn't learn the other ISP's router at > all. > > Anyway, I'm not saying necessarily that the topic of interprovider CARD should > not be examined at some point, I just think that the problem is harder than > intraprovider CARD, and so probably ought to wait. > > jak > > ----- Original Message ----- > From: > To: ; ; > Sent: Wednesday, January 15, 2003 8:25 AM > Subject: RE: [Seamoby] CARD between Routers - will CT do? > > > > Hi James: > > > > In event of IP-layer handoff, at some point MN needs to know IP address of > router it is going to connect to. So, MN will know IP address of new AR, latest > after handoff. > > > > I am not sure if I understood your example below. > > > > Hemant > > > > -----Original Message----- > > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: Wednesday, January 15, 2003 11:18 AM > > To: Chaskar Hemant (NRC/Boston); eunsoo@nec-lab.com; seamoby@ietf.org > > Subject: Re: [Seamoby] CARD between Routers - will CT do? > > > > > > > Hemant --> I agree with you that CARD should not mess with Internet routing > > infrastructure. With Mobile IP, MN will know its old router and new router. > > Thus, information about their geographical adjacency is already exposed to > third > > party. CARD should only be concerned about this information (however you > > distribute it and use it) without impacting routing infrastructure in any way. > > CARD is an edge phenomenon. > > > > > > > The MN only knows the AP identifier, it doesn't know the router. > > > > For example, suppose I have an MN with an 802.11b card and two hotspot > > providers, in different ASs, are providing service in the airport I happen to > be > > in: one does the United lounge and the other does the rest of the airport. If > I > > am standing next to the United lounge and using the provider for the rest of > the > > airport, my laptop may be able to see the BSSID for the United lounge but it > > won't know anything about the IP routing infrastructure, unless, of course, > CARD > > or some other protocol tells it. Similarly, the routers in the other provider > > won't know anything about the routers in the United provider. > > > > jak > > > > > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Jan 15 17:34:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12604 for ; Wed, 15 Jan 2003 17:34:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FMmMJ16901; Wed, 15 Jan 2003 17:48:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FMhHJ16580 for ; Wed, 15 Jan 2003 17:43:17 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12417 for ; Wed, 15 Jan 2003 17:27:58 -0500 (EST) Message-ID: <01aa01c2bce5$98128b40$5c6015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , , References: <00fe01c2bcdb$5c9f2af0$5c6015ac@T23KEMPF> <014701c2bcfb$128cb660$ea6b0f8a@eunsoo> Subject: Re: [Seamoby] CARD between Routers - will CT do? Date: Wed, 15 Jan 2003 14:29:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > In the case the two ISPs are cooperative, the problem becomes similar to > that of the intra-provider CARD. > If not, well, then, each ISP should decide what to do. > Since the IP address and the L2 IDs can be disclosed anyway, I think, the > ISPs can get more benefits by cooperating with each other to verify the > information delivered by the MN. So I'd suggest we work on the protocol > design assuming/requiring the cooperation first. > I don't think any interprovider transfer of topology information can assume co-operation. There need to be the correct security mechanisms in place. That said, I believe it might be possible to apply the intra-provider solution to the interprovider case by simply extending the intraprovider example based on, for example, standard AAA practice between two providers (this is just an example, other techniques might be better). So, I think getting a secure intra-provider CARD first, then looking at the inter-provider problem is the best course. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Jan 15 17:34:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12635 for ; Wed, 15 Jan 2003 17:34:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FMnPQ16992 for seamoby-archive@odin.ietf.org; Wed, 15 Jan 2003 17:49:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FMnOJ16989 for ; Wed, 15 Jan 2003 17:49:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12618 for ; Wed, 15 Jan 2003 17:34:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FMmMJ16901; Wed, 15 Jan 2003 17:48:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FMhHJ16580 for ; Wed, 15 Jan 2003 17:43:17 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12417 for ; Wed, 15 Jan 2003 17:27:58 -0500 (EST) Message-ID: <01aa01c2bce5$98128b40$5c6015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , , References: <00fe01c2bcdb$5c9f2af0$5c6015ac@T23KEMPF> <014701c2bcfb$128cb660$ea6b0f8a@eunsoo> Subject: Re: [Seamoby] CARD between Routers - will CT do? Date: Wed, 15 Jan 2003 14:29:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > In the case the two ISPs are cooperative, the problem becomes similar to > that of the intra-provider CARD. > If not, well, then, each ISP should decide what to do. > Since the IP address and the L2 IDs can be disclosed anyway, I think, the > ISPs can get more benefits by cooperating with each other to verify the > information delivered by the MN. So I'd suggest we work on the protocol > design assuming/requiring the cooperation first. > I don't think any interprovider transfer of topology information can assume co-operation. There need to be the correct security mechanisms in place. That said, I believe it might be possible to apply the intra-provider solution to the interprovider case by simply extending the intraprovider example based on, for example, standard AAA practice between two providers (this is just an example, other techniques might be better). So, I think getting a secure intra-provider CARD first, then looking at the inter-provider problem is the best course. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Jan 15 17:36:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12803 for ; Wed, 15 Jan 2003 17:36:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FMp4J17140; Wed, 15 Jan 2003 17:51:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FMo9J17055 for ; Wed, 15 Jan 2003 17:50:09 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12650 for ; Wed, 15 Jan 2003 17:34:50 -0500 (EST) Received: from eunsoo ([138.15.107.234]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 15 Jan 2003 17:38:11 -0500 Message-ID: <01c001c2bd00$40fac0a0$ea6b0f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , , References: <00fe01c2bcdb$5c9f2af0$5c6015ac@T23KEMPF> <014701c2bcfb$128cb660$ea6b0f8a@eunsoo> <01aa01c2bce5$98128b40$5c6015ac@T23KEMPF> Subject: Re: [Seamoby] CARD between Routers - will CT do? Date: Wed, 15 Jan 2003 17:40:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 15 Jan 2003 22:38:11.0690 (UTC) FILETIME=[C8C8D4A0:01C2BCE6] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > In the case the two ISPs are cooperative, the problem becomes similar to > > that of the intra-provider CARD. > > If not, well, then, each ISP should decide what to do. > > Since the IP address and the L2 IDs can be disclosed anyway, I think, the > > ISPs can get more benefits by cooperating with each other to verify the > > information delivered by the MN. So I'd suggest we work on the protocol > > design assuming/requiring the cooperation first. > > > > I don't think any interprovider transfer of topology information can assume > co-operation. There need to be the correct security mechanisms in place. > (eunsoo) I certainly agree that proper security mechanisms are required. I took it granted in my previous email. BTW, what the CARD protocol exchange between ARs is subset of the topology information of each domain since it deals with only ARs and BSs. Also it does not even tell how two ARs are connected in the wired network side even though it may reveal the IP subnets. So we should not think that CARD discloses the whole network topology of one administrative domain to another domain. I'd say it discloses only what MN can figure out regarding the topology. > That said, I believe it might be possible to apply the intra-provider solution > to the interprovider case by simply extending the intraprovider example based > on, for example, standard AAA practice between two providers (this is just an > example, other techniques might be better). > > So, I think getting a secure intra-provider CARD first, then looking at the > inter-provider problem is the best course. > (eunsoo) Good idea! Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Jan 15 17:37:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12845 for ; Wed, 15 Jan 2003 17:37:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FMq1817238 for seamoby-archive@odin.ietf.org; Wed, 15 Jan 2003 17:52:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FMq1J17235 for ; Wed, 15 Jan 2003 17:52:01 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12817 for ; Wed, 15 Jan 2003 17:36:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FMp4J17140; Wed, 15 Jan 2003 17:51:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FMo9J17055 for ; Wed, 15 Jan 2003 17:50:09 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12650 for ; Wed, 15 Jan 2003 17:34:50 -0500 (EST) Received: from eunsoo ([138.15.107.234]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 15 Jan 2003 17:38:11 -0500 Message-ID: <01c001c2bd00$40fac0a0$ea6b0f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , , References: <00fe01c2bcdb$5c9f2af0$5c6015ac@T23KEMPF> <014701c2bcfb$128cb660$ea6b0f8a@eunsoo> <01aa01c2bce5$98128b40$5c6015ac@T23KEMPF> Subject: Re: [Seamoby] CARD between Routers - will CT do? Date: Wed, 15 Jan 2003 17:40:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 15 Jan 2003 22:38:11.0690 (UTC) FILETIME=[C8C8D4A0:01C2BCE6] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > In the case the two ISPs are cooperative, the problem becomes similar to > > that of the intra-provider CARD. > > If not, well, then, each ISP should decide what to do. > > Since the IP address and the L2 IDs can be disclosed anyway, I think, the > > ISPs can get more benefits by cooperating with each other to verify the > > information delivered by the MN. So I'd suggest we work on the protocol > > design assuming/requiring the cooperation first. > > > > I don't think any interprovider transfer of topology information can assume > co-operation. There need to be the correct security mechanisms in place. > (eunsoo) I certainly agree that proper security mechanisms are required. I took it granted in my previous email. BTW, what the CARD protocol exchange between ARs is subset of the topology information of each domain since it deals with only ARs and BSs. Also it does not even tell how two ARs are connected in the wired network side even though it may reveal the IP subnets. So we should not think that CARD discloses the whole network topology of one administrative domain to another domain. I'd say it discloses only what MN can figure out regarding the topology. > That said, I believe it might be possible to apply the intra-provider solution > to the interprovider case by simply extending the intraprovider example based > on, for example, standard AAA practice between two providers (this is just an > example, other techniques might be better). > > So, I think getting a secure intra-provider CARD first, then looking at the > inter-provider problem is the best course. > (eunsoo) Good idea! Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Jan 15 17:40:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12968 for ; Wed, 15 Jan 2003 17:40:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FMt6J17512; Wed, 15 Jan 2003 17:55:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FMsUJ17440 for ; Wed, 15 Jan 2003 17:54:30 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12910 for ; Wed, 15 Jan 2003 17:39:00 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0FMgCB17455 for ; Wed, 15 Jan 2003 16:42:22 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 15 Jan 2003 16:42:03 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 15 Jan 2003 16:42:02 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CARD between Routers - will CT do? Date: Wed, 15 Jan 2003 17:42:01 -0500 Message-ID: Thread-Topic: [Seamoby] CARD between Routers - will CT do? Thread-Index: AcK85dRSET9TPgYyRPyBH9zGBid0twAAM30A To: , , X-OriginalArrivalTime: 15 Jan 2003 22:42:02.0855 (UTC) FILETIME=[5291CF70:01C2BCE7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0FMsUJ17441 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi James: See comments below: -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Wednesday, January 15, 2003 5:30 PM To: Eunsoo Shim; Chaskar Hemant (NRC/Boston); seamoby@ietf.org Subject: Re: [Seamoby] CARD between Routers - will CT do? > In the case the two ISPs are cooperative, the problem becomes similar to > that of the intra-provider CARD. > If not, well, then, each ISP should decide what to do. > Since the IP address and the L2 IDs can be disclosed anyway, I think, the > ISPs can get more benefits by cooperating with each other to verify the > information delivered by the MN. So I'd suggest we work on the protocol > design assuming/requiring the cooperation first. > I don't think any interprovider transfer of topology information can assume co-operation. There need to be the correct security mechanisms in place. That said, I believe it might be possible to apply the intra-provider solution to the interprovider case by simply extending the intraprovider example based on, for example, standard AAA practice between two providers (this is just an example, other techniques might be better). Hemant --> Agree. So, I think getting a secure intra-provider CARD first, then looking at the inter-provider problem is the best course. Hemant --> What we need is prerequisite that (i) ARs can establish SA between them, and (ii) are willing to participate in CARD. Then, distinction between intra provider CARD and inter provider CARD may not be needed. The pre-requisite is easily satisfied for intra case and can be satisfied for inter case by some means you describe above. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Jan 15 17:41:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13006 for ; Wed, 15 Jan 2003 17:41:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FMu7W17626 for seamoby-archive@odin.ietf.org; Wed, 15 Jan 2003 17:56:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FMu7J17623 for ; Wed, 15 Jan 2003 17:56:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12982 for ; Wed, 15 Jan 2003 17:40:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FMt6J17512; Wed, 15 Jan 2003 17:55:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FMsUJ17440 for ; Wed, 15 Jan 2003 17:54:30 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12910 for ; Wed, 15 Jan 2003 17:39:00 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0FMgCB17455 for ; Wed, 15 Jan 2003 16:42:22 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 15 Jan 2003 16:42:03 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 15 Jan 2003 16:42:02 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CARD between Routers - will CT do? Date: Wed, 15 Jan 2003 17:42:01 -0500 Message-ID: Thread-Topic: [Seamoby] CARD between Routers - will CT do? Thread-Index: AcK85dRSET9TPgYyRPyBH9zGBid0twAAM30A To: , , X-OriginalArrivalTime: 15 Jan 2003 22:42:02.0855 (UTC) FILETIME=[5291CF70:01C2BCE7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0FMsUJ17441 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi James: See comments below: -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Wednesday, January 15, 2003 5:30 PM To: Eunsoo Shim; Chaskar Hemant (NRC/Boston); seamoby@ietf.org Subject: Re: [Seamoby] CARD between Routers - will CT do? > In the case the two ISPs are cooperative, the problem becomes similar to > that of the intra-provider CARD. > If not, well, then, each ISP should decide what to do. > Since the IP address and the L2 IDs can be disclosed anyway, I think, the > ISPs can get more benefits by cooperating with each other to verify the > information delivered by the MN. So I'd suggest we work on the protocol > design assuming/requiring the cooperation first. > I don't think any interprovider transfer of topology information can assume co-operation. There need to be the correct security mechanisms in place. That said, I believe it might be possible to apply the intra-provider solution to the interprovider case by simply extending the intraprovider example based on, for example, standard AAA practice between two providers (this is just an example, other techniques might be better). Hemant --> Agree. So, I think getting a secure intra-provider CARD first, then looking at the inter-provider problem is the best course. Hemant --> What we need is prerequisite that (i) ARs can establish SA between them, and (ii) are willing to participate in CARD. Then, distinction between intra provider CARD and inter provider CARD may not be needed. The pre-requisite is easily satisfied for intra case and can be satisfied for inter case by some means you describe above. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Jan 15 18:08:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13888 for ; Wed, 15 Jan 2003 18:08:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FNMXJ19624; Wed, 15 Jan 2003 18:22:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FNJoJ19399 for ; Wed, 15 Jan 2003 18:19:50 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13695 for ; Wed, 15 Jan 2003 18:04:14 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0FN7PB22238 for ; Wed, 15 Jan 2003 17:07:36 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 15 Jan 2003 17:07:13 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 15 Jan 2003 17:06:46 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CARD between Routers - will CT do? Date: Wed, 15 Jan 2003 18:06:45 -0500 Message-ID: Thread-Topic: [Seamoby] CARD between Routers - will CT do? Thread-Index: AcK85pWAOYHF2//tRbOY3iSxFV+mcAAAvE2g To: , , , X-OriginalArrivalTime: 15 Jan 2003 23:06:46.0802 (UTC) FILETIME=[C7122720:01C2BCEA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0FNJoJ19400 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Jim, I think this point was brought out in the last IETF too. The main criteria to have inter-AR exchange (be it intra domain or inter domain) is the presence of a SA between them. If a SA exists, then there is no difference between inter domain and intra domain. You have pointed out some ways to establish an inter domain SA. Other ways using existing SLAs may be possible too. I think all we should do is should put the establishment of SAs as the pre-requisite for any inter AR exchange. Once this SA is established then inter-AR exchange can proceed. What do you think? -Govind. -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Wednesday, January 15, 2003 5:30 PM To: Eunsoo Shim; Chaskar Hemant (NRC/Boston); seamoby@ietf.org Subject: Re: [Seamoby] CARD between Routers - will CT do? > In the case the two ISPs are cooperative, the problem becomes similar to > that of the intra-provider CARD. > If not, well, then, each ISP should decide what to do. > Since the IP address and the L2 IDs can be disclosed anyway, I think, the > ISPs can get more benefits by cooperating with each other to verify the > information delivered by the MN. So I'd suggest we work on the protocol > design assuming/requiring the cooperation first. > I don't think any interprovider transfer of topology information can assume co-operation. There need to be the correct security mechanisms in place. That said, I believe it might be possible to apply the intra-provider solution to the interprovider case by simply extending the intraprovider example based on, for example, standard AAA practice between two providers (this is just an example, other techniques might be better). So, I think getting a secure intra-provider CARD first, then looking at the inter-provider problem is the best course. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Jan 15 18:09:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13915 for ; Wed, 15 Jan 2003 18:09:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FNOGZ19767 for seamoby-archive@odin.ietf.org; Wed, 15 Jan 2003 18:24:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FNOGJ19764 for ; Wed, 15 Jan 2003 18:24:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13902 for ; Wed, 15 Jan 2003 18:08:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FNMXJ19624; Wed, 15 Jan 2003 18:22:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FNJoJ19399 for ; Wed, 15 Jan 2003 18:19:50 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13695 for ; Wed, 15 Jan 2003 18:04:14 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0FN7PB22238 for ; Wed, 15 Jan 2003 17:07:36 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 15 Jan 2003 17:07:13 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 15 Jan 2003 17:06:46 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CARD between Routers - will CT do? Date: Wed, 15 Jan 2003 18:06:45 -0500 Message-ID: Thread-Topic: [Seamoby] CARD between Routers - will CT do? Thread-Index: AcK85pWAOYHF2//tRbOY3iSxFV+mcAAAvE2g To: , , , X-OriginalArrivalTime: 15 Jan 2003 23:06:46.0802 (UTC) FILETIME=[C7122720:01C2BCEA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0FNJoJ19400 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Jim, I think this point was brought out in the last IETF too. The main criteria to have inter-AR exchange (be it intra domain or inter domain) is the presence of a SA between them. If a SA exists, then there is no difference between inter domain and intra domain. You have pointed out some ways to establish an inter domain SA. Other ways using existing SLAs may be possible too. I think all we should do is should put the establishment of SAs as the pre-requisite for any inter AR exchange. Once this SA is established then inter-AR exchange can proceed. What do you think? -Govind. -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Wednesday, January 15, 2003 5:30 PM To: Eunsoo Shim; Chaskar Hemant (NRC/Boston); seamoby@ietf.org Subject: Re: [Seamoby] CARD between Routers - will CT do? > In the case the two ISPs are cooperative, the problem becomes similar to > that of the intra-provider CARD. > If not, well, then, each ISP should decide what to do. > Since the IP address and the L2 IDs can be disclosed anyway, I think, the > ISPs can get more benefits by cooperating with each other to verify the > information delivered by the MN. So I'd suggest we work on the protocol > design assuming/requiring the cooperation first. > I don't think any interprovider transfer of topology information can assume co-operation. There need to be the correct security mechanisms in place. That said, I believe it might be possible to apply the intra-provider solution to the interprovider case by simply extending the intraprovider example based on, for example, standard AAA practice between two providers (this is just an example, other techniques might be better). So, I think getting a secure intra-provider CARD first, then looking at the inter-provider problem is the best course. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Jan 15 22:19:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19354 for ; Wed, 15 Jan 2003 22:19:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G3XjJ04141; Wed, 15 Jan 2003 22:33:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G3OKJ03821 for ; Wed, 15 Jan 2003 22:24:20 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19189 for ; Wed, 15 Jan 2003 22:08:54 -0500 (EST) Date: Wed, 15 Jan 2003 19:10:15 -0800 From: Daichi Funato To: Hemant.Chaskar@nokia.com Subject: Re: [Seamoby] CARD between Routers - will CT do? Cc: , , In-Reply-To: References: Message-Id: <20030115190628.65B6.FUNATO@docomolabs-usa.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Hemant, > Hemant --> I think we can start protocol design under the assumptions that > (i) old and new ARs can establish SA between them, (ii) they are willing to > participate in CARD protocol. Then, there may not be any need for intra-domain > / inter-domain classification. What kind of security mechanisms are you assuming? I think we should not leave the security mechanisms out of the scope. Especially, MN-report-based CARD is vulnerable to an attacker. How to protect the communication is an essential part of CARD, I think. Actually, IEEE IAPP includes a security mechanism by itself. Do we neglect that part in CARD? IMHO, if CARD can provide secure keys for ARs, these can be used by CT and FMIP as well. This is another type of capability discovery. What do you think? Best regards, Daichi ------------------------------------------------------------- Daichi Funato DoCoMo Communications Laboratories USA, Inc. Confidential Note: Privileged/Confidential Information may be contained in this e-mail and any attachment to it. Unless you are the addressee indicated in this e-mail, please notify immediately the sender by reply e-mail that you have received this in error and delete it from your system. You may not use, copy or deliver this e-mail or any information contained in this e-mail to anyone. Thank you very much. ------------------------------------------------------------- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Jan 15 22:20:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19379 for ; Wed, 15 Jan 2003 22:20:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0G3YwN04228 for seamoby-archive@odin.ietf.org; Wed, 15 Jan 2003 22:34:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G3YvJ04225 for ; Wed, 15 Jan 2003 22:34:57 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19372 for ; Wed, 15 Jan 2003 22:19:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G3XjJ04141; Wed, 15 Jan 2003 22:33:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G3OKJ03821 for ; Wed, 15 Jan 2003 22:24:20 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19189 for ; Wed, 15 Jan 2003 22:08:54 -0500 (EST) Date: Wed, 15 Jan 2003 19:10:15 -0800 From: Daichi Funato To: Hemant.Chaskar@nokia.com Subject: Re: [Seamoby] CARD between Routers - will CT do? Cc: , , In-Reply-To: References: Message-Id: <20030115190628.65B6.FUNATO@docomolabs-usa.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Hemant, > Hemant --> I think we can start protocol design under the assumptions that > (i) old and new ARs can establish SA between them, (ii) they are willing to > participate in CARD protocol. Then, there may not be any need for intra-domain > / inter-domain classification. What kind of security mechanisms are you assuming? I think we should not leave the security mechanisms out of the scope. Especially, MN-report-based CARD is vulnerable to an attacker. How to protect the communication is an essential part of CARD, I think. Actually, IEEE IAPP includes a security mechanism by itself. Do we neglect that part in CARD? IMHO, if CARD can provide secure keys for ARs, these can be used by CT and FMIP as well. This is another type of capability discovery. What do you think? Best regards, Daichi ------------------------------------------------------------- Daichi Funato DoCoMo Communications Laboratories USA, Inc. Confidential Note: Privileged/Confidential Information may be contained in this e-mail and any attachment to it. Unless you are the addressee indicated in this e-mail, please notify immediately the sender by reply e-mail that you have received this in error and delete it from your system. You may not use, copy or deliver this e-mail or any information contained in this e-mail to anyone. Thank you very much. ------------------------------------------------------------- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Jan 15 23:23:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20361 for ; Wed, 15 Jan 2003 23:23:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G4bQJ08164; Wed, 15 Jan 2003 23:37:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G4aVJ07476 for ; Wed, 15 Jan 2003 23:36:31 -0500 Received: from hotmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20338 for ; Wed, 15 Jan 2003 23:21:04 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 15 Jan 2003 20:24:24 -0800 Received: from 66.30.240.206 by lw7fd.law7.hotmail.msn.com with HTTP; Thu, 16 Jan 2003 04:24:23 GMT X-Originating-IP: [66.30.240.206] From: "Hemant Chaskar" To: funato@docomolabs-usa.com, Hemant.Chaskar@nokia.com Cc: eunsoo@nec-lab.com, kempf@docomolabs-usa.com, seamoby@ietf.org Subject: Re: [Seamoby] CARD between Routers - will CT do? Date: Thu, 16 Jan 2003 04:24:23 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 16 Jan 2003 04:24:24.0311 (UTC) FILETIME=[263B4070:01C2BD17] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Hi Daichi: I do not think that establishment of SA between ARs should be within scope of CARD. We should start from pre-requisite that SA can be established between ARs. When ARs belong to same domain, this is simple. When they belong to different domain it is harder. In either case, there can be variety of ways to establish SAs - pre-shared key, domain specific certificates, AAA, credentials exchanged during SLAs or any other means. Why should CARD put any restriction on mechanism used to establish SA? So, instead of <--Interworking--> | Intra-domain CARD | Inter-domain CARD protocol | protocol --------------------|------------------------------ Intra-domain SA | Inter-domain SA mechanism | mechanism (CARD specific?) | (CARD specific?) I am saying that, if possible, we should try, CARD protocol ---------------------------------------------- | Intra-domain SA | Inter-domain SA mechanisms | mechanisms current/future best | (current/future best practices) | practices) At this point, I cannot vouch for security of MN-report-based CARD approach. But, could you describe what kind of attacks do you think MN-report-based CARD is vulnerable to? In draft-trossen-seamoby-dycard-00.txt, we have shown that certain simple mechanisms can foil security attacks in MN-report-based CARD (To the least, if MN tells new AR arbitrary IP address as address of old AR, it can be detected). Also, the side effect of attacks, if any, does not adversely affect good MNs. But, of course, we could have missed some attack possibilities. Hemant >From: Daichi Funato >To: Hemant.Chaskar@nokia.com >CC: , , >Subject: Re: [Seamoby] CARD between Routers - will CT do? >Date: Wed, 15 Jan 2003 19:10:15 -0800 > >Hi Hemant, > > > Hemant --> I think we can start protocol design under the assumptions >that > > (i) old and new ARs can establish SA between them, (ii) they are willing >to > > participate in CARD protocol. Then, there may not be any need for >intra-domain > > / inter-domain classification. > >What kind of security mechanisms are you assuming? >I think we should not leave the security mechanisms out of the scope. > >Especially, MN-report-based CARD is vulnerable to an attacker. >How to protect the communication is an essential part of CARD, I think. >Actually, IEEE IAPP includes a security mechanism by itself. >Do we neglect that part in CARD? > >IMHO, if CARD can provide secure keys for ARs, these can be used by CT >and FMIP as well. This is another type of capability discovery. >What do you think? > >Best regards, >Daichi > >------------------------------------------------------------- >Daichi Funato >DoCoMo Communications Laboratories USA, Inc. > >Confidential Note: >Privileged/Confidential Information may be contained in this e-mail >and any attachment to it. Unless you are the addressee indicated in >this e-mail, please notify immediately the sender by reply e-mail >that you have received this in error and delete it from your system. >You may not use, copy or deliver this e-mail or any information >contained in this e-mail to anyone. Thank you very much. >------------------------------------------------------------- > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Jan 15 23:23:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20401 for ; Wed, 15 Jan 2003 23:23:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0G4cbh08224 for seamoby-archive@odin.ietf.org; Wed, 15 Jan 2003 23:38:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G4cbJ08221 for ; Wed, 15 Jan 2003 23:38:37 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20388 for ; Wed, 15 Jan 2003 23:23:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G4bQJ08164; Wed, 15 Jan 2003 23:37:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G4aVJ07476 for ; Wed, 15 Jan 2003 23:36:31 -0500 Received: from hotmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20338 for ; Wed, 15 Jan 2003 23:21:04 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 15 Jan 2003 20:24:24 -0800 Received: from 66.30.240.206 by lw7fd.law7.hotmail.msn.com with HTTP; Thu, 16 Jan 2003 04:24:23 GMT X-Originating-IP: [66.30.240.206] From: "Hemant Chaskar" To: funato@docomolabs-usa.com, Hemant.Chaskar@nokia.com Cc: eunsoo@nec-lab.com, kempf@docomolabs-usa.com, seamoby@ietf.org Subject: Re: [Seamoby] CARD between Routers - will CT do? Date: Thu, 16 Jan 2003 04:24:23 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 16 Jan 2003 04:24:24.0311 (UTC) FILETIME=[263B4070:01C2BD17] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Hi Daichi: I do not think that establishment of SA between ARs should be within scope of CARD. We should start from pre-requisite that SA can be established between ARs. When ARs belong to same domain, this is simple. When they belong to different domain it is harder. In either case, there can be variety of ways to establish SAs - pre-shared key, domain specific certificates, AAA, credentials exchanged during SLAs or any other means. Why should CARD put any restriction on mechanism used to establish SA? So, instead of <--Interworking--> | Intra-domain CARD | Inter-domain CARD protocol | protocol --------------------|------------------------------ Intra-domain SA | Inter-domain SA mechanism | mechanism (CARD specific?) | (CARD specific?) I am saying that, if possible, we should try, CARD protocol ---------------------------------------------- | Intra-domain SA | Inter-domain SA mechanisms | mechanisms current/future best | (current/future best practices) | practices) At this point, I cannot vouch for security of MN-report-based CARD approach. But, could you describe what kind of attacks do you think MN-report-based CARD is vulnerable to? In draft-trossen-seamoby-dycard-00.txt, we have shown that certain simple mechanisms can foil security attacks in MN-report-based CARD (To the least, if MN tells new AR arbitrary IP address as address of old AR, it can be detected). Also, the side effect of attacks, if any, does not adversely affect good MNs. But, of course, we could have missed some attack possibilities. Hemant >From: Daichi Funato >To: Hemant.Chaskar@nokia.com >CC: , , >Subject: Re: [Seamoby] CARD between Routers - will CT do? >Date: Wed, 15 Jan 2003 19:10:15 -0800 > >Hi Hemant, > > > Hemant --> I think we can start protocol design under the assumptions >that > > (i) old and new ARs can establish SA between them, (ii) they are willing >to > > participate in CARD protocol. Then, there may not be any need for >intra-domain > > / inter-domain classification. > >What kind of security mechanisms are you assuming? >I think we should not leave the security mechanisms out of the scope. > >Especially, MN-report-based CARD is vulnerable to an attacker. >How to protect the communication is an essential part of CARD, I think. >Actually, IEEE IAPP includes a security mechanism by itself. >Do we neglect that part in CARD? > >IMHO, if CARD can provide secure keys for ARs, these can be used by CT >and FMIP as well. This is another type of capability discovery. >What do you think? > >Best regards, >Daichi > >------------------------------------------------------------- >Daichi Funato >DoCoMo Communications Laboratories USA, Inc. > >Confidential Note: >Privileged/Confidential Information may be contained in this e-mail >and any attachment to it. Unless you are the addressee indicated in >this e-mail, please notify immediately the sender by reply e-mail >that you have received this in error and delete it from your system. >You may not use, copy or deliver this e-mail or any information >contained in this e-mail to anyone. Thank you very much. >------------------------------------------------------------- > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Jan 16 09:27:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11936 for ; Thu, 16 Jan 2003 09:27:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GEgJJ26616; Thu, 16 Jan 2003 09:42:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GEflJ26590 for ; Thu, 16 Jan 2003 09:41:47 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11887 for ; Thu, 16 Jan 2003 09:25:57 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0GET2B26036 for ; Thu, 16 Jan 2003 08:29:12 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 16 Jan 2003 08:28:52 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 16 Jan 2003 08:27:49 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CARD between Routers - will CT do? Date: Thu, 16 Jan 2003 09:27:48 -0500 Message-ID: Thread-Topic: [Seamoby] CARD between Routers - will CT do? Thread-Index: AcK9DnL/WkKbIyL+SO+aMVVlvCoSCgAXDjCw To: , Cc: , , X-OriginalArrivalTime: 16 Jan 2003 14:27:49.0918 (UTC) FILETIME=[727473E0:01C2BD6B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0GEflJ26591 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Daichi, In addition to what Hemant has described in his email, just one more point to clarify things. I don't think CARD has to establish an SA. I mean, the messaging for establishing an SA shouldn't be part of CARD. This would be re-inventing the wheel. I think CARD should depend on any proven mechanism to establish an SA. Once an SA is established then inter-AR exchange can happen. Also, could you point out what you consider as security holes in the "MN-report" based CARD protocol? We have illustrated several security checks in our latest draft. We have also shown how genuine MNs will never be affected, i.e. sent to the wrong AR. However, if you still think there are some holes, please let us know and we will attempt to rectify that. Thanks, Govind. -----Original Message----- From: ext Daichi Funato [mailto:funato@docomolabs-usa.com] Sent: Wednesday, January 15, 2003 10:10 PM To: Chaskar Hemant (NRC/Boston) Cc: eunsoo@nec-lab.com; kempf@docomolabs-usa.com; seamoby@ietf.org Subject: Re: [Seamoby] CARD between Routers - will CT do? Hi Hemant, > Hemant --> I think we can start protocol design under the assumptions that > (i) old and new ARs can establish SA between them, (ii) they are willing to > participate in CARD protocol. Then, there may not be any need for intra-domain > / inter-domain classification. What kind of security mechanisms are you assuming? I think we should not leave the security mechanisms out of the scope. Especially, MN-report-based CARD is vulnerable to an attacker. How to protect the communication is an essential part of CARD, I think. Actually, IEEE IAPP includes a security mechanism by itself. Do we neglect that part in CARD? IMHO, if CARD can provide secure keys for ARs, these can be used by CT and FMIP as well. This is another type of capability discovery. What do you think? Best regards, Daichi ------------------------------------------------------------- Daichi Funato DoCoMo Communications Laboratories USA, Inc. Confidential Note: Privileged/Confidential Information may be contained in this e-mail and any attachment to it. Unless you are the addressee indicated in this e-mail, please notify immediately the sender by reply e-mail that you have received this in error and delete it from your system. You may not use, copy or deliver this e-mail or any information contained in this e-mail to anyone. Thank you very much. ------------------------------------------------------------- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Jan 16 09:28:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11971 for ; Thu, 16 Jan 2003 09:28:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GEhSx26660 for seamoby-archive@odin.ietf.org; Thu, 16 Jan 2003 09:43:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GEhRJ26657 for ; Thu, 16 Jan 2003 09:43:27 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11951 for ; Thu, 16 Jan 2003 09:27:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GEgJJ26616; Thu, 16 Jan 2003 09:42:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GEflJ26590 for ; Thu, 16 Jan 2003 09:41:47 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11887 for ; Thu, 16 Jan 2003 09:25:57 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0GET2B26036 for ; Thu, 16 Jan 2003 08:29:12 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 16 Jan 2003 08:28:52 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 16 Jan 2003 08:27:49 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CARD between Routers - will CT do? Date: Thu, 16 Jan 2003 09:27:48 -0500 Message-ID: Thread-Topic: [Seamoby] CARD between Routers - will CT do? Thread-Index: AcK9DnL/WkKbIyL+SO+aMVVlvCoSCgAXDjCw To: , Cc: , , X-OriginalArrivalTime: 16 Jan 2003 14:27:49.0918 (UTC) FILETIME=[727473E0:01C2BD6B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0GEflJ26591 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Daichi, In addition to what Hemant has described in his email, just one more point to clarify things. I don't think CARD has to establish an SA. I mean, the messaging for establishing an SA shouldn't be part of CARD. This would be re-inventing the wheel. I think CARD should depend on any proven mechanism to establish an SA. Once an SA is established then inter-AR exchange can happen. Also, could you point out what you consider as security holes in the "MN-report" based CARD protocol? We have illustrated several security checks in our latest draft. We have also shown how genuine MNs will never be affected, i.e. sent to the wrong AR. However, if you still think there are some holes, please let us know and we will attempt to rectify that. Thanks, Govind. -----Original Message----- From: ext Daichi Funato [mailto:funato@docomolabs-usa.com] Sent: Wednesday, January 15, 2003 10:10 PM To: Chaskar Hemant (NRC/Boston) Cc: eunsoo@nec-lab.com; kempf@docomolabs-usa.com; seamoby@ietf.org Subject: Re: [Seamoby] CARD between Routers - will CT do? Hi Hemant, > Hemant --> I think we can start protocol design under the assumptions that > (i) old and new ARs can establish SA between them, (ii) they are willing to > participate in CARD protocol. Then, there may not be any need for intra-domain > / inter-domain classification. What kind of security mechanisms are you assuming? I think we should not leave the security mechanisms out of the scope. Especially, MN-report-based CARD is vulnerable to an attacker. How to protect the communication is an essential part of CARD, I think. Actually, IEEE IAPP includes a security mechanism by itself. Do we neglect that part in CARD? IMHO, if CARD can provide secure keys for ARs, these can be used by CT and FMIP as well. This is another type of capability discovery. What do you think? Best regards, Daichi ------------------------------------------------------------- Daichi Funato DoCoMo Communications Laboratories USA, Inc. Confidential Note: Privileged/Confidential Information may be contained in this e-mail and any attachment to it. Unless you are the addressee indicated in this e-mail, please notify immediately the sender by reply e-mail that you have received this in error and delete it from your system. You may not use, copy or deliver this e-mail or any information contained in this e-mail to anyone. Thank you very much. ------------------------------------------------------------- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Jan 16 09:55:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12899 for ; Thu, 16 Jan 2003 09:55:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GF9SJ28636; Thu, 16 Jan 2003 10:09:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GF8JJ28591 for ; Thu, 16 Jan 2003 10:08:19 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12766 for ; Thu, 16 Jan 2003 09:52:39 -0500 (EST) Received: from eunsoo ([138.15.107.234]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 16 Jan 2003 09:56:01 -0500 Message-ID: <00f401c2bd88$da45bac0$ea6b0f8a@eunsoo> From: "Eunsoo Shim" To: "Hemant Chaskar" , Cc: , References: Subject: Re: [Seamoby] CARD between Routers - will CT do? Date: Thu, 16 Jan 2003 09:58:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 16 Jan 2003 14:56:01.0620 (UTC) FILETIME=[62C9B140:01C2BD6F] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > I do not think that establishment of SA between ARs should be within scope > of CARD. We should start from pre-requisite that SA can be established > between ARs. When ARs belong to same domain, this is simple. When they > belong to different domain it is harder. In either case, there can be > variety of ways to establish SAs - pre-shared key, domain specific > certificates, AAA, credentials exchanged during SLAs or any other means. Why > should CARD put any restriction on mechanism used to establish SA? > > So, instead of > > <--Interworking--> > | > Intra-domain CARD | Inter-domain CARD > protocol | protocol > --------------------|------------------------------ > Intra-domain SA | Inter-domain SA > mechanism | mechanism > (CARD specific?) | (CARD specific?) > > I am saying that, if possible, we should try, > > > > CARD protocol > ---------------------------------------------- > | > Intra-domain SA | Inter-domain SA > mechanisms | mechanisms > current/future best | (current/future best > practices) | practices) > I also prefer one CARD protocol that works for inter-domain and intra-domain operations. We need to analyze security threats on CARD in details and find out security requirements and solutions. To discuss the security threats, first of all, we need to identify the discovery mechanisms we want to consider. There were two proposals before the design team was formed. To continue discussion on security issues, I am looking for proposals on base discovery mechanisms from the design team. If the design team has the same proposals from the existing two proposals, then we can start security analysis of the discovery mechanisms. Regards, Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Jan 16 09:56:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12932 for ; Thu, 16 Jan 2003 09:56:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GFBAK28788 for seamoby-archive@odin.ietf.org; Thu, 16 Jan 2003 10:11:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GFBAJ28785 for ; Thu, 16 Jan 2003 10:11:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12915 for ; Thu, 16 Jan 2003 09:55:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GF9SJ28636; Thu, 16 Jan 2003 10:09:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GF8JJ28591 for ; Thu, 16 Jan 2003 10:08:19 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12766 for ; Thu, 16 Jan 2003 09:52:39 -0500 (EST) Received: from eunsoo ([138.15.107.234]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 16 Jan 2003 09:56:01 -0500 Message-ID: <00f401c2bd88$da45bac0$ea6b0f8a@eunsoo> From: "Eunsoo Shim" To: "Hemant Chaskar" , Cc: , References: Subject: Re: [Seamoby] CARD between Routers - will CT do? Date: Thu, 16 Jan 2003 09:58:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 16 Jan 2003 14:56:01.0620 (UTC) FILETIME=[62C9B140:01C2BD6F] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I do not think that establishment of SA between ARs should be within scope > of CARD. We should start from pre-requisite that SA can be established > between ARs. When ARs belong to same domain, this is simple. When they > belong to different domain it is harder. In either case, there can be > variety of ways to establish SAs - pre-shared key, domain specific > certificates, AAA, credentials exchanged during SLAs or any other means. Why > should CARD put any restriction on mechanism used to establish SA? > > So, instead of > > <--Interworking--> > | > Intra-domain CARD | Inter-domain CARD > protocol | protocol > --------------------|------------------------------ > Intra-domain SA | Inter-domain SA > mechanism | mechanism > (CARD specific?) | (CARD specific?) > > I am saying that, if possible, we should try, > > > > CARD protocol > ---------------------------------------------- > | > Intra-domain SA | Inter-domain SA > mechanisms | mechanisms > current/future best | (current/future best > practices) | practices) > I also prefer one CARD protocol that works for inter-domain and intra-domain operations. We need to analyze security threats on CARD in details and find out security requirements and solutions. To discuss the security threats, first of all, we need to identify the discovery mechanisms we want to consider. There were two proposals before the design team was formed. To continue discussion on security issues, I am looking for proposals on base discovery mechanisms from the design team. If the design team has the same proposals from the existing two proposals, then we can start security analysis of the discovery mechanisms. Regards, Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Jan 16 12:26:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16927 for ; Thu, 16 Jan 2003 12:26:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GHePJ07669; Thu, 16 Jan 2003 12:40:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GHaJJ06815 for ; Thu, 16 Jan 2003 12:36:19 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16720 for ; Thu, 16 Jan 2003 12:20:36 -0500 (EST) Message-ID: <003001c2bd83$d2b073e0$5c6015ac@T23KEMPF> From: "James Kempf" To: , , References: Subject: Re: [Seamoby] CARD between Routers - will CT do? Date: Thu, 16 Jan 2003 09:22:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Hemant --> I think we can start protocol design under the assumptions that (i) old and new ARs can establish SA between them, (ii) they are willing to participate in CARD protocol. Then, there may not be any need for intra-domain / inter-domain classification. > Alternatively, an intermediary that would be more acceptable, such as a Radius server, could be used. My initial point is that the two providers don't want to expose their internal topology, even if they have an SA allowing inter-provider handover. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Jan 16 12:27:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16948 for ; Thu, 16 Jan 2003 12:27:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GHgO707763 for seamoby-archive@odin.ietf.org; Thu, 16 Jan 2003 12:42:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GHgOJ07760 for ; Thu, 16 Jan 2003 12:42:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16941 for ; Thu, 16 Jan 2003 12:26:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GHePJ07669; Thu, 16 Jan 2003 12:40:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GHaJJ06815 for ; Thu, 16 Jan 2003 12:36:19 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16720 for ; Thu, 16 Jan 2003 12:20:36 -0500 (EST) Message-ID: <003001c2bd83$d2b073e0$5c6015ac@T23KEMPF> From: "James Kempf" To: , , References: Subject: Re: [Seamoby] CARD between Routers - will CT do? Date: Thu, 16 Jan 2003 09:22:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Hemant --> I think we can start protocol design under the assumptions that (i) old and new ARs can establish SA between them, (ii) they are willing to participate in CARD protocol. Then, there may not be any need for intra-domain / inter-domain classification. > Alternatively, an intermediary that would be more acceptable, such as a Radius server, could be used. My initial point is that the two providers don't want to expose their internal topology, even if they have an SA allowing inter-provider handover. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Jan 16 12:48:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17691 for ; Thu, 16 Jan 2003 12:48:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GI3BJ09132; Thu, 16 Jan 2003 13:03:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GI2uJ09084 for ; Thu, 16 Jan 2003 13:02:56 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17645 for ; Thu, 16 Jan 2003 12:47:12 -0500 (EST) Message-ID: <008701c2bd87$86e3dcf0$5c6015ac@T23KEMPF> From: "James Kempf" To: "Hemant Chaskar" , , Cc: , References: Subject: Re: [Seamoby] CARD between Routers - will CT do? Date: Thu, 16 Jan 2003 09:48:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit What do you mean by an SA? An IPSec SA? If so, how do you propose to have the routers use that for checking that the AP L2 addresses provided by the MN map into IP addresses that are authorized to route on the service provider's network? Note that the IESG is requiring that the Security Considerations of all protocol drafts describe, precisely, how the protocol will be secured. It is no longer sufficient to say "use IPSec" or "use AAA". Requiring other protocols is OK, but it must be specified precisely how those protocols are used for securing the protocol in question. jak ----- Original Message ----- From: "Hemant Chaskar" To: ; Cc: ; ; Sent: Wednesday, January 15, 2003 8:24 PM Subject: Re: [Seamoby] CARD between Routers - will CT do? > Hi Daichi: > > I do not think that establishment of SA between ARs should be within scope > of CARD. We should start from pre-requisite that SA can be established > between ARs. When ARs belong to same domain, this is simple. When they > belong to different domain it is harder. In either case, there can be > variety of ways to establish SAs - pre-shared key, domain specific > certificates, AAA, credentials exchanged during SLAs or any other means. Why > should CARD put any restriction on mechanism used to establish SA? > > So, instead of > > <--Interworking--> > | > Intra-domain CARD | Inter-domain CARD > protocol | protocol > --------------------|------------------------------ > Intra-domain SA | Inter-domain SA > mechanism | mechanism > (CARD specific?) | (CARD specific?) > > I am saying that, if possible, we should try, > > > > CARD protocol > ---------------------------------------------- > | > Intra-domain SA | Inter-domain SA > mechanisms | mechanisms > current/future best | (current/future best > practices) | practices) > > At this point, I cannot vouch for security of MN-report-based CARD approach. > But, could you describe what kind of attacks do you think MN-report-based > CARD is vulnerable to? In draft-trossen-seamoby-dycard-00.txt, we have shown > that certain simple mechanisms can foil security attacks in MN-report-based > CARD (To the least, if MN tells new AR arbitrary IP address as address of > old AR, it can be detected). Also, the side effect of attacks, if any, does > not adversely affect good MNs. But, of course, we could have missed some > attack possibilities. > > > Hemant > > >From: Daichi Funato > >To: Hemant.Chaskar@nokia.com > >CC: , , > >Subject: Re: [Seamoby] CARD between Routers - will CT do? > >Date: Wed, 15 Jan 2003 19:10:15 -0800 > > > >Hi Hemant, > > > > > Hemant --> I think we can start protocol design under the assumptions > >that > > > (i) old and new ARs can establish SA between them, (ii) they are willing > >to > > > participate in CARD protocol. Then, there may not be any need for > >intra-domain > > > / inter-domain classification. > > > >What kind of security mechanisms are you assuming? > >I think we should not leave the security mechanisms out of the scope. > > > >Especially, MN-report-based CARD is vulnerable to an attacker. > >How to protect the communication is an essential part of CARD, I think. > >Actually, IEEE IAPP includes a security mechanism by itself. > >Do we neglect that part in CARD? > > > >IMHO, if CARD can provide secure keys for ARs, these can be used by CT > >and FMIP as well. This is another type of capability discovery. > >What do you think? > > > >Best regards, > >Daichi > > > >------------------------------------------------------------- > >Daichi Funato > >DoCoMo Communications Laboratories USA, Inc. > > > >Confidential Note: > >Privileged/Confidential Information may be contained in this e-mail > >and any attachment to it. Unless you are the addressee indicated in > >this e-mail, please notify immediately the sender by reply e-mail > >that you have received this in error and delete it from your system. > >You may not use, copy or deliver this e-mail or any information > >contained in this e-mail to anyone. Thank you very much. > >------------------------------------------------------------- > > > >_______________________________________________ > >Seamoby mailing list > >Seamoby@ietf.org > >https://www1.ietf.org/mailman/listinfo/seamoby > > > _________________________________________________________________ > Add photos to your e-mail with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Jan 16 12:49:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17728 for ; Thu, 16 Jan 2003 12:49:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GI4Rs09183 for seamoby-archive@odin.ietf.org; Thu, 16 Jan 2003 13:04:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GI4QJ09180 for ; Thu, 16 Jan 2003 13:04:26 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17705 for ; Thu, 16 Jan 2003 12:48:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GI3BJ09132; Thu, 16 Jan 2003 13:03:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GI2uJ09084 for ; Thu, 16 Jan 2003 13:02:56 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17645 for ; Thu, 16 Jan 2003 12:47:12 -0500 (EST) Message-ID: <008701c2bd87$86e3dcf0$5c6015ac@T23KEMPF> From: "James Kempf" To: "Hemant Chaskar" , , Cc: , References: Subject: Re: [Seamoby] CARD between Routers - will CT do? Date: Thu, 16 Jan 2003 09:48:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit What do you mean by an SA? An IPSec SA? If so, how do you propose to have the routers use that for checking that the AP L2 addresses provided by the MN map into IP addresses that are authorized to route on the service provider's network? Note that the IESG is requiring that the Security Considerations of all protocol drafts describe, precisely, how the protocol will be secured. It is no longer sufficient to say "use IPSec" or "use AAA". Requiring other protocols is OK, but it must be specified precisely how those protocols are used for securing the protocol in question. jak ----- Original Message ----- From: "Hemant Chaskar" To: ; Cc: ; ; Sent: Wednesday, January 15, 2003 8:24 PM Subject: Re: [Seamoby] CARD between Routers - will CT do? > Hi Daichi: > > I do not think that establishment of SA between ARs should be within scope > of CARD. We should start from pre-requisite that SA can be established > between ARs. When ARs belong to same domain, this is simple. When they > belong to different domain it is harder. In either case, there can be > variety of ways to establish SAs - pre-shared key, domain specific > certificates, AAA, credentials exchanged during SLAs or any other means. Why > should CARD put any restriction on mechanism used to establish SA? > > So, instead of > > <--Interworking--> > | > Intra-domain CARD | Inter-domain CARD > protocol | protocol > --------------------|------------------------------ > Intra-domain SA | Inter-domain SA > mechanism | mechanism > (CARD specific?) | (CARD specific?) > > I am saying that, if possible, we should try, > > > > CARD protocol > ---------------------------------------------- > | > Intra-domain SA | Inter-domain SA > mechanisms | mechanisms > current/future best | (current/future best > practices) | practices) > > At this point, I cannot vouch for security of MN-report-based CARD approach. > But, could you describe what kind of attacks do you think MN-report-based > CARD is vulnerable to? In draft-trossen-seamoby-dycard-00.txt, we have shown > that certain simple mechanisms can foil security attacks in MN-report-based > CARD (To the least, if MN tells new AR arbitrary IP address as address of > old AR, it can be detected). Also, the side effect of attacks, if any, does > not adversely affect good MNs. But, of course, we could have missed some > attack possibilities. > > > Hemant > > >From: Daichi Funato > >To: Hemant.Chaskar@nokia.com > >CC: , , > >Subject: Re: [Seamoby] CARD between Routers - will CT do? > >Date: Wed, 15 Jan 2003 19:10:15 -0800 > > > >Hi Hemant, > > > > > Hemant --> I think we can start protocol design under the assumptions > >that > > > (i) old and new ARs can establish SA between them, (ii) they are willing > >to > > > participate in CARD protocol. Then, there may not be any need for > >intra-domain > > > / inter-domain classification. > > > >What kind of security mechanisms are you assuming? > >I think we should not leave the security mechanisms out of the scope. > > > >Especially, MN-report-based CARD is vulnerable to an attacker. > >How to protect the communication is an essential part of CARD, I think. > >Actually, IEEE IAPP includes a security mechanism by itself. > >Do we neglect that part in CARD? > > > >IMHO, if CARD can provide secure keys for ARs, these can be used by CT > >and FMIP as well. This is another type of capability discovery. > >What do you think? > > > >Best regards, > >Daichi > > > >------------------------------------------------------------- > >Daichi Funato > >DoCoMo Communications Laboratories USA, Inc. > > > >Confidential Note: > >Privileged/Confidential Information may be contained in this e-mail > >and any attachment to it. Unless you are the addressee indicated in > >this e-mail, please notify immediately the sender by reply e-mail > >that you have received this in error and delete it from your system. > >You may not use, copy or deliver this e-mail or any information > >contained in this e-mail to anyone. Thank you very much. > >------------------------------------------------------------- > > > >_______________________________________________ > >Seamoby mailing list > >Seamoby@ietf.org > >https://www1.ietf.org/mailman/listinfo/seamoby > > > _________________________________________________________________ > Add photos to your e-mail with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Jan 16 12:51:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17816 for ; Thu, 16 Jan 2003 12:51:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GI63J09300; Thu, 16 Jan 2003 13:06:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GI5jJ09268 for ; Thu, 16 Jan 2003 13:05:45 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17766 for ; Thu, 16 Jan 2003 12:49:52 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0GHqxB17313 for ; Thu, 16 Jan 2003 11:53:10 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 16 Jan 2003 11:52:51 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 16 Jan 2003 11:52:43 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CARD between Routers - will CT do? Date: Thu, 16 Jan 2003 12:52:42 -0500 Message-ID: Thread-Topic: [Seamoby] CARD between Routers - will CT do? Thread-Index: AcK9hA/TI/iQ6+1WRXKWM9kCXHUNSgAA0/Tw To: , , X-OriginalArrivalTime: 16 Jan 2003 17:52:43.0371 (UTC) FILETIME=[11EC83B0:01C2BD88] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0GI5jJ09269 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi James: I am not sure why CARD needs to expose "internal" topology. But, to emphasize it, we can add a guideline that (iii) CARD SHOULD/MUST not export any information between domains other than AR addresses, Link layer IDs and capabilities. (The above information is already exposed to third parties, i.e., MNs connecting to networks. So, it is not secret anymore.) Are you suggesting use of Radius to establish SAs (possible) or for performing CARD (not sure)? Hemant -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Thursday, January 16, 2003 12:22 PM To: Chaskar Hemant (NRC/Boston); eunsoo@nec-lab.com; seamoby@ietf.org Subject: Re: [Seamoby] CARD between Routers - will CT do? > Hemant --> I think we can start protocol design under the assumptions that (i) old and new ARs can establish SA between them, (ii) they are willing to participate in CARD protocol. Then, there may not be any need for intra-domain / inter-domain classification. > Alternatively, an intermediary that would be more acceptable, such as a Radius server, could be used. My initial point is that the two providers don't want to expose their internal topology, even if they have an SA allowing inter-provider handover. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Jan 16 12:51:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17860 for ; Thu, 16 Jan 2003 12:51:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GI76Q09520 for seamoby-archive@odin.ietf.org; Thu, 16 Jan 2003 13:07:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GI76J09517 for ; Thu, 16 Jan 2003 13:07:06 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17830 for ; Thu, 16 Jan 2003 12:51:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GI63J09300; Thu, 16 Jan 2003 13:06:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GI5jJ09268 for ; Thu, 16 Jan 2003 13:05:45 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17766 for ; Thu, 16 Jan 2003 12:49:52 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0GHqxB17313 for ; Thu, 16 Jan 2003 11:53:10 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 16 Jan 2003 11:52:51 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 16 Jan 2003 11:52:43 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CARD between Routers - will CT do? Date: Thu, 16 Jan 2003 12:52:42 -0500 Message-ID: Thread-Topic: [Seamoby] CARD between Routers - will CT do? Thread-Index: AcK9hA/TI/iQ6+1WRXKWM9kCXHUNSgAA0/Tw To: , , X-OriginalArrivalTime: 16 Jan 2003 17:52:43.0371 (UTC) FILETIME=[11EC83B0:01C2BD88] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0GI5jJ09269 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi James: I am not sure why CARD needs to expose "internal" topology. But, to emphasize it, we can add a guideline that (iii) CARD SHOULD/MUST not export any information between domains other than AR addresses, Link layer IDs and capabilities. (The above information is already exposed to third parties, i.e., MNs connecting to networks. So, it is not secret anymore.) Are you suggesting use of Radius to establish SAs (possible) or for performing CARD (not sure)? Hemant -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Thursday, January 16, 2003 12:22 PM To: Chaskar Hemant (NRC/Boston); eunsoo@nec-lab.com; seamoby@ietf.org Subject: Re: [Seamoby] CARD between Routers - will CT do? > Hemant --> I think we can start protocol design under the assumptions that (i) old and new ARs can establish SA between them, (ii) they are willing to participate in CARD protocol. Then, there may not be any need for intra-domain / inter-domain classification. > Alternatively, an intermediary that would be more acceptable, such as a Radius server, could be used. My initial point is that the two providers don't want to expose their internal topology, even if they have an SA allowing inter-provider handover. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Jan 16 12:54:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18067 for ; Thu, 16 Jan 2003 12:54:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GI93J10194; Thu, 16 Jan 2003 13:09:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GI8hJ10160 for ; Thu, 16 Jan 2003 13:08:43 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17928 for ; Thu, 16 Jan 2003 12:52:45 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0GHtrB17930 for ; Thu, 16 Jan 2003 11:56:03 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 16 Jan 2003 11:55:46 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 16 Jan 2003 09:55:45 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CARD between Routers - will CT do? Date: Thu, 16 Jan 2003 12:55:44 -0500 Message-ID: Thread-Topic: [Seamoby] CARD between Routers - will CT do? Thread-Index: AcK9h8oYtnGUSxQzS7Ss/flV6/DjlQAAFsTg To: , , Cc: , X-OriginalArrivalTime: 16 Jan 2003 17:55:45.0815 (UTC) FILETIME=[7EAB4270:01C2BD88] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0GI8hJ10161 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi James: One suggestion: Referring second diagram below, we could design CARD agnostic to intra or inter classification, but assuming that ARs can establish SAs. Then, we provide subsections on how this would be achieved for intra case and inter case. Of this first subsection will be ready first (as it is easier) and we continue to work on second subsection over time. What do you think? Hemant -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Thursday, January 16, 2003 12:49 PM To: Hemant Chaskar; funato@docomolabs-usa.com; Chaskar Hemant (NRC/Boston) Cc: eunsoo@nec-lab.com; seamoby@ietf.org Subject: Re: [Seamoby] CARD between Routers - will CT do? What do you mean by an SA? An IPSec SA? If so, how do you propose to have the routers use that for checking that the AP L2 addresses provided by the MN map into IP addresses that are authorized to route on the service provider's network? Note that the IESG is requiring that the Security Considerations of all protocol drafts describe, precisely, how the protocol will be secured. It is no longer sufficient to say "use IPSec" or "use AAA". Requiring other protocols is OK, but it must be specified precisely how those protocols are used for securing the protocol in question. jak ----- Original Message ----- From: "Hemant Chaskar" To: ; Cc: ; ; Sent: Wednesday, January 15, 2003 8:24 PM Subject: Re: [Seamoby] CARD between Routers - will CT do? > Hi Daichi: > > I do not think that establishment of SA between ARs should be within scope > of CARD. We should start from pre-requisite that SA can be established > between ARs. When ARs belong to same domain, this is simple. When they > belong to different domain it is harder. In either case, there can be > variety of ways to establish SAs - pre-shared key, domain specific > certificates, AAA, credentials exchanged during SLAs or any other means. Why > should CARD put any restriction on mechanism used to establish SA? > > So, instead of > > <--Interworking--> > | > Intra-domain CARD | Inter-domain CARD > protocol | protocol > --------------------|------------------------------ > Intra-domain SA | Inter-domain SA > mechanism | mechanism > (CARD specific?) | (CARD specific?) > > I am saying that, if possible, we should try, > > > > CARD protocol > ---------------------------------------------- > | > Intra-domain SA | Inter-domain SA > mechanisms | mechanisms > current/future best | (current/future best > practices) | practices) > > At this point, I cannot vouch for security of MN-report-based CARD approach. > But, could you describe what kind of attacks do you think MN-report-based > CARD is vulnerable to? In draft-trossen-seamoby-dycard-00.txt, we have shown > that certain simple mechanisms can foil security attacks in MN-report-based > CARD (To the least, if MN tells new AR arbitrary IP address as address of > old AR, it can be detected). Also, the side effect of attacks, if any, does > not adversely affect good MNs. But, of course, we could have missed some > attack possibilities. > > > Hemant > > >From: Daichi Funato > >To: Hemant.Chaskar@nokia.com > >CC: , , > >Subject: Re: [Seamoby] CARD between Routers - will CT do? > >Date: Wed, 15 Jan 2003 19:10:15 -0800 > > > >Hi Hemant, > > > > > Hemant --> I think we can start protocol design under the assumptions > >that > > > (i) old and new ARs can establish SA between them, (ii) they are willing > >to > > > participate in CARD protocol. Then, there may not be any need for > >intra-domain > > > / inter-domain classification. > > > >What kind of security mechanisms are you assuming? > >I think we should not leave the security mechanisms out of the scope. > > > >Especially, MN-report-based CARD is vulnerable to an attacker. > >How to protect the communication is an essential part of CARD, I think. > >Actually, IEEE IAPP includes a security mechanism by itself. > >Do we neglect that part in CARD? > > > >IMHO, if CARD can provide secure keys for ARs, these can be used by CT > >and FMIP as well. This is another type of capability discovery. > >What do you think? > > > >Best regards, > >Daichi > > > >------------------------------------------------------------- > >Daichi Funato > >DoCoMo Communications Laboratories USA, Inc. > > > >Confidential Note: > >Privileged/Confidential Information may be contained in this e-mail > >and any attachment to it. Unless you are the addressee indicated in > >this e-mail, please notify immediately the sender by reply e-mail > >that you have received this in error and delete it from your system. > >You may not use, copy or deliver this e-mail or any information > >contained in this e-mail to anyone. Thank you very much. > >------------------------------------------------------------- > > > >_______________________________________________ > >Seamoby mailing list > >Seamoby@ietf.org > >https://www1.ietf.org/mailman/listinfo/seamoby > > > _________________________________________________________________ > Add photos to your e-mail with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Jan 16 12:55:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18118 for ; Thu, 16 Jan 2003 12:55:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GIAKX10302 for seamoby-archive@odin.ietf.org; Thu, 16 Jan 2003 13:10:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GIAJJ10299 for ; Thu, 16 Jan 2003 13:10:19 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18088 for ; Thu, 16 Jan 2003 12:54:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GI93J10194; Thu, 16 Jan 2003 13:09:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GI8hJ10160 for ; Thu, 16 Jan 2003 13:08:43 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17928 for ; Thu, 16 Jan 2003 12:52:45 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0GHtrB17930 for ; Thu, 16 Jan 2003 11:56:03 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 16 Jan 2003 11:55:46 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 16 Jan 2003 09:55:45 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CARD between Routers - will CT do? Date: Thu, 16 Jan 2003 12:55:44 -0500 Message-ID: Thread-Topic: [Seamoby] CARD between Routers - will CT do? Thread-Index: AcK9h8oYtnGUSxQzS7Ss/flV6/DjlQAAFsTg To: , , Cc: , X-OriginalArrivalTime: 16 Jan 2003 17:55:45.0815 (UTC) FILETIME=[7EAB4270:01C2BD88] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0GI8hJ10161 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi James: One suggestion: Referring second diagram below, we could design CARD agnostic to intra or inter classification, but assuming that ARs can establish SAs. Then, we provide subsections on how this would be achieved for intra case and inter case. Of this first subsection will be ready first (as it is easier) and we continue to work on second subsection over time. What do you think? Hemant -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Thursday, January 16, 2003 12:49 PM To: Hemant Chaskar; funato@docomolabs-usa.com; Chaskar Hemant (NRC/Boston) Cc: eunsoo@nec-lab.com; seamoby@ietf.org Subject: Re: [Seamoby] CARD between Routers - will CT do? What do you mean by an SA? An IPSec SA? If so, how do you propose to have the routers use that for checking that the AP L2 addresses provided by the MN map into IP addresses that are authorized to route on the service provider's network? Note that the IESG is requiring that the Security Considerations of all protocol drafts describe, precisely, how the protocol will be secured. It is no longer sufficient to say "use IPSec" or "use AAA". Requiring other protocols is OK, but it must be specified precisely how those protocols are used for securing the protocol in question. jak ----- Original Message ----- From: "Hemant Chaskar" To: ; Cc: ; ; Sent: Wednesday, January 15, 2003 8:24 PM Subject: Re: [Seamoby] CARD between Routers - will CT do? > Hi Daichi: > > I do not think that establishment of SA between ARs should be within scope > of CARD. We should start from pre-requisite that SA can be established > between ARs. When ARs belong to same domain, this is simple. When they > belong to different domain it is harder. In either case, there can be > variety of ways to establish SAs - pre-shared key, domain specific > certificates, AAA, credentials exchanged during SLAs or any other means. Why > should CARD put any restriction on mechanism used to establish SA? > > So, instead of > > <--Interworking--> > | > Intra-domain CARD | Inter-domain CARD > protocol | protocol > --------------------|------------------------------ > Intra-domain SA | Inter-domain SA > mechanism | mechanism > (CARD specific?) | (CARD specific?) > > I am saying that, if possible, we should try, > > > > CARD protocol > ---------------------------------------------- > | > Intra-domain SA | Inter-domain SA > mechanisms | mechanisms > current/future best | (current/future best > practices) | practices) > > At this point, I cannot vouch for security of MN-report-based CARD approach. > But, could you describe what kind of attacks do you think MN-report-based > CARD is vulnerable to? In draft-trossen-seamoby-dycard-00.txt, we have shown > that certain simple mechanisms can foil security attacks in MN-report-based > CARD (To the least, if MN tells new AR arbitrary IP address as address of > old AR, it can be detected). Also, the side effect of attacks, if any, does > not adversely affect good MNs. But, of course, we could have missed some > attack possibilities. > > > Hemant > > >From: Daichi Funato > >To: Hemant.Chaskar@nokia.com > >CC: , , > >Subject: Re: [Seamoby] CARD between Routers - will CT do? > >Date: Wed, 15 Jan 2003 19:10:15 -0800 > > > >Hi Hemant, > > > > > Hemant --> I think we can start protocol design under the assumptions > >that > > > (i) old and new ARs can establish SA between them, (ii) they are willing > >to > > > participate in CARD protocol. Then, there may not be any need for > >intra-domain > > > / inter-domain classification. > > > >What kind of security mechanisms are you assuming? > >I think we should not leave the security mechanisms out of the scope. > > > >Especially, MN-report-based CARD is vulnerable to an attacker. > >How to protect the communication is an essential part of CARD, I think. > >Actually, IEEE IAPP includes a security mechanism by itself. > >Do we neglect that part in CARD? > > > >IMHO, if CARD can provide secure keys for ARs, these can be used by CT > >and FMIP as well. This is another type of capability discovery. > >What do you think? > > > >Best regards, > >Daichi > > > >------------------------------------------------------------- > >Daichi Funato > >DoCoMo Communications Laboratories USA, Inc. > > > >Confidential Note: > >Privileged/Confidential Information may be contained in this e-mail > >and any attachment to it. Unless you are the addressee indicated in > >this e-mail, please notify immediately the sender by reply e-mail > >that you have received this in error and delete it from your system. > >You may not use, copy or deliver this e-mail or any information > >contained in this e-mail to anyone. Thank you very much. > >------------------------------------------------------------- > > > >_______________________________________________ > >Seamoby mailing list > >Seamoby@ietf.org > >https://www1.ietf.org/mailman/listinfo/seamoby > > > _________________________________________________________________ > Add photos to your e-mail with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Jan 16 12:56:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18209 for ; Thu, 16 Jan 2003 12:56:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GIB4J10355; Thu, 16 Jan 2003 13:11:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GIAVJ10316 for ; Thu, 16 Jan 2003 13:10:31 -0500 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18108 for ; Thu, 16 Jan 2003 12:54:48 -0500 (EST) Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id h0GHvtR50634; Thu, 16 Jan 2003 18:57:56 +0100 (CET) (envelope-from Marco.Liebsch@ccrle.nec.de) Received: from ccrle.nec.de (liebsch.office [10.1.1.153]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id BA88C844C8; Thu, 16 Jan 2003 20:06:02 +0100 (CET) Message-ID: <3E26F258.9020706@ccrle.nec.de> Date: Thu, 16 Jan 2003 18:56:40 +0100 From: Marco Liebsch Organization: NEC Europe Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf Cc: Hemant.Chaskar@nokia.com, eunsoo@nec-lab.com, seamoby@ietf.org Subject: Re: [Seamoby] CARD between Routers - will CT do? References: <003001c2bd83$d2b073e0$5c6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit James, do you refer to server-based SA establishment for inter-domain case only, or for any case, inter- as well as intra-domain CARD? marco James Kempf wrote: >>Hemant --> I think we can start protocol design under the assumptions that (i) >> >> >old and new ARs can establish SA between them, (ii) they are willing to >participate in CARD protocol. Then, there may not be any need for intra-domain / >inter-domain classification. > > > >Alternatively, an intermediary that would be more acceptable, such as a Radius >server, could be used. My initial point is that the two providers don't want to >expose their internal topology, even if they have an SA allowing inter-provider >handover. > > jak > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Jan 16 12:57:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18242 for ; Thu, 16 Jan 2003 12:57:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GICGv10449 for seamoby-archive@odin.ietf.org; Thu, 16 Jan 2003 13:12:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GICGJ10446 for ; Thu, 16 Jan 2003 13:12:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18224 for ; Thu, 16 Jan 2003 12:56:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GIB4J10355; Thu, 16 Jan 2003 13:11:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GIAVJ10316 for ; Thu, 16 Jan 2003 13:10:31 -0500 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18108 for ; Thu, 16 Jan 2003 12:54:48 -0500 (EST) Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id h0GHvtR50634; Thu, 16 Jan 2003 18:57:56 +0100 (CET) (envelope-from Marco.Liebsch@ccrle.nec.de) Received: from ccrle.nec.de (liebsch.office [10.1.1.153]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id BA88C844C8; Thu, 16 Jan 2003 20:06:02 +0100 (CET) Message-ID: <3E26F258.9020706@ccrle.nec.de> Date: Thu, 16 Jan 2003 18:56:40 +0100 From: Marco Liebsch Organization: NEC Europe Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf Cc: Hemant.Chaskar@nokia.com, eunsoo@nec-lab.com, seamoby@ietf.org Subject: Re: [Seamoby] CARD between Routers - will CT do? References: <003001c2bd83$d2b073e0$5c6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit James, do you refer to server-based SA establishment for inter-domain case only, or for any case, inter- as well as intra-domain CARD? marco James Kempf wrote: >>Hemant --> I think we can start protocol design under the assumptions that (i) >> >> >old and new ARs can establish SA between them, (ii) they are willing to >participate in CARD protocol. Then, there may not be any need for intra-domain / >inter-domain classification. > > > >Alternatively, an intermediary that would be more acceptable, such as a Radius >server, could be used. My initial point is that the two providers don't want to >expose their internal topology, even if they have an SA allowing inter-provider >handover. > > jak > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Jan 16 13:25:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19169 for ; Thu, 16 Jan 2003 13:25:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GIe9J12941; Thu, 16 Jan 2003 13:40:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GIdmJ12878 for ; Thu, 16 Jan 2003 13:39:48 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19132 for ; Thu, 16 Jan 2003 13:24:04 -0500 (EST) Message-ID: <00d101c2bd8c$b1c034f0$5c6015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , "Hemant Chaskar" , Cc: References: <006401c2bd84$e17502f0$ea6b0f8a@eunsoo> Subject: Re: [Seamoby] CARD between Routers - will CT do? Date: Thu, 16 Jan 2003 10:21:58 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Speaking with my service provider hat on... Like I said, I think you will have a hard time persuading service providers to utilize an interdomain protocol if it requires them to expose their internal routing topology. I think they are likely to configure to simply reject any information provided by the MN that does not correspond to routers in their domain. There are some limited cases where it may be of use, two providers that are subsidiaries of the same company for example, but they are not worth spending time on right now. I think we ought to concentrate on the intraprovider case, then revisit the interprovider issue when we are done. Otherwise, we are likely to get bogged down in the details of how to do something that, in the end, no service provider wants. Let's make it *simple* first, then add things as it becomes apparent that they are needed. If there is some doubt about this, I can discuss it with our operations people and have one of them come on the list with an opinion. Perhaps other service providers on this list can speak up? Are there any on the list? jak ----- Original Message ----- From: "Eunsoo Shim" To: "Hemant Chaskar" ; Cc: ; Sent: Thursday, January 16, 2003 9:29 AM Subject: Re: [Seamoby] CARD between Routers - will CT do? > > I do not think that establishment of SA between ARs should be within scope > > of CARD. We should start from pre-requisite that SA can be established > > between ARs. When ARs belong to same domain, this is simple. When they > > belong to different domain it is harder. In either case, there can be > > variety of ways to establish SAs - pre-shared key, domain specific > > certificates, AAA, credentials exchanged during SLAs or any other means. > Why > > should CARD put any restriction on mechanism used to establish SA? > > > > So, instead of > > > > <--Interworking--> > > | > > Intra-domain CARD | Inter-domain CARD > > protocol | protocol > > --------------------|------------------------------ > > Intra-domain SA | Inter-domain SA > > mechanism | mechanism > > (CARD specific?) | (CARD specific?) > > > > I am saying that, if possible, we should try, > > > > > > > > CARD protocol > > ---------------------------------------------- > > | > > Intra-domain SA | Inter-domain SA > > mechanisms | mechanisms > > current/future best | (current/future best > > practices) | practices) > > > > I also prefer one CARD protocol that works for inter-domain and intra-domain > operations. > We need to analyze security threats on CARD in details and find out security > requirements and solutions. > To discuss the security threats, first of all, we need to identify the > discovery mechanisms we want to consider. > There were two proposals before the design team was formed. > To continue discussion on security issues, I am looking for proposals on > base discovery mechanisms from the design team. > If the design team has the same proposals from the existing two proposals, > then we can start security analysis of the discovery mechanisms. > Regards, > > Eunsoo > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Jan 16 13:26:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19215 for ; Thu, 16 Jan 2003 13:26:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GIfHD13029 for seamoby-archive@odin.ietf.org; Thu, 16 Jan 2003 13:41:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GIfHJ13025 for ; Thu, 16 Jan 2003 13:41:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19183 for ; Thu, 16 Jan 2003 13:25:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GIe9J12941; Thu, 16 Jan 2003 13:40:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GIdmJ12878 for ; Thu, 16 Jan 2003 13:39:48 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19132 for ; Thu, 16 Jan 2003 13:24:04 -0500 (EST) Message-ID: <00d101c2bd8c$b1c034f0$5c6015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , "Hemant Chaskar" , Cc: References: <006401c2bd84$e17502f0$ea6b0f8a@eunsoo> Subject: Re: [Seamoby] CARD between Routers - will CT do? Date: Thu, 16 Jan 2003 10:21:58 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Speaking with my service provider hat on... Like I said, I think you will have a hard time persuading service providers to utilize an interdomain protocol if it requires them to expose their internal routing topology. I think they are likely to configure to simply reject any information provided by the MN that does not correspond to routers in their domain. There are some limited cases where it may be of use, two providers that are subsidiaries of the same company for example, but they are not worth spending time on right now. I think we ought to concentrate on the intraprovider case, then revisit the interprovider issue when we are done. Otherwise, we are likely to get bogged down in the details of how to do something that, in the end, no service provider wants. Let's make it *simple* first, then add things as it becomes apparent that they are needed. If there is some doubt about this, I can discuss it with our operations people and have one of them come on the list with an opinion. Perhaps other service providers on this list can speak up? Are there any on the list? jak ----- Original Message ----- From: "Eunsoo Shim" To: "Hemant Chaskar" ; Cc: ; Sent: Thursday, January 16, 2003 9:29 AM Subject: Re: [Seamoby] CARD between Routers - will CT do? > > I do not think that establishment of SA between ARs should be within scope > > of CARD. We should start from pre-requisite that SA can be established > > between ARs. When ARs belong to same domain, this is simple. When they > > belong to different domain it is harder. In either case, there can be > > variety of ways to establish SAs - pre-shared key, domain specific > > certificates, AAA, credentials exchanged during SLAs or any other means. > Why > > should CARD put any restriction on mechanism used to establish SA? > > > > So, instead of > > > > <--Interworking--> > > | > > Intra-domain CARD | Inter-domain CARD > > protocol | protocol > > --------------------|------------------------------ > > Intra-domain SA | Inter-domain SA > > mechanism | mechanism > > (CARD specific?) | (CARD specific?) > > > > I am saying that, if possible, we should try, > > > > > > > > CARD protocol > > ---------------------------------------------- > > | > > Intra-domain SA | Inter-domain SA > > mechanisms | mechanisms > > current/future best | (current/future best > > practices) | practices) > > > > I also prefer one CARD protocol that works for inter-domain and intra-domain > operations. > We need to analyze security threats on CARD in details and find out security > requirements and solutions. > To discuss the security threats, first of all, we need to identify the > discovery mechanisms we want to consider. > There were two proposals before the design team was formed. > To continue discussion on security issues, I am looking for proposals on > base discovery mechanisms from the design team. > If the design team has the same proposals from the existing two proposals, > then we can start security analysis of the discovery mechanisms. > Regards, > > Eunsoo > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Jan 16 13:48:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20233 for ; Thu, 16 Jan 2003 13:48:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GJ2JJ14230; Thu, 16 Jan 2003 14:02:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GJ1HJ14182 for ; Thu, 16 Jan 2003 14:01:17 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20137 for ; Thu, 16 Jan 2003 13:45:33 -0500 (EST) Message-ID: <010f01c2bd8f$b1743070$5c6015ac@T23KEMPF> From: "James Kempf" To: , , References: Subject: Re: [Seamoby] CARD between Routers - will CT do? Date: Thu, 16 Jan 2003 10:47:15 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit With my service provider hat on, I'm saying that I don't think our operations guys will approve using the IP address from another service provider's internal topology in the fashion that you and Eunsoo are advocating. Regardless of whether or not there is a Radius connection. if the MN sends it, our RAs will simply be configured to reject it. Therefore, I think we should now try to concentrate on the intra-provider case now, and deal with the interprovider case later. Other service providers, want to comment? jak ----- Original Message ----- From: To: ; ; Sent: Thursday, January 16, 2003 9:52 AM Subject: RE: [Seamoby] CARD between Routers - will CT do? > Hi James: > > I am not sure why CARD needs to expose "internal" topology. But, to emphasize it, we can add a guideline that > > (iii) CARD SHOULD/MUST not export any information between domains other than AR addresses, Link layer IDs and capabilities. > > (The above information is already exposed to third parties, i.e., MNs connecting to networks. So, it is not secret anymore.) > > Are you suggesting use of Radius to establish SAs (possible) or for performing CARD (not sure)? > > Hemant > > -----Original Message----- > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Thursday, January 16, 2003 12:22 PM > To: Chaskar Hemant (NRC/Boston); eunsoo@nec-lab.com; seamoby@ietf.org > Subject: Re: [Seamoby] CARD between Routers - will CT do? > > > > Hemant --> I think we can start protocol design under the assumptions that (i) > old and new ARs can establish SA between them, (ii) they are willing to > participate in CARD protocol. Then, there may not be any need for intra-domain / > inter-domain classification. > > > > Alternatively, an intermediary that would be more acceptable, such as a Radius > server, could be used. My initial point is that the two providers don't want to > expose their internal topology, even if they have an SA allowing inter-provider > handover. > > jak > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Jan 16 13:48:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20270 for ; Thu, 16 Jan 2003 13:48:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GJ47b14350 for seamoby-archive@odin.ietf.org; Thu, 16 Jan 2003 14:04:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GJ47J14347 for ; Thu, 16 Jan 2003 14:04:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20247 for ; Thu, 16 Jan 2003 13:48:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GJ2JJ14230; Thu, 16 Jan 2003 14:02:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GJ1HJ14182 for ; Thu, 16 Jan 2003 14:01:17 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20137 for ; Thu, 16 Jan 2003 13:45:33 -0500 (EST) Message-ID: <010f01c2bd8f$b1743070$5c6015ac@T23KEMPF> From: "James Kempf" To: , , References: Subject: Re: [Seamoby] CARD between Routers - will CT do? Date: Thu, 16 Jan 2003 10:47:15 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit With my service provider hat on, I'm saying that I don't think our operations guys will approve using the IP address from another service provider's internal topology in the fashion that you and Eunsoo are advocating. Regardless of whether or not there is a Radius connection. if the MN sends it, our RAs will simply be configured to reject it. Therefore, I think we should now try to concentrate on the intra-provider case now, and deal with the interprovider case later. Other service providers, want to comment? jak ----- Original Message ----- From: To: ; ; Sent: Thursday, January 16, 2003 9:52 AM Subject: RE: [Seamoby] CARD between Routers - will CT do? > Hi James: > > I am not sure why CARD needs to expose "internal" topology. But, to emphasize it, we can add a guideline that > > (iii) CARD SHOULD/MUST not export any information between domains other than AR addresses, Link layer IDs and capabilities. > > (The above information is already exposed to third parties, i.e., MNs connecting to networks. So, it is not secret anymore.) > > Are you suggesting use of Radius to establish SAs (possible) or for performing CARD (not sure)? > > Hemant > > -----Original Message----- > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Thursday, January 16, 2003 12:22 PM > To: Chaskar Hemant (NRC/Boston); eunsoo@nec-lab.com; seamoby@ietf.org > Subject: Re: [Seamoby] CARD between Routers - will CT do? > > > > Hemant --> I think we can start protocol design under the assumptions that (i) > old and new ARs can establish SA between them, (ii) they are willing to > participate in CARD protocol. Then, there may not be any need for intra-domain / > inter-domain classification. > > > > Alternatively, an intermediary that would be more acceptable, such as a Radius > server, could be used. My initial point is that the two providers don't want to > expose their internal topology, even if they have an SA allowing inter-provider > handover. > > jak > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Jan 16 13:49:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20288 for ; Thu, 16 Jan 2003 13:49:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GJ45J14339; Thu, 16 Jan 2003 14:04:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GJ3tJ14309 for ; Thu, 16 Jan 2003 14:03:55 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20229 for ; Thu, 16 Jan 2003 13:48:10 -0500 (EST) Message-ID: <011301c2bd90$0e14ce20$5c6015ac@T23KEMPF> From: "James Kempf" To: , , Cc: , References: Subject: Re: [Seamoby] CARD between Routers - will CT do? Date: Thu, 16 Jan 2003 10:49:52 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I think the specification should say nothing about intra or inter. I think it should just tell how an AR can verify that an AP identifier obtained by the AR from an MN is connected to an AR IP address that is authorized to route. jak ----- Original Message ----- From: To: ; ; Cc: ; Sent: Thursday, January 16, 2003 9:55 AM Subject: RE: [Seamoby] CARD between Routers - will CT do? > Hi James: > > One suggestion: Referring second diagram below, we could design CARD agnostic to intra or inter classification, but assuming that ARs can establish SAs. Then, we provide subsections on how this would be achieved for intra case and inter case. Of this first subsection will be ready first (as it is easier) and we continue to work on second subsection over time. What do you think? > > Hemant > > -----Original Message----- > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Thursday, January 16, 2003 12:49 PM > To: Hemant Chaskar; funato@docomolabs-usa.com; Chaskar Hemant > (NRC/Boston) > Cc: eunsoo@nec-lab.com; seamoby@ietf.org > Subject: Re: [Seamoby] CARD between Routers - will CT do? > > > What do you mean by an SA? An IPSec SA? If so, how do you propose to have the > routers use that for checking that the AP L2 addresses provided by the MN map > into IP addresses that are authorized to route on the service provider's > network? > > Note that the IESG is requiring that the Security Considerations of all protocol > drafts describe, precisely, how the protocol will be secured. It is no longer > sufficient to say "use IPSec" or "use AAA". Requiring other protocols is OK, but > it must be specified precisely how those protocols are used for securing the > protocol in question. > > jak > > ----- Original Message ----- > From: "Hemant Chaskar" > To: ; > Cc: ; ; > Sent: Wednesday, January 15, 2003 8:24 PM > Subject: Re: [Seamoby] CARD between Routers - will CT do? > > > > Hi Daichi: > > > > I do not think that establishment of SA between ARs should be within scope > > of CARD. We should start from pre-requisite that SA can be established > > between ARs. When ARs belong to same domain, this is simple. When they > > belong to different domain it is harder. In either case, there can be > > variety of ways to establish SAs - pre-shared key, domain specific > > certificates, AAA, credentials exchanged during SLAs or any other means. Why > > should CARD put any restriction on mechanism used to establish SA? > > > > So, instead of > > > > <--Interworking--> > > | > > Intra-domain CARD | Inter-domain CARD > > protocol | protocol > > --------------------|------------------------------ > > Intra-domain SA | Inter-domain SA > > mechanism | mechanism > > (CARD specific?) | (CARD specific?) > > > > I am saying that, if possible, we should try, > > > > > > > > CARD protocol > > ---------------------------------------------- > > | > > Intra-domain SA | Inter-domain SA > > mechanisms | mechanisms > > current/future best | (current/future best > > practices) | practices) > > > > At this point, I cannot vouch for security of MN-report-based CARD approach. > > But, could you describe what kind of attacks do you think MN-report-based > > CARD is vulnerable to? In draft-trossen-seamoby-dycard-00.txt, we have shown > > that certain simple mechanisms can foil security attacks in MN-report-based > > CARD (To the least, if MN tells new AR arbitrary IP address as address of > > old AR, it can be detected). Also, the side effect of attacks, if any, does > > not adversely affect good MNs. But, of course, we could have missed some > > attack possibilities. > > > > > > Hemant > > > > >From: Daichi Funato > > >To: Hemant.Chaskar@nokia.com > > >CC: , , > > >Subject: Re: [Seamoby] CARD between Routers - will CT do? > > >Date: Wed, 15 Jan 2003 19:10:15 -0800 > > > > > >Hi Hemant, > > > > > > > Hemant --> I think we can start protocol design under the assumptions > > >that > > > > (i) old and new ARs can establish SA between them, (ii) they are willing > > >to > > > > participate in CARD protocol. Then, there may not be any need for > > >intra-domain > > > > / inter-domain classification. > > > > > >What kind of security mechanisms are you assuming? > > >I think we should not leave the security mechanisms out of the scope. > > > > > >Especially, MN-report-based CARD is vulnerable to an attacker. > > >How to protect the communication is an essential part of CARD, I think. > > >Actually, IEEE IAPP includes a security mechanism by itself. > > >Do we neglect that part in CARD? > > > > > >IMHO, if CARD can provide secure keys for ARs, these can be used by CT > > >and FMIP as well. This is another type of capability discovery. > > >What do you think? > > > > > >Best regards, > > >Daichi > > > > > >------------------------------------------------------------- > > >Daichi Funato > > >DoCoMo Communications Laboratories USA, Inc. > > > > > >Confidential Note: > > >Privileged/Confidential Information may be contained in this e-mail > > >and any attachment to it. Unless you are the addressee indicated in > > >this e-mail, please notify immediately the sender by reply e-mail > > >that you have received this in error and delete it from your system. > > >You may not use, copy or deliver this e-mail or any information > > >contained in this e-mail to anyone. Thank you very much. > > >------------------------------------------------------------- > > > > > >_______________________________________________ > > >Seamoby mailing list > > >Seamoby@ietf.org > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _________________________________________________________________ > > Add photos to your e-mail with MSN 8. Get 2 months FREE*. > > http://join.msn.com/?page=features/featuredemail > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Jan 16 13:50:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20327 for ; Thu, 16 Jan 2003 13:50:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GJ5Ol14421 for seamoby-archive@odin.ietf.org; Thu, 16 Jan 2003 14:05:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GJ5OJ14418 for ; Thu, 16 Jan 2003 14:05:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20302 for ; Thu, 16 Jan 2003 13:49:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GJ45J14339; Thu, 16 Jan 2003 14:04:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GJ3tJ14309 for ; Thu, 16 Jan 2003 14:03:55 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20229 for ; Thu, 16 Jan 2003 13:48:10 -0500 (EST) Message-ID: <011301c2bd90$0e14ce20$5c6015ac@T23KEMPF> From: "James Kempf" To: , , Cc: , References: Subject: Re: [Seamoby] CARD between Routers - will CT do? Date: Thu, 16 Jan 2003 10:49:52 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I think the specification should say nothing about intra or inter. I think it should just tell how an AR can verify that an AP identifier obtained by the AR from an MN is connected to an AR IP address that is authorized to route. jak ----- Original Message ----- From: To: ; ; Cc: ; Sent: Thursday, January 16, 2003 9:55 AM Subject: RE: [Seamoby] CARD between Routers - will CT do? > Hi James: > > One suggestion: Referring second diagram below, we could design CARD agnostic to intra or inter classification, but assuming that ARs can establish SAs. Then, we provide subsections on how this would be achieved for intra case and inter case. Of this first subsection will be ready first (as it is easier) and we continue to work on second subsection over time. What do you think? > > Hemant > > -----Original Message----- > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Thursday, January 16, 2003 12:49 PM > To: Hemant Chaskar; funato@docomolabs-usa.com; Chaskar Hemant > (NRC/Boston) > Cc: eunsoo@nec-lab.com; seamoby@ietf.org > Subject: Re: [Seamoby] CARD between Routers - will CT do? > > > What do you mean by an SA? An IPSec SA? If so, how do you propose to have the > routers use that for checking that the AP L2 addresses provided by the MN map > into IP addresses that are authorized to route on the service provider's > network? > > Note that the IESG is requiring that the Security Considerations of all protocol > drafts describe, precisely, how the protocol will be secured. It is no longer > sufficient to say "use IPSec" or "use AAA". Requiring other protocols is OK, but > it must be specified precisely how those protocols are used for securing the > protocol in question. > > jak > > ----- Original Message ----- > From: "Hemant Chaskar" > To: ; > Cc: ; ; > Sent: Wednesday, January 15, 2003 8:24 PM > Subject: Re: [Seamoby] CARD between Routers - will CT do? > > > > Hi Daichi: > > > > I do not think that establishment of SA between ARs should be within scope > > of CARD. We should start from pre-requisite that SA can be established > > between ARs. When ARs belong to same domain, this is simple. When they > > belong to different domain it is harder. In either case, there can be > > variety of ways to establish SAs - pre-shared key, domain specific > > certificates, AAA, credentials exchanged during SLAs or any other means. Why > > should CARD put any restriction on mechanism used to establish SA? > > > > So, instead of > > > > <--Interworking--> > > | > > Intra-domain CARD | Inter-domain CARD > > protocol | protocol > > --------------------|------------------------------ > > Intra-domain SA | Inter-domain SA > > mechanism | mechanism > > (CARD specific?) | (CARD specific?) > > > > I am saying that, if possible, we should try, > > > > > > > > CARD protocol > > ---------------------------------------------- > > | > > Intra-domain SA | Inter-domain SA > > mechanisms | mechanisms > > current/future best | (current/future best > > practices) | practices) > > > > At this point, I cannot vouch for security of MN-report-based CARD approach. > > But, could you describe what kind of attacks do you think MN-report-based > > CARD is vulnerable to? In draft-trossen-seamoby-dycard-00.txt, we have shown > > that certain simple mechanisms can foil security attacks in MN-report-based > > CARD (To the least, if MN tells new AR arbitrary IP address as address of > > old AR, it can be detected). Also, the side effect of attacks, if any, does > > not adversely affect good MNs. But, of course, we could have missed some > > attack possibilities. > > > > > > Hemant > > > > >From: Daichi Funato > > >To: Hemant.Chaskar@nokia.com > > >CC: , , > > >Subject: Re: [Seamoby] CARD between Routers - will CT do? > > >Date: Wed, 15 Jan 2003 19:10:15 -0800 > > > > > >Hi Hemant, > > > > > > > Hemant --> I think we can start protocol design under the assumptions > > >that > > > > (i) old and new ARs can establish SA between them, (ii) they are willing > > >to > > > > participate in CARD protocol. Then, there may not be any need for > > >intra-domain > > > > / inter-domain classification. > > > > > >What kind of security mechanisms are you assuming? > > >I think we should not leave the security mechanisms out of the scope. > > > > > >Especially, MN-report-based CARD is vulnerable to an attacker. > > >How to protect the communication is an essential part of CARD, I think. > > >Actually, IEEE IAPP includes a security mechanism by itself. > > >Do we neglect that part in CARD? > > > > > >IMHO, if CARD can provide secure keys for ARs, these can be used by CT > > >and FMIP as well. This is another type of capability discovery. > > >What do you think? > > > > > >Best regards, > > >Daichi > > > > > >------------------------------------------------------------- > > >Daichi Funato > > >DoCoMo Communications Laboratories USA, Inc. > > > > > >Confidential Note: > > >Privileged/Confidential Information may be contained in this e-mail > > >and any attachment to it. Unless you are the addressee indicated in > > >this e-mail, please notify immediately the sender by reply e-mail > > >that you have received this in error and delete it from your system. > > >You may not use, copy or deliver this e-mail or any information > > >contained in this e-mail to anyone. Thank you very much. > > >------------------------------------------------------------- > > > > > >_______________________________________________ > > >Seamoby mailing list > > >Seamoby@ietf.org > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _________________________________________________________________ > > Add photos to your e-mail with MSN 8. Get 2 months FREE*. > > http://join.msn.com/?page=features/featuredemail > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Jan 16 14:50:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22084 for ; Thu, 16 Jan 2003 14:50:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GK4YJ18452; Thu, 16 Jan 2003 15:04:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GK3iJ18416 for ; Thu, 16 Jan 2003 15:03:44 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22035 for ; Thu, 16 Jan 2003 14:47:48 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0GJoCB17460 for ; Thu, 16 Jan 2003 13:50:32 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 16 Jan 2003 13:50:01 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 16 Jan 2003 13:49:54 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CARD between Routers - will CT do? Date: Thu, 16 Jan 2003 14:49:53 -0500 Message-ID: Thread-Topic: [Seamoby] CARD between Routers - will CT do? Thread-Index: AcK9iD2XNFkmd4qsS2OUmvEvxbf3aAACdgow To: , , Cc: , X-OriginalArrivalTime: 16 Jan 2003 19:49:54.0901 (UTC) FILETIME=[710AD850:01C2BD98] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0GK3jJ18417 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Jim, comments inline. -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Thursday, January 16, 2003 12:49 PM To: Hemant Chaskar; funato@docomolabs-usa.com; Chaskar Hemant (NRC/Boston) Cc: eunsoo@nec-lab.com; seamoby@ietf.org Subject: Re: [Seamoby] CARD between Routers - will CT do? What do you mean by an SA? An IPSec SA? ---> By SA, I mean a trust relationship. It can be using an IPSec SA or any other means. They have enough information to authenticate each other. If so, how do you propose to have the routers use that for checking that the AP L2 addresses provided by the MN map into IP addresses that are authorized to route on the service provider's network? ----> We have illustrated one method to do this in our draft. Note that the IESG is requiring that the Security Considerations of all protocol drafts describe, precisely, how the protocol will be secured. It is no longer sufficient to say "use IPSec" or "use AAA". Requiring other protocols is OK, but it must be specified precisely how those protocols are used for securing the protocol in question. -----> OK. jak ----- Original Message ----- From: "Hemant Chaskar" To: ; Cc: ; ; Sent: Wednesday, January 15, 2003 8:24 PM Subject: Re: [Seamoby] CARD between Routers - will CT do? > Hi Daichi: > > I do not think that establishment of SA between ARs should be within scope > of CARD. We should start from pre-requisite that SA can be established > between ARs. When ARs belong to same domain, this is simple. When they > belong to different domain it is harder. In either case, there can be > variety of ways to establish SAs - pre-shared key, domain specific > certificates, AAA, credentials exchanged during SLAs or any other means. Why > should CARD put any restriction on mechanism used to establish SA? > > So, instead of > > <--Interworking--> > | > Intra-domain CARD | Inter-domain CARD > protocol | protocol > --------------------|------------------------------ > Intra-domain SA | Inter-domain SA > mechanism | mechanism > (CARD specific?) | (CARD specific?) > > I am saying that, if possible, we should try, > > > > CARD protocol > ---------------------------------------------- > | > Intra-domain SA | Inter-domain SA > mechanisms | mechanisms > current/future best | (current/future best > practices) | practices) > > At this point, I cannot vouch for security of MN-report-based CARD approach. > But, could you describe what kind of attacks do you think MN-report-based > CARD is vulnerable to? In draft-trossen-seamoby-dycard-00.txt, we have shown > that certain simple mechanisms can foil security attacks in MN-report-based > CARD (To the least, if MN tells new AR arbitrary IP address as address of > old AR, it can be detected). Also, the side effect of attacks, if any, does > not adversely affect good MNs. But, of course, we could have missed some > attack possibilities. > > > Hemant > > >From: Daichi Funato > >To: Hemant.Chaskar@nokia.com > >CC: , , > >Subject: Re: [Seamoby] CARD between Routers - will CT do? > >Date: Wed, 15 Jan 2003 19:10:15 -0800 > > > >Hi Hemant, > > > > > Hemant --> I think we can start protocol design under the assumptions > >that > > > (i) old and new ARs can establish SA between them, (ii) they are willing > >to > > > participate in CARD protocol. Then, there may not be any need for > >intra-domain > > > / inter-domain classification. > > > >What kind of security mechanisms are you assuming? > >I think we should not leave the security mechanisms out of the scope. > > > >Especially, MN-report-based CARD is vulnerable to an attacker. > >How to protect the communication is an essential part of CARD, I think. > >Actually, IEEE IAPP includes a security mechanism by itself. > >Do we neglect that part in CARD? > > > >IMHO, if CARD can provide secure keys for ARs, these can be used by CT > >and FMIP as well. This is another type of capability discovery. > >What do you think? > > > >Best regards, > >Daichi > > > >------------------------------------------------------------- > >Daichi Funato > >DoCoMo Communications Laboratories USA, Inc. > > > >Confidential Note: > >Privileged/Confidential Information may be contained in this e-mail > >and any attachment to it. Unless you are the addressee indicated in > >this e-mail, please notify immediately the sender by reply e-mail > >that you have received this in error and delete it from your system. > >You may not use, copy or deliver this e-mail or any information > >contained in this e-mail to anyone. Thank you very much. > >------------------------------------------------------------- > > > >_______________________________________________ > >Seamoby mailing list > >Seamoby@ietf.org > >https://www1.ietf.org/mailman/listinfo/seamoby > > > _________________________________________________________________ > Add photos to your e-mail with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Jan 16 14:51:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22111 for ; Thu, 16 Jan 2003 14:51:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GK6Ju18543 for seamoby-archive@odin.ietf.org; Thu, 16 Jan 2003 15:06:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GK6JJ18540 for ; Thu, 16 Jan 2003 15:06:19 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22100 for ; Thu, 16 Jan 2003 14:50:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GK4YJ18452; Thu, 16 Jan 2003 15:04:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GK3iJ18416 for ; Thu, 16 Jan 2003 15:03:44 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22035 for ; Thu, 16 Jan 2003 14:47:48 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0GJoCB17460 for ; Thu, 16 Jan 2003 13:50:32 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 16 Jan 2003 13:50:01 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 16 Jan 2003 13:49:54 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CARD between Routers - will CT do? Date: Thu, 16 Jan 2003 14:49:53 -0500 Message-ID: Thread-Topic: [Seamoby] CARD between Routers - will CT do? Thread-Index: AcK9iD2XNFkmd4qsS2OUmvEvxbf3aAACdgow To: , , Cc: , X-OriginalArrivalTime: 16 Jan 2003 19:49:54.0901 (UTC) FILETIME=[710AD850:01C2BD98] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0GK3jJ18417 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Jim, comments inline. -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Thursday, January 16, 2003 12:49 PM To: Hemant Chaskar; funato@docomolabs-usa.com; Chaskar Hemant (NRC/Boston) Cc: eunsoo@nec-lab.com; seamoby@ietf.org Subject: Re: [Seamoby] CARD between Routers - will CT do? What do you mean by an SA? An IPSec SA? ---> By SA, I mean a trust relationship. It can be using an IPSec SA or any other means. They have enough information to authenticate each other. If so, how do you propose to have the routers use that for checking that the AP L2 addresses provided by the MN map into IP addresses that are authorized to route on the service provider's network? ----> We have illustrated one method to do this in our draft. Note that the IESG is requiring that the Security Considerations of all protocol drafts describe, precisely, how the protocol will be secured. It is no longer sufficient to say "use IPSec" or "use AAA". Requiring other protocols is OK, but it must be specified precisely how those protocols are used for securing the protocol in question. -----> OK. jak ----- Original Message ----- From: "Hemant Chaskar" To: ; Cc: ; ; Sent: Wednesday, January 15, 2003 8:24 PM Subject: Re: [Seamoby] CARD between Routers - will CT do? > Hi Daichi: > > I do not think that establishment of SA between ARs should be within scope > of CARD. We should start from pre-requisite that SA can be established > between ARs. When ARs belong to same domain, this is simple. When they > belong to different domain it is harder. In either case, there can be > variety of ways to establish SAs - pre-shared key, domain specific > certificates, AAA, credentials exchanged during SLAs or any other means. Why > should CARD put any restriction on mechanism used to establish SA? > > So, instead of > > <--Interworking--> > | > Intra-domain CARD | Inter-domain CARD > protocol | protocol > --------------------|------------------------------ > Intra-domain SA | Inter-domain SA > mechanism | mechanism > (CARD specific?) | (CARD specific?) > > I am saying that, if possible, we should try, > > > > CARD protocol > ---------------------------------------------- > | > Intra-domain SA | Inter-domain SA > mechanisms | mechanisms > current/future best | (current/future best > practices) | practices) > > At this point, I cannot vouch for security of MN-report-based CARD approach. > But, could you describe what kind of attacks do you think MN-report-based > CARD is vulnerable to? In draft-trossen-seamoby-dycard-00.txt, we have shown > that certain simple mechanisms can foil security attacks in MN-report-based > CARD (To the least, if MN tells new AR arbitrary IP address as address of > old AR, it can be detected). Also, the side effect of attacks, if any, does > not adversely affect good MNs. But, of course, we could have missed some > attack possibilities. > > > Hemant > > >From: Daichi Funato > >To: Hemant.Chaskar@nokia.com > >CC: , , > >Subject: Re: [Seamoby] CARD between Routers - will CT do? > >Date: Wed, 15 Jan 2003 19:10:15 -0800 > > > >Hi Hemant, > > > > > Hemant --> I think we can start protocol design under the assumptions > >that > > > (i) old and new ARs can establish SA between them, (ii) they are willing > >to > > > participate in CARD protocol. Then, there may not be any need for > >intra-domain > > > / inter-domain classification. > > > >What kind of security mechanisms are you assuming? > >I think we should not leave the security mechanisms out of the scope. > > > >Especially, MN-report-based CARD is vulnerable to an attacker. > >How to protect the communication is an essential part of CARD, I think. > >Actually, IEEE IAPP includes a security mechanism by itself. > >Do we neglect that part in CARD? > > > >IMHO, if CARD can provide secure keys for ARs, these can be used by CT > >and FMIP as well. This is another type of capability discovery. > >What do you think? > > > >Best regards, > >Daichi > > > >------------------------------------------------------------- > >Daichi Funato > >DoCoMo Communications Laboratories USA, Inc. > > > >Confidential Note: > >Privileged/Confidential Information may be contained in this e-mail > >and any attachment to it. Unless you are the addressee indicated in > >this e-mail, please notify immediately the sender by reply e-mail > >that you have received this in error and delete it from your system. > >You may not use, copy or deliver this e-mail or any information > >contained in this e-mail to anyone. Thank you very much. > >------------------------------------------------------------- > > > >_______________________________________________ > >Seamoby mailing list > >Seamoby@ietf.org > >https://www1.ietf.org/mailman/listinfo/seamoby > > > _________________________________________________________________ > Add photos to your e-mail with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Jan 16 16:00:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23729 for ; Thu, 16 Jan 2003 16:00:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GLEfJ23913; Thu, 16 Jan 2003 16:14:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GLDKJ23869 for ; Thu, 16 Jan 2003 16:13:20 -0500 Received: from zcars04f.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23627 for ; Thu, 16 Jan 2003 15:57:31 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0GL0aq01480; Thu, 16 Jan 2003 16:00:36 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Jan 2003 16:00:37 -0500 Message-ID: From: "Gary Kenward" To: "'Govind.Krishnamurthi@nokia.com'" , kempf@docomolabs-usa.com, funato@docomolabs-usa.com, Hemant.Chaskar@nokia.com Cc: eunsoo@nec-lab.com, seamoby@ietf.org Subject: RE: [Seamoby] CARD between Routers - will CT do? Date: Thu, 16 Jan 2003 16:00:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2BDA2.4E590566" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2BDA2.4E590566 Content-Type: text/plain; charset="iso-8859-1" Inter-domain CARD: Let me see if I understand this correctly: to perform an inter-system handover based upon CARD, I would need a service agreement between the two operators, CARD at each AR, CARD at the MN, a path and a protocol for transferring information (including "topology information"?) between ARs in two different domains *and* all the aforementioned security overhead. Or, on the other hand, the two operators could agree to mutually configure their networks so that the network controlled handover algorithms direct the mobile to the appropriate AR in the neighbouring domain. The handover algorithms stay basically the same, the operators do not need to exchange topology information (there are other, easier methods for finding out where the access points are mounted, if that was the intent). But no discovery protocol, no AR to AR signalling and no SA required between ARs (other then, perhaps CT, if you believe in CT for seamlessness). Lot's of L2 issues, but they exist in either scenario. Gary > -----Original Message----- > From: Govind.Krishnamurthi@nokia.com > [mailto:Govind.Krishnamurthi@nokia.com] > Sent: January 16, 2003 14:50 > To: kempf@docomolabs-usa.com; funato@docomolabs-usa.com; > Hemant.Chaskar@nokia.com > Cc: eunsoo@nec-lab.com; seamoby@ietf.org > Subject: RE: [Seamoby] CARD between Routers - will CT do? > > > Jim, > comments inline. > > -----Original Message----- > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Thursday, January 16, 2003 12:49 PM > To: Hemant Chaskar; funato@docomolabs-usa.com; Chaskar Hemant > (NRC/Boston) > Cc: eunsoo@nec-lab.com; seamoby@ietf.org > Subject: Re: [Seamoby] CARD between Routers - will CT do? > > > What do you mean by an SA? An IPSec SA? > ---> By SA, I mean a trust relationship. It can be using an > IPSec SA or > any other means. They have enough information to authenticate > each other. > > If so, how do you propose to have the > routers use that for checking that the AP L2 addresses > provided by the MN map > into IP addresses that are authorized to route on the service > provider's > network? > > ----> We have illustrated one method to do this in our draft. > > Note that the IESG is requiring that the Security > Considerations of all protocol > drafts describe, precisely, how the protocol will be secured. > It is no longer > sufficient to say "use IPSec" or "use AAA". Requiring other > protocols is OK, but > it must be specified precisely how those protocols are used > for securing the > protocol in question. > > -----> OK. > > jak > > ----- Original Message ----- > From: "Hemant Chaskar" > To: ; > Cc: ; ; > > Sent: Wednesday, January 15, 2003 8:24 PM > Subject: Re: [Seamoby] CARD between Routers - will CT do? > > > > Hi Daichi: > > > > I do not think that establishment of SA between ARs should > be within scope > > of CARD. We should start from pre-requisite that SA can be > established > > between ARs. When ARs belong to same domain, this is > simple. When they > > belong to different domain it is harder. In either case, > there can be > > variety of ways to establish SAs - pre-shared key, domain specific > > certificates, AAA, credentials exchanged during SLAs or any > other means. Why > > should CARD put any restriction on mechanism used to establish SA? > > > > So, instead of > > > > <--Interworking--> > > | > > Intra-domain CARD | Inter-domain CARD > > protocol | protocol > > --------------------|------------------------------ > > Intra-domain SA | Inter-domain SA > > mechanism | mechanism > > (CARD specific?) | (CARD specific?) > > > > I am saying that, if possible, we should try, > > > > > > > > CARD protocol > > ---------------------------------------------- > > | > > Intra-domain SA | Inter-domain SA > > mechanisms | mechanisms > > current/future best | (current/future best > > practices) | practices) > > > > At this point, I cannot vouch for security of > MN-report-based CARD approach. > > But, could you describe what kind of attacks do you think > MN-report-based > > CARD is vulnerable to? In > draft-trossen-seamoby-dycard-00.txt, we have shown > > that certain simple mechanisms can foil security attacks in > MN-report-based > > CARD (To the least, if MN tells new AR arbitrary IP address > as address of > > old AR, it can be detected). Also, the side effect of > attacks, if any, does > > not adversely affect good MNs. But, of course, we could > have missed some > > attack possibilities. > > > > > > Hemant > > > > >From: Daichi Funato > > >To: Hemant.Chaskar@nokia.com > > >CC: , , > > > >Subject: Re: [Seamoby] CARD between Routers - will CT do? > > >Date: Wed, 15 Jan 2003 19:10:15 -0800 > > > > > >Hi Hemant, > > > > > > > Hemant --> I think we can start protocol design under > the assumptions > > >that > > > > (i) old and new ARs can establish SA between them, (ii) > they are willing > > >to > > > > participate in CARD protocol. Then, there may not be > any need for > > >intra-domain > > > > / inter-domain classification. > > > > > >What kind of security mechanisms are you assuming? > > >I think we should not leave the security mechanisms out of > the scope. > > > > > >Especially, MN-report-based CARD is vulnerable to an attacker. > > >How to protect the communication is an essential part of > CARD, I think. > > >Actually, IEEE IAPP includes a security mechanism by itself. > > >Do we neglect that part in CARD? > > > > > >IMHO, if CARD can provide secure keys for ARs, these can > be used by CT > > >and FMIP as well. This is another type of capability discovery. > > >What do you think? > > > > > >Best regards, > > >Daichi > > > > > >------------------------------------------------------------- > > >Daichi Funato > > >DoCoMo Communications Laboratories USA, Inc. > > > > > >Confidential Note: > > >Privileged/Confidential Information may be contained in this e-mail > > >and any attachment to it. Unless you are the addressee indicated in > > >this e-mail, please notify immediately the sender by reply e-mail > > >that you have received this in error and delete it from > your system. > > >You may not use, copy or deliver this e-mail or any information > > >contained in this e-mail to anyone. Thank you very much. > > >------------------------------------------------------------- > > > > > >_______________________________________________ > > >Seamoby mailing list > > >Seamoby@ietf.org > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _________________________________________________________________ > > Add photos to your e-mail with MSN 8. Get 2 months FREE*. > > http://join.msn.com/?page=features/featuredemail > > > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > ------_=_NextPart_001_01C2BDA2.4E590566 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] CARD between Routers - will CT do?

Inter-domain CARD:

Let me see if I understand this correctly: to perform an inter-system
handover based upon CARD, I would need a service agreement between
the two operators, CARD at each AR, CARD at the MN, a path and a protocol
for transferring information (including "topology information"?)
between ARs in two different domains *and* all the aforementioned security
overhead.

Or, on the other hand, the two operators could agree to mutually configure
their networks so that the network controlled handover algorithms direct the
mobile to the appropriate AR in the neighbouring domain. The handover algorithms
stay basically the same, the operators do not need to exchange topology
information (there are other, easier methods for finding out where the access
points are mounted, if that was the intent). But no discovery protocol, no
AR to AR signalling and no SA required between ARs (other then, perhaps CT,
if you believe in CT for seamlessness).

Lot's of L2 issues, but they exist in either scenario.

Gary

> -----Original Message-----
> From: Govind.Krishnamurthi@nokia.com
> [mailto:Govind.Krishnamurthi@nokia.com]
> Sent: January 16, 2003 14:50
> To: kempf@docomolabs-usa.com; funato@docomolabs-usa.com;
> Hemant.Chaskar@nokia.com
> Cc: eunsoo@nec-lab.com; seamoby@ietf.org
> Subject: RE: [Seamoby] CARD between Routers - will CT do?
>
>
> Jim,
> comments inline.
>
> -----Original Message-----
> From: ext James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: Thursday, January 16, 2003 12:49 PM
> To: Hemant Chaskar; funato@docomolabs-usa.com; Chaskar Hemant
> (NRC/Boston)
> Cc: eunsoo@nec-lab.com; seamoby@ietf.org
> Subject: Re: [Seamoby] CARD between Routers - will CT do?
>
>
> What do you mean by an SA? An IPSec SA?
> ---> By SA, I mean a trust relationship. It can be using an
> IPSec SA or
> any other means. They have enough information to authenticate
> each other.
>
> If so, how do you propose to have the
> routers use that for checking that the AP L2 addresses
> provided by the MN map
> into IP addresses that are authorized to route on the service
> provider's
> network?
>
> ----> We have illustrated one method to do this in our draft.
>
> Note that the IESG is requiring that the Security
> Considerations of all protocol
> drafts describe, precisely, how the protocol will be secured.
> It is no longer
> sufficient to say "use IPSec" or "use AAA". Requiring other
> protocols is OK, but
> it must be specified precisely how those protocols are used
> for securing the
> protocol in question.
>
> -----> OK.
>
>             jak
>
> ----- Original Message -----
> From: "Hemant Chaskar" <hchaskar@hotmail.com>
> To: <funato@docomolabs-usa.com>; <Hemant.Chaskar@nokia.com>
> Cc: <eunsoo@nec-lab.com>; <kempf@docomolabs-usa.com>;
> <seamoby@ietf.org>
> Sent: Wednesday, January 15, 2003 8:24 PM
> Subject: Re: [Seamoby] CARD between Routers - will CT do?
>
>
> > Hi Daichi:
> >
> > I do not think that establishment of SA between ARs should
> be within scope
> > of CARD. We should start from pre-requisite that SA can be
> established
> > between ARs. When ARs belong to same domain, this is
> simple. When they
> > belong to different domain it is harder. In either case,
> there can be
> > variety of ways to establish SAs - pre-shared key, domain specific
> > certificates, AAA, credentials exchanged during SLAs or any
> other means. Why
> > should CARD put any restriction on mechanism used to establish SA?
> >
> > So, instead of
> >
> >                       <--Interworking-->
> >                              |
> >          Intra-domain CARD   |       Inter-domain CARD
> >                protocol      |          protocol
> >          --------------------|------------------------------
> >          Intra-domain SA     |       Inter-domain SA
> >            mechanism         |          mechanism
> >         (CARD specific?)     |       (CARD specific?)
> >
> > I am saying that, if possible, we should try,
> >
> >
> >
> >                        CARD protocol
> >          ----------------------------------------------
> >                               |
> >          Intra-domain SA      |      Inter-domain SA
> >             mechanisms        |         mechanisms
> >         current/future best   |   (current/future best
> >             practices)        |          practices)
> >
> > At this point, I cannot vouch for security of
> MN-report-based CARD approach.
> > But, could you describe what kind of attacks do you think
> MN-report-based
> > CARD is vulnerable to? In
> draft-trossen-seamoby-dycard-00.txt, we have shown
> > that certain simple mechanisms can foil security attacks in
> MN-report-based
> > CARD (To the least, if MN tells new AR arbitrary IP address
> as address of
> > old AR, it can be detected). Also, the side effect of
> attacks, if any, does
> > not adversely affect good MNs. But, of course, we could
> have missed some
> > attack possibilities.
> >
> >
> > Hemant
> >
> > >From: Daichi Funato <funato@docomolabs-usa.com>
> > >To: Hemant.Chaskar@nokia.com
> > >CC: <eunsoo@nec-lab.com>, <kempf@docomolabs-usa.com>,
> <seamoby@ietf.org>
> > >Subject: Re: [Seamoby] CARD between Routers - will CT do?
> > >Date: Wed, 15 Jan 2003 19:10:15 -0800
> > >
> > >Hi Hemant,
> > >
> > > > Hemant --> I think we can start protocol design under
> the assumptions
> > >that
> > > > (i) old and new ARs can establish SA between them, (ii)
> they are willing
> > >to
> > > > participate in CARD protocol. Then, there may not be
> any need for
> > >intra-domain
> > > > / inter-domain classification.
> > >
> > >What kind of security mechanisms are you assuming?
> > >I think we should not leave the security mechanisms out of
> the scope.
> > >
> > >Especially, MN-report-based CARD is vulnerable to an attacker.
> > >How to protect the communication is an essential part of
> CARD, I think.
> > >Actually, IEEE IAPP includes a security mechanism by itself.
> > >Do we neglect that part in CARD?
> > >
> > >IMHO, if CARD can provide secure keys for ARs, these can
> be used by CT
> > >and FMIP as well. This is another type of capability discovery.
> > >What do you think?
> > >
> > >Best regards,
> > >Daichi
> > >
> > >-------------------------------------------------------------
> > >Daichi Funato <funato@docomolabs-usa.com>
> > >DoCoMo Communications Laboratories USA, Inc.
> > >
> > >Confidential Note:
> > >Privileged/Confidential Information may be contained in this e-mail
> > >and any attachment to it. Unless you are the addressee indicated in
> > >this e-mail, please notify immediately the sender by reply e-mail
> > >that you have received this in error and delete it from
> your system.
> > >You may not use, copy or deliver this e-mail or any information
> > >contained in this e-mail to anyone.  Thank you very much.
> > >-------------------------------------------------------------
> > >
> > >_______________________________________________
> > >Seamoby mailing list
> > >Seamoby@ietf.org
> > >https://www1.ietf.org/mailman/listinfo/seamoby
> >
> >
> > _________________________________________________________________
> > Add photos to your e-mail with MSN 8. Get 2 months FREE*.
> > http://join.msn.com/?page=features/featuredemail
> >
> >
>
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

------_=_NextPart_001_01C2BDA2.4E590566-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Jan 16 16:01:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23801 for ; Thu, 16 Jan 2003 16:01:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GLGpO24049 for seamoby-archive@odin.ietf.org; Thu, 16 Jan 2003 16:16:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GLGpJ24046 for ; Thu, 16 Jan 2003 16:16:51 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23771 for ; Thu, 16 Jan 2003 16:01:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GLEfJ23913; Thu, 16 Jan 2003 16:14:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GLDKJ23869 for ; Thu, 16 Jan 2003 16:13:20 -0500 Received: from zcars04f.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23627 for ; Thu, 16 Jan 2003 15:57:31 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0GL0aq01480; Thu, 16 Jan 2003 16:00:36 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Jan 2003 16:00:37 -0500 Message-ID: From: "Gary Kenward" To: "'Govind.Krishnamurthi@nokia.com'" , kempf@docomolabs-usa.com, funato@docomolabs-usa.com, Hemant.Chaskar@nokia.com Cc: eunsoo@nec-lab.com, seamoby@ietf.org Subject: RE: [Seamoby] CARD between Routers - will CT do? Date: Thu, 16 Jan 2003 16:00:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2BDA2.4E590566" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2BDA2.4E590566 Content-Type: text/plain; charset="iso-8859-1" Inter-domain CARD: Let me see if I understand this correctly: to perform an inter-system handover based upon CARD, I would need a service agreement between the two operators, CARD at each AR, CARD at the MN, a path and a protocol for transferring information (including "topology information"?) between ARs in two different domains *and* all the aforementioned security overhead. Or, on the other hand, the two operators could agree to mutually configure their networks so that the network controlled handover algorithms direct the mobile to the appropriate AR in the neighbouring domain. The handover algorithms stay basically the same, the operators do not need to exchange topology information (there are other, easier methods for finding out where the access points are mounted, if that was the intent). But no discovery protocol, no AR to AR signalling and no SA required between ARs (other then, perhaps CT, if you believe in CT for seamlessness). Lot's of L2 issues, but they exist in either scenario. Gary > -----Original Message----- > From: Govind.Krishnamurthi@nokia.com > [mailto:Govind.Krishnamurthi@nokia.com] > Sent: January 16, 2003 14:50 > To: kempf@docomolabs-usa.com; funato@docomolabs-usa.com; > Hemant.Chaskar@nokia.com > Cc: eunsoo@nec-lab.com; seamoby@ietf.org > Subject: RE: [Seamoby] CARD between Routers - will CT do? > > > Jim, > comments inline. > > -----Original Message----- > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Thursday, January 16, 2003 12:49 PM > To: Hemant Chaskar; funato@docomolabs-usa.com; Chaskar Hemant > (NRC/Boston) > Cc: eunsoo@nec-lab.com; seamoby@ietf.org > Subject: Re: [Seamoby] CARD between Routers - will CT do? > > > What do you mean by an SA? An IPSec SA? > ---> By SA, I mean a trust relationship. It can be using an > IPSec SA or > any other means. They have enough information to authenticate > each other. > > If so, how do you propose to have the > routers use that for checking that the AP L2 addresses > provided by the MN map > into IP addresses that are authorized to route on the service > provider's > network? > > ----> We have illustrated one method to do this in our draft. > > Note that the IESG is requiring that the Security > Considerations of all protocol > drafts describe, precisely, how the protocol will be secured. > It is no longer > sufficient to say "use IPSec" or "use AAA". Requiring other > protocols is OK, but > it must be specified precisely how those protocols are used > for securing the > protocol in question. > > -----> OK. > > jak > > ----- Original Message ----- > From: "Hemant Chaskar" > To: ; > Cc: ; ; > > Sent: Wednesday, January 15, 2003 8:24 PM > Subject: Re: [Seamoby] CARD between Routers - will CT do? > > > > Hi Daichi: > > > > I do not think that establishment of SA between ARs should > be within scope > > of CARD. We should start from pre-requisite that SA can be > established > > between ARs. When ARs belong to same domain, this is > simple. When they > > belong to different domain it is harder. In either case, > there can be > > variety of ways to establish SAs - pre-shared key, domain specific > > certificates, AAA, credentials exchanged during SLAs or any > other means. Why > > should CARD put any restriction on mechanism used to establish SA? > > > > So, instead of > > > > <--Interworking--> > > | > > Intra-domain CARD | Inter-domain CARD > > protocol | protocol > > --------------------|------------------------------ > > Intra-domain SA | Inter-domain SA > > mechanism | mechanism > > (CARD specific?) | (CARD specific?) > > > > I am saying that, if possible, we should try, > > > > > > > > CARD protocol > > ---------------------------------------------- > > | > > Intra-domain SA | Inter-domain SA > > mechanisms | mechanisms > > current/future best | (current/future best > > practices) | practices) > > > > At this point, I cannot vouch for security of > MN-report-based CARD approach. > > But, could you describe what kind of attacks do you think > MN-report-based > > CARD is vulnerable to? In > draft-trossen-seamoby-dycard-00.txt, we have shown > > that certain simple mechanisms can foil security attacks in > MN-report-based > > CARD (To the least, if MN tells new AR arbitrary IP address > as address of > > old AR, it can be detected). Also, the side effect of > attacks, if any, does > > not adversely affect good MNs. But, of course, we could > have missed some > > attack possibilities. > > > > > > Hemant > > > > >From: Daichi Funato > > >To: Hemant.Chaskar@nokia.com > > >CC: , , > > > >Subject: Re: [Seamoby] CARD between Routers - will CT do? > > >Date: Wed, 15 Jan 2003 19:10:15 -0800 > > > > > >Hi Hemant, > > > > > > > Hemant --> I think we can start protocol design under > the assumptions > > >that > > > > (i) old and new ARs can establish SA between them, (ii) > they are willing > > >to > > > > participate in CARD protocol. Then, there may not be > any need for > > >intra-domain > > > > / inter-domain classification. > > > > > >What kind of security mechanisms are you assuming? > > >I think we should not leave the security mechanisms out of > the scope. > > > > > >Especially, MN-report-based CARD is vulnerable to an attacker. > > >How to protect the communication is an essential part of > CARD, I think. > > >Actually, IEEE IAPP includes a security mechanism by itself. > > >Do we neglect that part in CARD? > > > > > >IMHO, if CARD can provide secure keys for ARs, these can > be used by CT > > >and FMIP as well. This is another type of capability discovery. > > >What do you think? > > > > > >Best regards, > > >Daichi > > > > > >------------------------------------------------------------- > > >Daichi Funato > > >DoCoMo Communications Laboratories USA, Inc. > > > > > >Confidential Note: > > >Privileged/Confidential Information may be contained in this e-mail > > >and any attachment to it. Unless you are the addressee indicated in > > >this e-mail, please notify immediately the sender by reply e-mail > > >that you have received this in error and delete it from > your system. > > >You may not use, copy or deliver this e-mail or any information > > >contained in this e-mail to anyone. Thank you very much. > > >------------------------------------------------------------- > > > > > >_______________________________________________ > > >Seamoby mailing list > > >Seamoby@ietf.org > > >https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _________________________________________________________________ > > Add photos to your e-mail with MSN 8. Get 2 months FREE*. > > http://join.msn.com/?page=features/featuredemail > > > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > ------_=_NextPart_001_01C2BDA2.4E590566 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] CARD between Routers - will CT do?

Inter-domain CARD:

Let me see if I understand this correctly: to perform an inter-system
handover based upon CARD, I would need a service agreement between
the two operators, CARD at each AR, CARD at the MN, a path and a protocol
for transferring information (including "topology information"?)
between ARs in two different domains *and* all the aforementioned security
overhead.

Or, on the other hand, the two operators could agree to mutually configure
their networks so that the network controlled handover algorithms direct the
mobile to the appropriate AR in the neighbouring domain. The handover algorithms
stay basically the same, the operators do not need to exchange topology
information (there are other, easier methods for finding out where the access
points are mounted, if that was the intent). But no discovery protocol, no
AR to AR signalling and no SA required between ARs (other then, perhaps CT,
if you believe in CT for seamlessness).

Lot's of L2 issues, but they exist in either scenario.

Gary

> -----Original Message-----
> From: Govind.Krishnamurthi@nokia.com
> [mailto:Govind.Krishnamurthi@nokia.com]
> Sent: January 16, 2003 14:50
> To: kempf@docomolabs-usa.com; funato@docomolabs-usa.com;
> Hemant.Chaskar@nokia.com
> Cc: eunsoo@nec-lab.com; seamoby@ietf.org
> Subject: RE: [Seamoby] CARD between Routers - will CT do?
>
>
> Jim,
> comments inline.
>
> -----Original Message-----
> From: ext James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: Thursday, January 16, 2003 12:49 PM
> To: Hemant Chaskar; funato@docomolabs-usa.com; Chaskar Hemant
> (NRC/Boston)
> Cc: eunsoo@nec-lab.com; seamoby@ietf.org
> Subject: Re: [Seamoby] CARD between Routers - will CT do?
>
>
> What do you mean by an SA? An IPSec SA?
> ---> By SA, I mean a trust relationship. It can be using an
> IPSec SA or
> any other means. They have enough information to authenticate
> each other.
>
> If so, how do you propose to have the
> routers use that for checking that the AP L2 addresses
> provided by the MN map
> into IP addresses that are authorized to route on the service
> provider's
> network?
>
> ----> We have illustrated one method to do this in our draft.
>
> Note that the IESG is requiring that the Security
> Considerations of all protocol
> drafts describe, precisely, how the protocol will be secured.
> It is no longer
> sufficient to say "use IPSec" or "use AAA". Requiring other
> protocols is OK, but
> it must be specified precisely how those protocols are used
> for securing the
> protocol in question.
>
> -----> OK.
>
>             jak
>
> ----- Original Message -----
> From: "Hemant Chaskar" <hchaskar@hotmail.com>
> To: <funato@docomolabs-usa.com>; <Hemant.Chaskar@nokia.com>
> Cc: <eunsoo@nec-lab.com>; <kempf@docomolabs-usa.com>;
> <seamoby@ietf.org>
> Sent: Wednesday, January 15, 2003 8:24 PM
> Subject: Re: [Seamoby] CARD between Routers - will CT do?
>
>
> > Hi Daichi:
> >
> > I do not think that establishment of SA between ARs should
> be within scope
> > of CARD. We should start from pre-requisite that SA can be
> established
> > between ARs. When ARs belong to same domain, this is
> simple. When they
> > belong to different domain it is harder. In either case,
> there can be
> > variety of ways to establish SAs - pre-shared key, domain specific
> > certificates, AAA, credentials exchanged during SLAs or any
> other means. Why
> > should CARD put any restriction on mechanism used to establish SA?
> >
> > So, instead of
> >
> >                       <--Interworking-->
> >                              |
> >          Intra-domain CARD   |       Inter-domain CARD
> >                protocol      |          protocol
> >          --------------------|------------------------------
> >          Intra-domain SA     |       Inter-domain SA
> >            mechanism         |          mechanism
> >         (CARD specific?)     |       (CARD specific?)
> >
> > I am saying that, if possible, we should try,
> >
> >
> >
> >                        CARD protocol
> >          ----------------------------------------------
> >                               |
> >          Intra-domain SA      |      Inter-domain SA
> >             mechanisms        |         mechanisms
> >         current/future best   |   (current/future best
> >             practices)        |          practices)
> >
> > At this point, I cannot vouch for security of
> MN-report-based CARD approach.
> > But, could you describe what kind of attacks do you think
> MN-report-based
> > CARD is vulnerable to? In
> draft-trossen-seamoby-dycard-00.txt, we have shown
> > that certain simple mechanisms can foil security attacks in
> MN-report-based
> > CARD (To the least, if MN tells new AR arbitrary IP address
> as address of
> > old AR, it can be detected). Also, the side effect of
> attacks, if any, does
> > not adversely affect good MNs. But, of course, we could
> have missed some
> > attack possibilities.
> >
> >
> > Hemant
> >
> > >From: Daichi Funato <funato@docomolabs-usa.com>
> > >To: Hemant.Chaskar@nokia.com
> > >CC: <eunsoo@nec-lab.com>, <kempf@docomolabs-usa.com>,
> <seamoby@ietf.org>
> > >Subject: Re: [Seamoby] CARD between Routers - will CT do?
> > >Date: Wed, 15 Jan 2003 19:10:15 -0800
> > >
> > >Hi Hemant,
> > >
> > > > Hemant --> I think we can start protocol design under
> the assumptions
> > >that
> > > > (i) old and new ARs can establish SA between them, (ii)
> they are willing
> > >to
> > > > participate in CARD protocol. Then, there may not be
> any need for
> > >intra-domain
> > > > / inter-domain classification.
> > >
> > >What kind of security mechanisms are you assuming?
> > >I think we should not leave the security mechanisms out of
> the scope.
> > >
> > >Especially, MN-report-based CARD is vulnerable to an attacker.
> > >How to protect the communication is an essential part of
> CARD, I think.
> > >Actually, IEEE IAPP includes a security mechanism by itself.
> > >Do we neglect that part in CARD?
> > >
> > >IMHO, if CARD can provide secure keys for ARs, these can
> be used by CT
> > >and FMIP as well. This is another type of capability discovery.
> > >What do you think?
> > >
> > >Best regards,
> > >Daichi
> > >
> > >-------------------------------------------------------------
> > >Daichi Funato <funato@docomolabs-usa.com>
> > >DoCoMo Communications Laboratories USA, Inc.
> > >
> > >Confidential Note:
> > >Privileged/Confidential Information may be contained in this e-mail
> > >and any attachment to it. Unless you are the addressee indicated in
> > >this e-mail, please notify immediately the sender by reply e-mail
> > >that you have received this in error and delete it from
> your system.
> > >You may not use, copy or deliver this e-mail or any information
> > >contained in this e-mail to anyone.  Thank you very much.
> > >-------------------------------------------------------------
> > >
> > >_______________________________________________
> > >Seamoby mailing list
> > >Seamoby@ietf.org
> > >https://www1.ietf.org/mailman/listinfo/seamoby
> >
> >
> > _________________________________________________________________
> > Add photos to your e-mail with MSN 8. Get 2 months FREE*.
> > http://join.msn.com/?page=features/featuredemail
> >
> >
>
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

------_=_NextPart_001_01C2BDA2.4E590566-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Jan 16 16:52:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24985 for ; Thu, 16 Jan 2003 16:52:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GM6bJ27253; Thu, 16 Jan 2003 17:06:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GM5bJ27191 for ; Thu, 16 Jan 2003 17:05:37 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24968 for ; Thu, 16 Jan 2003 16:49:48 -0500 (EST) Received: from eunsoo ([138.15.107.234]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 16 Jan 2003 16:53:10 -0500 Message-ID: <013101c2bdc3$2084ed50$ea6b0f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , , References: <010f01c2bd8f$b1743070$5c6015ac@T23KEMPF> Subject: Re: [Seamoby] CARD between Routers - will CT do? Date: Thu, 16 Jan 2003 16:55:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 16 Jan 2003 21:53:10.0923 (UTC) FILETIME=[A96A3DB0:01C2BDA9] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Please let me repeat once. The CARD protocol does NOT disclose the INTERNAL topology of the network that the MNs cannot figure out. Also it is not necessary for mobility management. It discloses only the AR's IP addresses, AP's MAC addresses and such things. Disclosing capabilities (attributes) can be limited by policies. So I am wondering what's the concern of the providers in exchanging the information that is anyway given away to the MNs. I am not sure that trusting another provider with any kind of cooperation relationship (such as roaming agreement) is more risky than trusting the MNs. Anyway this is about network provider's policies or business frameworks. I am not so sure we should spend lots of time on clarifying the providers' policies. Of course, if providers come out and provider their opinions, it is more than welcome. While we work on security measures for CARD, I think, we will know what's the requirements for inter-provider operation of CARD. I don't agree if you suggest we forget about inter-provider operation in designing the CARD protocol and create something only for intra-provider operation and then start looking into the inter-provider operation. For it might lead to a protocol that is not suitable at all for inter-provider operation in the beginning. I think we should keep in mind all the way that it is most preferable to use the same protocol for inter-provider operation as well as intra-provider operation. I agree to looking into intra-provider design first only with the intention to extend the same protocol for the inter-provider operation immediately rather than trying to create totally different two sets of protocols. With that in mind, we can start with a base discovery mechanism and look into the security measures for it. We may find that the security measures are very different in two cases, that is, inter-provider operation and intra-provider operation, or they are almost the same. Then we will be able to say what is the (technically) feasible approach for CARD over inter-provider roaming. So the most important thing for our progress is picking (a) base discovery mechanism(s) that we want to look into and design security measures on. How do we want to go about this? We start looking into the two individual proposals or any new or merged proposals from the design team? What's the status of the design team about it? Regards, Eunsoo ----- Original Message ----- From: "James Kempf" To: ; ; Sent: Thursday, January 16, 2003 10:47 AM Subject: Re: [Seamoby] CARD between Routers - will CT do? > With my service provider hat on, I'm saying that I don't think our operations > guys will approve using the IP address from another service provider's internal > topology in the fashion that you and Eunsoo are advocating. Regardless of > whether or not there is a Radius connection. if the MN sends it, our RAs will > simply be configured to reject it. Therefore, I think we should now try to > concentrate on the intra-provider case now, and deal with the interprovider case > later. > > Other service providers, want to comment? > > jak > > > ----- Original Message ----- > From: > To: ; ; > Sent: Thursday, January 16, 2003 9:52 AM > Subject: RE: [Seamoby] CARD between Routers - will CT do? > > > > Hi James: > > > > I am not sure why CARD needs to expose "internal" topology. But, to emphasize > it, we can add a guideline that > > > > (iii) CARD SHOULD/MUST not export any information between domains other than > AR addresses, Link layer IDs and capabilities. > > > > (The above information is already exposed to third parties, i.e., MNs > connecting to networks. So, it is not secret anymore.) > > > > Are you suggesting use of Radius to establish SAs (possible) or for performing > CARD (not sure)? > > > > Hemant > > > > -----Original Message----- > > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: Thursday, January 16, 2003 12:22 PM > > To: Chaskar Hemant (NRC/Boston); eunsoo@nec-lab.com; seamoby@ietf.org > > Subject: Re: [Seamoby] CARD between Routers - will CT do? > > > > > > > Hemant --> I think we can start protocol design under the assumptions that > (i) > > old and new ARs can establish SA between them, (ii) they are willing to > > participate in CARD protocol. Then, there may not be any need for intra-domain > / > > inter-domain classification. > > > > > > > Alternatively, an intermediary that would be more acceptable, such as a Radius > > server, could be used. My initial point is that the two providers don't want > to > > expose their internal topology, even if they have an SA allowing > inter-provider > > handover. > > > > jak > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Jan 16 16:53:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25010 for ; Thu, 16 Jan 2003 16:53:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GM8YM27977 for seamoby-archive@odin.ietf.org; Thu, 16 Jan 2003 17:08:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GM8YJ27974 for ; Thu, 16 Jan 2003 17:08:34 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24999 for ; Thu, 16 Jan 2003 16:52:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GM6bJ27253; Thu, 16 Jan 2003 17:06:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GM5bJ27191 for ; Thu, 16 Jan 2003 17:05:37 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24968 for ; Thu, 16 Jan 2003 16:49:48 -0500 (EST) Received: from eunsoo ([138.15.107.234]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 16 Jan 2003 16:53:10 -0500 Message-ID: <013101c2bdc3$2084ed50$ea6b0f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , , References: <010f01c2bd8f$b1743070$5c6015ac@T23KEMPF> Subject: Re: [Seamoby] CARD between Routers - will CT do? Date: Thu, 16 Jan 2003 16:55:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 16 Jan 2003 21:53:10.0923 (UTC) FILETIME=[A96A3DB0:01C2BDA9] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Please let me repeat once. The CARD protocol does NOT disclose the INTERNAL topology of the network that the MNs cannot figure out. Also it is not necessary for mobility management. It discloses only the AR's IP addresses, AP's MAC addresses and such things. Disclosing capabilities (attributes) can be limited by policies. So I am wondering what's the concern of the providers in exchanging the information that is anyway given away to the MNs. I am not sure that trusting another provider with any kind of cooperation relationship (such as roaming agreement) is more risky than trusting the MNs. Anyway this is about network provider's policies or business frameworks. I am not so sure we should spend lots of time on clarifying the providers' policies. Of course, if providers come out and provider their opinions, it is more than welcome. While we work on security measures for CARD, I think, we will know what's the requirements for inter-provider operation of CARD. I don't agree if you suggest we forget about inter-provider operation in designing the CARD protocol and create something only for intra-provider operation and then start looking into the inter-provider operation. For it might lead to a protocol that is not suitable at all for inter-provider operation in the beginning. I think we should keep in mind all the way that it is most preferable to use the same protocol for inter-provider operation as well as intra-provider operation. I agree to looking into intra-provider design first only with the intention to extend the same protocol for the inter-provider operation immediately rather than trying to create totally different two sets of protocols. With that in mind, we can start with a base discovery mechanism and look into the security measures for it. We may find that the security measures are very different in two cases, that is, inter-provider operation and intra-provider operation, or they are almost the same. Then we will be able to say what is the (technically) feasible approach for CARD over inter-provider roaming. So the most important thing for our progress is picking (a) base discovery mechanism(s) that we want to look into and design security measures on. How do we want to go about this? We start looking into the two individual proposals or any new or merged proposals from the design team? What's the status of the design team about it? Regards, Eunsoo ----- Original Message ----- From: "James Kempf" To: ; ; Sent: Thursday, January 16, 2003 10:47 AM Subject: Re: [Seamoby] CARD between Routers - will CT do? > With my service provider hat on, I'm saying that I don't think our operations > guys will approve using the IP address from another service provider's internal > topology in the fashion that you and Eunsoo are advocating. Regardless of > whether or not there is a Radius connection. if the MN sends it, our RAs will > simply be configured to reject it. Therefore, I think we should now try to > concentrate on the intra-provider case now, and deal with the interprovider case > later. > > Other service providers, want to comment? > > jak > > > ----- Original Message ----- > From: > To: ; ; > Sent: Thursday, January 16, 2003 9:52 AM > Subject: RE: [Seamoby] CARD between Routers - will CT do? > > > > Hi James: > > > > I am not sure why CARD needs to expose "internal" topology. But, to emphasize > it, we can add a guideline that > > > > (iii) CARD SHOULD/MUST not export any information between domains other than > AR addresses, Link layer IDs and capabilities. > > > > (The above information is already exposed to third parties, i.e., MNs > connecting to networks. So, it is not secret anymore.) > > > > Are you suggesting use of Radius to establish SAs (possible) or for performing > CARD (not sure)? > > > > Hemant > > > > -----Original Message----- > > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: Thursday, January 16, 2003 12:22 PM > > To: Chaskar Hemant (NRC/Boston); eunsoo@nec-lab.com; seamoby@ietf.org > > Subject: Re: [Seamoby] CARD between Routers - will CT do? > > > > > > > Hemant --> I think we can start protocol design under the assumptions that > (i) > > old and new ARs can establish SA between them, (ii) they are willing to > > participate in CARD protocol. Then, there may not be any need for intra-domain > / > > inter-domain classification. > > > > > > > Alternatively, an intermediary that would be more acceptable, such as a Radius > > server, could be used. My initial point is that the two providers don't want > to > > expose their internal topology, even if they have an SA allowing > inter-provider > > handover. > > > > jak > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Jan 16 19:34:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27728 for ; Thu, 16 Jan 2003 19:34:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0H0nQJ04805; Thu, 16 Jan 2003 19:49:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0H0gDJ04540 for ; Thu, 16 Jan 2003 19:42:13 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27480 for ; Thu, 16 Jan 2003 19:26:22 -0500 (EST) Message-ID: <020a01c2bdbf$4d854ce0$5c6015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , , References: <010f01c2bd8f$b1743070$5c6015ac@T23KEMPF> <013101c2bdc3$2084ed50$ea6b0f8a@eunsoo> Subject: Re: [Seamoby] CARD between Routers - will CT do? Date: Thu, 16 Jan 2003 16:28:04 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Eunsoo, The design team is still active and tasked with completing the proposal that they started last fall. Therefore, I think we should terminate the circular discussion we seem to be having on this list and let them get on with their job. jak ----- Original Message ----- From: "Eunsoo Shim" To: "James Kempf" ; ; Sent: Thursday, January 16, 2003 4:55 PM Subject: Re: [Seamoby] CARD between Routers - will CT do? > Please let me repeat once. > The CARD protocol does NOT disclose the INTERNAL topology of the network > that the MNs cannot figure out. > Also it is not necessary for mobility management. It discloses only the AR's > IP addresses, AP's MAC addresses and such things. Disclosing capabilities > (attributes) can be limited by policies. > > So I am wondering what's the concern of the providers in exchanging the > information that is anyway given away to the MNs. > I am not sure that trusting another provider with any kind of cooperation > relationship (such as roaming agreement) is more risky than trusting the > MNs. > Anyway this is about network provider's policies or business frameworks. I > am not so sure we should spend lots of time on clarifying the providers' > policies. Of course, if providers come out and provider their opinions, it > is more than welcome. > > While we work on security measures for CARD, I think, we will know what's > the requirements for inter-provider operation of CARD. I don't agree if you > suggest we forget about inter-provider operation in designing the CARD > protocol and create something only for intra-provider operation and then > start looking into the inter-provider operation. For it might lead to a > protocol that is not suitable at all for inter-provider operation in the > beginning. I think we should keep in mind all the way that it is most > preferable to use the same protocol for inter-provider operation as well as > intra-provider operation. I agree to looking into intra-provider design > first only with the intention to extend the same protocol for the > inter-provider operation immediately rather than trying to create totally > different two sets of protocols. > With that in mind, we can start with a base discovery mechanism and look > into the security measures for it. We may find that the security measures > are very different in two cases, that is, inter-provider operation and > intra-provider operation, or they are almost the same. Then we will be able > to say what is the (technically) feasible approach for CARD over > inter-provider roaming. > > So the most important thing for our progress is picking (a) base discovery > mechanism(s) that we want to look into and design security measures on. > > How do we want to go about this? We start looking into the two individual > proposals or any new or merged proposals from the design team? What's the > status of the design team about it? > > Regards, > > Eunsoo > > > ----- Original Message ----- > From: "James Kempf" > To: ; ; > Sent: Thursday, January 16, 2003 10:47 AM > Subject: Re: [Seamoby] CARD between Routers - will CT do? > > > > With my service provider hat on, I'm saying that I don't think our > operations > > guys will approve using the IP address from another service provider's > internal > > topology in the fashion that you and Eunsoo are advocating. Regardless of > > whether or not there is a Radius connection. if the MN sends it, our RAs > will > > simply be configured to reject it. Therefore, I think we should now try to > > concentrate on the intra-provider case now, and deal with the > interprovider case > > later. > > > > Other service providers, want to comment? > > > > jak > > > > > > ----- Original Message ----- > > From: > > To: ; ; > > Sent: Thursday, January 16, 2003 9:52 AM > > Subject: RE: [Seamoby] CARD between Routers - will CT do? > > > > > > > Hi James: > > > > > > I am not sure why CARD needs to expose "internal" topology. But, to > emphasize > > it, we can add a guideline that > > > > > > (iii) CARD SHOULD/MUST not export any information between domains other > than > > AR addresses, Link layer IDs and capabilities. > > > > > > (The above information is already exposed to third parties, i.e., MNs > > connecting to networks. So, it is not secret anymore.) > > > > > > Are you suggesting use of Radius to establish SAs (possible) or for > performing > > CARD (not sure)? > > > > > > Hemant > > > > > > -----Original Message----- > > > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > > > Sent: Thursday, January 16, 2003 12:22 PM > > > To: Chaskar Hemant (NRC/Boston); eunsoo@nec-lab.com; seamoby@ietf.org > > > Subject: Re: [Seamoby] CARD between Routers - will CT do? > > > > > > > > > > Hemant --> I think we can start protocol design under the assumptions > that > > (i) > > > old and new ARs can establish SA between them, (ii) they are willing to > > > participate in CARD protocol. Then, there may not be any need for > intra-domain > > / > > > inter-domain classification. > > > > > > > > > > Alternatively, an intermediary that would be more acceptable, such as a > Radius > > > server, could be used. My initial point is that the two providers don't > want > > to > > > expose their internal topology, even if they have an SA allowing > > inter-provider > > > handover. > > > > > > jak > > > > > > > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Jan 16 19:35:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27770 for ; Thu, 16 Jan 2003 19:35:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0H0oaZ04962 for seamoby-archive@odin.ietf.org; Thu, 16 Jan 2003 19:50:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0H0oaJ04959 for ; Thu, 16 Jan 2003 19:50:36 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27742 for ; Thu, 16 Jan 2003 19:34:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0H0nQJ04805; Thu, 16 Jan 2003 19:49:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0H0gDJ04540 for ; Thu, 16 Jan 2003 19:42:13 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27480 for ; Thu, 16 Jan 2003 19:26:22 -0500 (EST) Message-ID: <020a01c2bdbf$4d854ce0$5c6015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , , References: <010f01c2bd8f$b1743070$5c6015ac@T23KEMPF> <013101c2bdc3$2084ed50$ea6b0f8a@eunsoo> Subject: Re: [Seamoby] CARD between Routers - will CT do? Date: Thu, 16 Jan 2003 16:28:04 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Eunsoo, The design team is still active and tasked with completing the proposal that they started last fall. Therefore, I think we should terminate the circular discussion we seem to be having on this list and let them get on with their job. jak ----- Original Message ----- From: "Eunsoo Shim" To: "James Kempf" ; ; Sent: Thursday, January 16, 2003 4:55 PM Subject: Re: [Seamoby] CARD between Routers - will CT do? > Please let me repeat once. > The CARD protocol does NOT disclose the INTERNAL topology of the network > that the MNs cannot figure out. > Also it is not necessary for mobility management. It discloses only the AR's > IP addresses, AP's MAC addresses and such things. Disclosing capabilities > (attributes) can be limited by policies. > > So I am wondering what's the concern of the providers in exchanging the > information that is anyway given away to the MNs. > I am not sure that trusting another provider with any kind of cooperation > relationship (such as roaming agreement) is more risky than trusting the > MNs. > Anyway this is about network provider's policies or business frameworks. I > am not so sure we should spend lots of time on clarifying the providers' > policies. Of course, if providers come out and provider their opinions, it > is more than welcome. > > While we work on security measures for CARD, I think, we will know what's > the requirements for inter-provider operation of CARD. I don't agree if you > suggest we forget about inter-provider operation in designing the CARD > protocol and create something only for intra-provider operation and then > start looking into the inter-provider operation. For it might lead to a > protocol that is not suitable at all for inter-provider operation in the > beginning. I think we should keep in mind all the way that it is most > preferable to use the same protocol for inter-provider operation as well as > intra-provider operation. I agree to looking into intra-provider design > first only with the intention to extend the same protocol for the > inter-provider operation immediately rather than trying to create totally > different two sets of protocols. > With that in mind, we can start with a base discovery mechanism and look > into the security measures for it. We may find that the security measures > are very different in two cases, that is, inter-provider operation and > intra-provider operation, or they are almost the same. Then we will be able > to say what is the (technically) feasible approach for CARD over > inter-provider roaming. > > So the most important thing for our progress is picking (a) base discovery > mechanism(s) that we want to look into and design security measures on. > > How do we want to go about this? We start looking into the two individual > proposals or any new or merged proposals from the design team? What's the > status of the design team about it? > > Regards, > > Eunsoo > > > ----- Original Message ----- > From: "James Kempf" > To: ; ; > Sent: Thursday, January 16, 2003 10:47 AM > Subject: Re: [Seamoby] CARD between Routers - will CT do? > > > > With my service provider hat on, I'm saying that I don't think our > operations > > guys will approve using the IP address from another service provider's > internal > > topology in the fashion that you and Eunsoo are advocating. Regardless of > > whether or not there is a Radius connection. if the MN sends it, our RAs > will > > simply be configured to reject it. Therefore, I think we should now try to > > concentrate on the intra-provider case now, and deal with the > interprovider case > > later. > > > > Other service providers, want to comment? > > > > jak > > > > > > ----- Original Message ----- > > From: > > To: ; ; > > Sent: Thursday, January 16, 2003 9:52 AM > > Subject: RE: [Seamoby] CARD between Routers - will CT do? > > > > > > > Hi James: > > > > > > I am not sure why CARD needs to expose "internal" topology. But, to > emphasize > > it, we can add a guideline that > > > > > > (iii) CARD SHOULD/MUST not export any information between domains other > than > > AR addresses, Link layer IDs and capabilities. > > > > > > (The above information is already exposed to third parties, i.e., MNs > > connecting to networks. So, it is not secret anymore.) > > > > > > Are you suggesting use of Radius to establish SAs (possible) or for > performing > > CARD (not sure)? > > > > > > Hemant > > > > > > -----Original Message----- > > > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > > > Sent: Thursday, January 16, 2003 12:22 PM > > > To: Chaskar Hemant (NRC/Boston); eunsoo@nec-lab.com; seamoby@ietf.org > > > Subject: Re: [Seamoby] CARD between Routers - will CT do? > > > > > > > > > > Hemant --> I think we can start protocol design under the assumptions > that > > (i) > > > old and new ARs can establish SA between them, (ii) they are willing to > > > participate in CARD protocol. Then, there may not be any need for > intra-domain > > / > > > inter-domain classification. > > > > > > > > > > Alternatively, an intermediary that would be more acceptable, such as a > Radius > > > server, could be used. My initial point is that the two providers don't > want > > to > > > expose their internal topology, even if they have an SA allowing > > inter-provider > > > handover. > > > > > > jak > > > > > > > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Thu Jan 16 22:28:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01003 for ; Thu, 16 Jan 2003 22:28:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0H3gVJ15280; Thu, 16 Jan 2003 22:42:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0H3fRJ15222 for ; Thu, 16 Jan 2003 22:41:27 -0500 Received: from hotmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00962 for ; Thu, 16 Jan 2003 22:25:31 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 16 Jan 2003 19:28:54 -0800 X-Originating-IP: [138.15.107.234] From: "Eunsoo Shim" To: "James Kempf" , , References: <010f01c2bd8f$b1743070$5c6015ac@T23KEMPF> <013101c2bdc3$2084ed50$ea6b0f8a@eunsoo> <020a01c2bdbf$4d854ce0$5c6015ac@T23KEMPF> Subject: Re: [Seamoby] CARD between Routers - will CT do? Date: Thu, 16 Jan 2003 22:30:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Message-ID: X-OriginalArrivalTime: 17 Jan 2003 03:28:54.0153 (UTC) FILETIME=[8FB73790:01C2BDD8] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > The design team is still active and tasked with completing the proposal that > they started last fall. > > Therefore, I think we should terminate the circular discussion we seem to be > having on this list and let them get on with their job. > James, I agree with you. We need the proposal from the design team for further discussion, at least, about security measures. Regards, Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Thu Jan 16 22:28:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01020 for ; Thu, 16 Jan 2003 22:28:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0H3i3u15338 for seamoby-archive@odin.ietf.org; Thu, 16 Jan 2003 22:44:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0H3i3J15335 for ; Thu, 16 Jan 2003 22:44:03 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01017 for ; Thu, 16 Jan 2003 22:28:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0H3gVJ15280; Thu, 16 Jan 2003 22:42:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0H3fRJ15222 for ; Thu, 16 Jan 2003 22:41:27 -0500 Received: from hotmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00962 for ; Thu, 16 Jan 2003 22:25:31 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 16 Jan 2003 19:28:54 -0800 X-Originating-IP: [138.15.107.234] From: "Eunsoo Shim" To: "James Kempf" , , References: <010f01c2bd8f$b1743070$5c6015ac@T23KEMPF> <013101c2bdc3$2084ed50$ea6b0f8a@eunsoo> <020a01c2bdbf$4d854ce0$5c6015ac@T23KEMPF> Subject: Re: [Seamoby] CARD between Routers - will CT do? Date: Thu, 16 Jan 2003 22:30:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Message-ID: X-OriginalArrivalTime: 17 Jan 2003 03:28:54.0153 (UTC) FILETIME=[8FB73790:01C2BDD8] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > The design team is still active and tasked with completing the proposal that > they started last fall. > > Therefore, I think we should terminate the circular discussion we seem to be > having on this list and let them get on with their job. > James, I agree with you. We need the proposal from the design team for further discussion, at least, about security measures. Regards, Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Jan 17 08:32:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21887 for ; Fri, 17 Jan 2003 08:32:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HDldJ31856; Fri, 17 Jan 2003 08:47:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HDkFJ31800 for ; Fri, 17 Jan 2003 08:46:15 -0500 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21857 for ; Fri, 17 Jan 2003 08:30:06 -0500 (EST) Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id h0HDXLR64807; Fri, 17 Jan 2003 14:33:22 +0100 (CET) (envelope-from Marco.Liebsch@ccrle.nec.de) Received: from ccrle.nec.de (liebsch.office [10.1.1.153]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id CB8DE84A98; Fri, 17 Jan 2003 15:41:20 +0100 (CET) Message-ID: <3E2805D8.20402@ccrle.nec.de> Date: Fri, 17 Jan 2003 14:32:08 +0100 From: Marco Liebsch Organization: NEC Europe Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark Cc: Hemant.Chaskar@nokia.com, ASINGH1@motorola.com, mankin@psg.com, kempf@docomolabs-usa.com, Seamoby@ietf.org Subject: Re: [Seamoby] CARD - FMIPv6 protocol interworking References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Eric, please see a proposal for the issue you addressed below. marco Erik Nordmark wrote: >>In the current CARD protocol draft, we have defined CARD ICMP type. This >>enables standalone implementation of CARD, independent of FMIPv6. There are >>two ICMP options for this type, namely, Request and Response. Each of those >>options have sub-options carrying CARD info. >> >> > >OK. > > > >>At the same time, to allow for integration with FMIPv6, if that is the >>implementers' choice, CARD Request and Response can be piggybacked on FMIPv6 >>signaling. This however, imposes the restriction that CARD signaling events >>must be aligned with FMIPv6 signaling events. >> >> > >And that the FMIPv6 sender only perform such piggybacking when the FMIPv6 >receiver is capable to process the received piggybacked info. >Thus this can't be an independent choice for an implementor - you might need >a mechanism in FMIPv6 to know whether the peer supports CARD piggybacking >on the FMIPv6 messages. > > We discussed this issue within the design team. To avoid modification of other protocols (FMIPv6, Neighbor Disc.) for discovery of whether or not the communication peer supports CARD protocol piggybacking, what about the following: The ICMP message for CARD protocol stand-alone deployment has a flag, indicating piggybacking capability of the message sender, if present. First CARD message sent (for example mobile to AR) is to be a stand-alone CARD message, indicating the sender's capability of piggybacking. The appropriate reply message, in this example from AR, indicates, whether or not the AR itself is able to perform piggybacking. In case of both entities support piggybacking, further CARD messages can be piggybacked. The CARD reply could already be piggybacked in case of the AR supports piggybacking and in case of an appropriate "carrier" protocol message is to be sent anyway. For the latter proposal it's important to separate protocol messages' sequence numbers. Hence, the piggybacked CARD reply message would carry the CARD message sequence number in the option to be piggybacked. This keeps CARD protocol sequence numbers de-coupled from the "carrier protocol's" sequence numbers. What do you think? marco > > >>To eliminate this restriction when integrating with FMIPv6, we were >>considering a possibility of the type, say, send Request in CARD ICMP type >>and possibly receive response in FMIPv6 message with CARD Response option >>piggybacked on it. For this however, Request and Response options need to >>have sequence ID field of their own. >> >> > >So you would send a CARD message that says "if you'd like I can accept >the response as a CARD message or piggybacked on a FMIPv6 message". >If you always use that type of exchange you handle the capability discovery >part. > >But aren't there also cases when you want to piggyback something on >the CARD request? > >Do we already know that CARD would be logically sent first? >Or will there (also) be a need for the inverse piggybacking (carrying FMIPv6 >information in CARD ICMP messages?) > > Erik > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Jan 17 08:33:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21904 for ; Fri, 17 Jan 2003 08:33:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0HDmnS31901 for seamoby-archive@odin.ietf.org; Fri, 17 Jan 2003 08:48:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HDmnJ31898 for ; Fri, 17 Jan 2003 08:48:49 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21901 for ; Fri, 17 Jan 2003 08:32:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HDldJ31856; Fri, 17 Jan 2003 08:47:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HDkFJ31800 for ; Fri, 17 Jan 2003 08:46:15 -0500 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21857 for ; Fri, 17 Jan 2003 08:30:06 -0500 (EST) Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id h0HDXLR64807; Fri, 17 Jan 2003 14:33:22 +0100 (CET) (envelope-from Marco.Liebsch@ccrle.nec.de) Received: from ccrle.nec.de (liebsch.office [10.1.1.153]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id CB8DE84A98; Fri, 17 Jan 2003 15:41:20 +0100 (CET) Message-ID: <3E2805D8.20402@ccrle.nec.de> Date: Fri, 17 Jan 2003 14:32:08 +0100 From: Marco Liebsch Organization: NEC Europe Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark Cc: Hemant.Chaskar@nokia.com, ASINGH1@motorola.com, mankin@psg.com, kempf@docomolabs-usa.com, Seamoby@ietf.org Subject: Re: [Seamoby] CARD - FMIPv6 protocol interworking References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Eric, please see a proposal for the issue you addressed below. marco Erik Nordmark wrote: >>In the current CARD protocol draft, we have defined CARD ICMP type. This >>enables standalone implementation of CARD, independent of FMIPv6. There are >>two ICMP options for this type, namely, Request and Response. Each of those >>options have sub-options carrying CARD info. >> >> > >OK. > > > >>At the same time, to allow for integration with FMIPv6, if that is the >>implementers' choice, CARD Request and Response can be piggybacked on FMIPv6 >>signaling. This however, imposes the restriction that CARD signaling events >>must be aligned with FMIPv6 signaling events. >> >> > >And that the FMIPv6 sender only perform such piggybacking when the FMIPv6 >receiver is capable to process the received piggybacked info. >Thus this can't be an independent choice for an implementor - you might need >a mechanism in FMIPv6 to know whether the peer supports CARD piggybacking >on the FMIPv6 messages. > > We discussed this issue within the design team. To avoid modification of other protocols (FMIPv6, Neighbor Disc.) for discovery of whether or not the communication peer supports CARD protocol piggybacking, what about the following: The ICMP message for CARD protocol stand-alone deployment has a flag, indicating piggybacking capability of the message sender, if present. First CARD message sent (for example mobile to AR) is to be a stand-alone CARD message, indicating the sender's capability of piggybacking. The appropriate reply message, in this example from AR, indicates, whether or not the AR itself is able to perform piggybacking. In case of both entities support piggybacking, further CARD messages can be piggybacked. The CARD reply could already be piggybacked in case of the AR supports piggybacking and in case of an appropriate "carrier" protocol message is to be sent anyway. For the latter proposal it's important to separate protocol messages' sequence numbers. Hence, the piggybacked CARD reply message would carry the CARD message sequence number in the option to be piggybacked. This keeps CARD protocol sequence numbers de-coupled from the "carrier protocol's" sequence numbers. What do you think? marco > > >>To eliminate this restriction when integrating with FMIPv6, we were >>considering a possibility of the type, say, send Request in CARD ICMP type >>and possibly receive response in FMIPv6 message with CARD Response option >>piggybacked on it. For this however, Request and Response options need to >>have sequence ID field of their own. >> >> > >So you would send a CARD message that says "if you'd like I can accept >the response as a CARD message or piggybacked on a FMIPv6 message". >If you always use that type of exchange you handle the capability discovery >part. > >But aren't there also cases when you want to piggyback something on >the CARD request? > >Do we already know that CARD would be logically sent first? >Or will there (also) be a need for the inverse piggybacking (carrying FMIPv6 >information in CARD ICMP messages?) > > Erik > >_______________________________________________ >Seamoby mailing list >Seamoby@ietf.org >https://www1.ietf.org/mailman/listinfo/seamoby > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Jan 17 09:45:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23911 for ; Fri, 17 Jan 2003 09:45:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HF0NJ04635; Fri, 17 Jan 2003 10:00:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HExdJ04560 for ; Fri, 17 Jan 2003 09:59:39 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23741 for ; Fri, 17 Jan 2003 09:43:18 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0HEkQB11604 for ; Fri, 17 Jan 2003 08:46:37 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 17 Jan 2003 08:46:18 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 17 Jan 2003 06:44:54 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 17 Jan 2003 09:44:53 -0500 Message-ID: Thread-Topic: [Seamoby] CARD between Routers - will CT do? Thread-Index: AcK9v4mPbroIPLLfSgiHAjofKvNXxwAceAoQ To: , , X-OriginalArrivalTime: 17 Jan 2003 14:44:54.0440 (UTC) FILETIME=[FF87DA80:01C2BE36] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0HExdJ04561 Subject: [Seamoby] choices for rev. adr. translation mechanisms [was: CARD between Routers - will CT do?] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi, Based on the discussion we had so far, DT has following choices. WG feedback on how to proceed - a) accept one approach, b) combine the two, c) reject both, d) delay the decision; would be valuable. This will prevent drastic modifications to subsequent versions of draft. I will try to summarize the premises we have: Approach 1: Based on MN-reports about neighborhood: ---------- - Similar to draft-trossen-seamoby-dycard-00.txt (First handoff between a pair of ARs is hard handoff. This MN tells new AR where it came from, i.e., IP address of old AR. Let us call it bootstrap handoff - HO_bt) - No rev. adr. trans. servers required - HO_bt cannot use fast/seamless handoff protocols, subsequent handoffs can - If ARs verify trust relationship between them (via preferred security mechanism such as AAA, certificates, SLAs or other), could be secured from malicious MNs (new AR asks old AR if this MN was indeed connected to it within reasonable past) - Distinction between intra and inter domain is in the method of establishing trust relationship between ARs, CARD protocol is the same for both cases (Establishing trust relationship is easy for intra case, harder for inter case. One example of how trust relation could be established in inter case: When HA_bt tells new AR about old AR's IP address, new AR asks old AR to provide credentials, say, in the form of certificate and vice versa. If ARs are satisfied with each others' credentials, then only they go for further capability and rev. adr. translation information exchange. Other credential mechanisms are possible too. Such security mechanisms can be further studied if WG were to choose this approach) Approach 2: Rev. adr. trans. server based approach: ----------- (Intra-domain scope, similar to draft-funato-seamoby-gaard-01.txt) - Network domain maintains rev. adr. trans. server that stores rev. adr. translation information of ARs in the domain - Old AR queries rev. adr. trans. server in its domain to resolve a first L2 ID to IP address (bootstrap query - Query_bt) - Rev. adr. trans. server replies with IP address of new AR (in the same domain) - Later, old and new ARs can engage in peer-to-peer capability and rev. adr. translation information exchange bypassing the rev. adr. tran. server - Easily secured (Extending Approach 2 to interdomain scope): - Form federation of rev. adr. trans. servers in different domains. For this we can go for one of following approaches: (i) rev. adr. translation servers in different domains exchange information. This is similar to IPTEL WG's Telephony Routing over IP (TRIP) Protocol (which does information exchange between ITADs (IP Telephony Admin Domains) about IP-PSTN gateways they can reach), which in turn is similar to BGP. or, (ii) build DNS like tree of rev. adr. trans. servers, or (iii) require that AP ID has enough information that Query_bt can be routed over Internet to correct rev. adr. translation server, or (iv) flood the federation of servers with Query_bt - When going inter domain, there is no guarantee that response to Query_bt comes before handoff is imminent. So this handoff may not be able to use fast/seamless handoff protocols, subsequent handoffs can - Security mechanism needs to be provided by server federation Note, in any case, ISPs cannot hide rev. adr. translation information from each other. If this is intolerable, we should proceed with understanding that seamless handoff protocols SHOULD be used intra domain. This is because, these protocols will need old AR to know IP address of new AR. Comments? Hemant -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Thursday, January 16, 2003 7:28 PM To: Eunsoo Shim; Chaskar Hemant (NRC/Boston); seamoby@ietf.org Subject: Re: [Seamoby] CARD between Routers - will CT do? Eunsoo, The design team is still active and tasked with completing the proposal that they started last fall. Therefore, I think we should terminate the circular discussion we seem to be having on this list and let them get on with their job. jak ----- Original Message ----- From: "Eunsoo Shim" To: "James Kempf" ; ; Sent: Thursday, January 16, 2003 4:55 PM Subject: Re: [Seamoby] CARD between Routers - will CT do? > Please let me repeat once. > The CARD protocol does NOT disclose the INTERNAL topology of the network > that the MNs cannot figure out. > Also it is not necessary for mobility management. It discloses only the AR's > IP addresses, AP's MAC addresses and such things. Disclosing capabilities > (attributes) can be limited by policies. > > So I am wondering what's the concern of the providers in exchanging the > information that is anyway given away to the MNs. > I am not sure that trusting another provider with any kind of cooperation > relationship (such as roaming agreement) is more risky than trusting the > MNs. > Anyway this is about network provider's policies or business frameworks. I > am not so sure we should spend lots of time on clarifying the providers' > policies. Of course, if providers come out and provider their opinions, it > is more than welcome. > > While we work on security measures for CARD, I think, we will know what's > the requirements for inter-provider operation of CARD. I don't agree if you > suggest we forget about inter-provider operation in designing the CARD > protocol and create something only for intra-provider operation and then > start looking into the inter-provider operation. For it might lead to a > protocol that is not suitable at all for inter-provider operation in the > beginning. I think we should keep in mind all the way that it is most > preferable to use the same protocol for inter-provider operation as well as > intra-provider operation. I agree to looking into intra-provider design > first only with the intention to extend the same protocol for the > inter-provider operation immediately rather than trying to create totally > different two sets of protocols. > With that in mind, we can start with a base discovery mechanism and look > into the security measures for it. We may find that the security measures > are very different in two cases, that is, inter-provider operation and > intra-provider operation, or they are almost the same. Then we will be able > to say what is the (technically) feasible approach for CARD over > inter-provider roaming. > > So the most important thing for our progress is picking (a) base discovery > mechanism(s) that we want to look into and design security measures on. > > How do we want to go about this? We start looking into the two individual > proposals or any new or merged proposals from the design team? What's the > status of the design team about it? > > Regards, > > Eunsoo > > > ----- Original Message ----- > From: "James Kempf" > To: ; ; > Sent: Thursday, January 16, 2003 10:47 AM > Subject: Re: [Seamoby] CARD between Routers - will CT do? > > > > With my service provider hat on, I'm saying that I don't think our > operations > > guys will approve using the IP address from another service provider's > internal > > topology in the fashion that you and Eunsoo are advocating. Regardless of > > whether or not there is a Radius connection. if the MN sends it, our RAs > will > > simply be configured to reject it. Therefore, I think we should now try to > > concentrate on the intra-provider case now, and deal with the > interprovider case > > later. > > > > Other service providers, want to comment? > > > > jak > > > > > > ----- Original Message ----- > > From: > > To: ; ; > > Sent: Thursday, January 16, 2003 9:52 AM > > Subject: RE: [Seamoby] CARD between Routers - will CT do? > > > > > > > Hi James: > > > > > > I am not sure why CARD needs to expose "internal" topology. But, to > emphasize > > it, we can add a guideline that > > > > > > (iii) CARD SHOULD/MUST not export any information between domains other > than > > AR addresses, Link layer IDs and capabilities. > > > > > > (The above information is already exposed to third parties, i.e., MNs > > connecting to networks. So, it is not secret anymore.) > > > > > > Are you suggesting use of Radius to establish SAs (possible) or for > performing > > CARD (not sure)? > > > > > > Hemant > > > > > > -----Original Message----- > > > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > > > Sent: Thursday, January 16, 2003 12:22 PM > > > To: Chaskar Hemant (NRC/Boston); eunsoo@nec-lab.com; seamoby@ietf.org > > > Subject: Re: [Seamoby] CARD between Routers - will CT do? > > > > > > > > > > Hemant --> I think we can start protocol design under the assumptions > that > > (i) > > > old and new ARs can establish SA between them, (ii) they are willing to > > > participate in CARD protocol. Then, there may not be any need for > intra-domain > > / > > > inter-domain classification. > > > > > > > > > > Alternatively, an intermediary that would be more acceptable, such as a > Radius > > > server, could be used. My initial point is that the two providers don't > want > > to > > > expose their internal topology, even if they have an SA allowing > > inter-provider > > > handover. > > > > > > jak > > > > > > > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Jan 17 09:46:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23943 for ; Fri, 17 Jan 2003 09:46:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0HF2E604768 for seamoby-archive@odin.ietf.org; Fri, 17 Jan 2003 10:02:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HF2EJ04765 for ; Fri, 17 Jan 2003 10:02:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23925 for ; Fri, 17 Jan 2003 09:46:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HF0NJ04635; Fri, 17 Jan 2003 10:00:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HExdJ04560 for ; Fri, 17 Jan 2003 09:59:39 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23741 for ; Fri, 17 Jan 2003 09:43:18 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0HEkQB11604 for ; Fri, 17 Jan 2003 08:46:37 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 17 Jan 2003 08:46:18 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 17 Jan 2003 06:44:54 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 17 Jan 2003 09:44:53 -0500 Message-ID: Thread-Topic: [Seamoby] CARD between Routers - will CT do? Thread-Index: AcK9v4mPbroIPLLfSgiHAjofKvNXxwAceAoQ To: , , X-OriginalArrivalTime: 17 Jan 2003 14:44:54.0440 (UTC) FILETIME=[FF87DA80:01C2BE36] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0HExdJ04561 Subject: [Seamoby] choices for rev. adr. translation mechanisms [was: CARD between Routers - will CT do?] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, Based on the discussion we had so far, DT has following choices. WG feedback on how to proceed - a) accept one approach, b) combine the two, c) reject both, d) delay the decision; would be valuable. This will prevent drastic modifications to subsequent versions of draft. I will try to summarize the premises we have: Approach 1: Based on MN-reports about neighborhood: ---------- - Similar to draft-trossen-seamoby-dycard-00.txt (First handoff between a pair of ARs is hard handoff. This MN tells new AR where it came from, i.e., IP address of old AR. Let us call it bootstrap handoff - HO_bt) - No rev. adr. trans. servers required - HO_bt cannot use fast/seamless handoff protocols, subsequent handoffs can - If ARs verify trust relationship between them (via preferred security mechanism such as AAA, certificates, SLAs or other), could be secured from malicious MNs (new AR asks old AR if this MN was indeed connected to it within reasonable past) - Distinction between intra and inter domain is in the method of establishing trust relationship between ARs, CARD protocol is the same for both cases (Establishing trust relationship is easy for intra case, harder for inter case. One example of how trust relation could be established in inter case: When HA_bt tells new AR about old AR's IP address, new AR asks old AR to provide credentials, say, in the form of certificate and vice versa. If ARs are satisfied with each others' credentials, then only they go for further capability and rev. adr. translation information exchange. Other credential mechanisms are possible too. Such security mechanisms can be further studied if WG were to choose this approach) Approach 2: Rev. adr. trans. server based approach: ----------- (Intra-domain scope, similar to draft-funato-seamoby-gaard-01.txt) - Network domain maintains rev. adr. trans. server that stores rev. adr. translation information of ARs in the domain - Old AR queries rev. adr. trans. server in its domain to resolve a first L2 ID to IP address (bootstrap query - Query_bt) - Rev. adr. trans. server replies with IP address of new AR (in the same domain) - Later, old and new ARs can engage in peer-to-peer capability and rev. adr. translation information exchange bypassing the rev. adr. tran. server - Easily secured (Extending Approach 2 to interdomain scope): - Form federation of rev. adr. trans. servers in different domains. For this we can go for one of following approaches: (i) rev. adr. translation servers in different domains exchange information. This is similar to IPTEL WG's Telephony Routing over IP (TRIP) Protocol (which does information exchange between ITADs (IP Telephony Admin Domains) about IP-PSTN gateways they can reach), which in turn is similar to BGP. or, (ii) build DNS like tree of rev. adr. trans. servers, or (iii) require that AP ID has enough information that Query_bt can be routed over Internet to correct rev. adr. translation server, or (iv) flood the federation of servers with Query_bt - When going inter domain, there is no guarantee that response to Query_bt comes before handoff is imminent. So this handoff may not be able to use fast/seamless handoff protocols, subsequent handoffs can - Security mechanism needs to be provided by server federation Note, in any case, ISPs cannot hide rev. adr. translation information from each other. If this is intolerable, we should proceed with understanding that seamless handoff protocols SHOULD be used intra domain. This is because, these protocols will need old AR to know IP address of new AR. Comments? Hemant -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Thursday, January 16, 2003 7:28 PM To: Eunsoo Shim; Chaskar Hemant (NRC/Boston); seamoby@ietf.org Subject: Re: [Seamoby] CARD between Routers - will CT do? Eunsoo, The design team is still active and tasked with completing the proposal that they started last fall. Therefore, I think we should terminate the circular discussion we seem to be having on this list and let them get on with their job. jak ----- Original Message ----- From: "Eunsoo Shim" To: "James Kempf" ; ; Sent: Thursday, January 16, 2003 4:55 PM Subject: Re: [Seamoby] CARD between Routers - will CT do? > Please let me repeat once. > The CARD protocol does NOT disclose the INTERNAL topology of the network > that the MNs cannot figure out. > Also it is not necessary for mobility management. It discloses only the AR's > IP addresses, AP's MAC addresses and such things. Disclosing capabilities > (attributes) can be limited by policies. > > So I am wondering what's the concern of the providers in exchanging the > information that is anyway given away to the MNs. > I am not sure that trusting another provider with any kind of cooperation > relationship (such as roaming agreement) is more risky than trusting the > MNs. > Anyway this is about network provider's policies or business frameworks. I > am not so sure we should spend lots of time on clarifying the providers' > policies. Of course, if providers come out and provider their opinions, it > is more than welcome. > > While we work on security measures for CARD, I think, we will know what's > the requirements for inter-provider operation of CARD. I don't agree if you > suggest we forget about inter-provider operation in designing the CARD > protocol and create something only for intra-provider operation and then > start looking into the inter-provider operation. For it might lead to a > protocol that is not suitable at all for inter-provider operation in the > beginning. I think we should keep in mind all the way that it is most > preferable to use the same protocol for inter-provider operation as well as > intra-provider operation. I agree to looking into intra-provider design > first only with the intention to extend the same protocol for the > inter-provider operation immediately rather than trying to create totally > different two sets of protocols. > With that in mind, we can start with a base discovery mechanism and look > into the security measures for it. We may find that the security measures > are very different in two cases, that is, inter-provider operation and > intra-provider operation, or they are almost the same. Then we will be able > to say what is the (technically) feasible approach for CARD over > inter-provider roaming. > > So the most important thing for our progress is picking (a) base discovery > mechanism(s) that we want to look into and design security measures on. > > How do we want to go about this? We start looking into the two individual > proposals or any new or merged proposals from the design team? What's the > status of the design team about it? > > Regards, > > Eunsoo > > > ----- Original Message ----- > From: "James Kempf" > To: ; ; > Sent: Thursday, January 16, 2003 10:47 AM > Subject: Re: [Seamoby] CARD between Routers - will CT do? > > > > With my service provider hat on, I'm saying that I don't think our > operations > > guys will approve using the IP address from another service provider's > internal > > topology in the fashion that you and Eunsoo are advocating. Regardless of > > whether or not there is a Radius connection. if the MN sends it, our RAs > will > > simply be configured to reject it. Therefore, I think we should now try to > > concentrate on the intra-provider case now, and deal with the > interprovider case > > later. > > > > Other service providers, want to comment? > > > > jak > > > > > > ----- Original Message ----- > > From: > > To: ; ; > > Sent: Thursday, January 16, 2003 9:52 AM > > Subject: RE: [Seamoby] CARD between Routers - will CT do? > > > > > > > Hi James: > > > > > > I am not sure why CARD needs to expose "internal" topology. But, to > emphasize > > it, we can add a guideline that > > > > > > (iii) CARD SHOULD/MUST not export any information between domains other > than > > AR addresses, Link layer IDs and capabilities. > > > > > > (The above information is already exposed to third parties, i.e., MNs > > connecting to networks. So, it is not secret anymore.) > > > > > > Are you suggesting use of Radius to establish SAs (possible) or for > performing > > CARD (not sure)? > > > > > > Hemant > > > > > > -----Original Message----- > > > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > > > Sent: Thursday, January 16, 2003 12:22 PM > > > To: Chaskar Hemant (NRC/Boston); eunsoo@nec-lab.com; seamoby@ietf.org > > > Subject: Re: [Seamoby] CARD between Routers - will CT do? > > > > > > > > > > Hemant --> I think we can start protocol design under the assumptions > that > > (i) > > > old and new ARs can establish SA between them, (ii) they are willing to > > > participate in CARD protocol. Then, there may not be any need for > intra-domain > > / > > > inter-domain classification. > > > > > > > > > > Alternatively, an intermediary that would be more acceptable, such as a > Radius > > > server, could be used. My initial point is that the two providers don't > want > > to > > > expose their internal topology, even if they have an SA allowing > > inter-provider > > > handover. > > > > > > jak > > > > > > > > > > > > _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Jan 17 09:51:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24114 for ; Fri, 17 Jan 2003 09:51:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HF62J05084; Fri, 17 Jan 2003 10:06:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HF5GJ05030 for ; Fri, 17 Jan 2003 10:05:16 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24046 for ; Fri, 17 Jan 2003 09:48:49 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0HEq1B12592 for ; Fri, 17 Jan 2003 08:52:12 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 17 Jan 2003 08:51:49 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 17 Jan 2003 08:50:52 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2BE37.D42A49D0" Subject: RE: [Seamoby] CARD between Routers - will CT do? Date: Fri, 17 Jan 2003 09:50:51 -0500 Message-ID: Thread-Topic: [Seamoby] CARD between Routers - will CT do? Thread-Index: AcK9olewU0m7dRiJSQqr3ocmYQf6zgAlOsHw To: , , , Cc: , X-OriginalArrivalTime: 17 Jan 2003 14:50:52.0574 (UTC) FILETIME=[D4FEC3E0:01C2BE37] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C2BE37.D42A49D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Gary: =20 See below: =20 -----Original Message----- From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Thursday, January 16, 2003 4:01 PM To: Krishnamurthi Govind (NRC/Boston); kempf@docomolabs-usa.com; = funato@docomolabs-usa.com; Chaskar Hemant (NRC/Boston) Cc: eunsoo@nec-lab.com; seamoby@ietf.org Subject: RE: [Seamoby] CARD between Routers - will CT do? Inter-domain CARD:=20 Let me see if I understand this correctly: to perform an inter-system=20 handover based upon CARD, I would need a service agreement between=20 the two operators, CARD at each AR, CARD at the MN, a path and a = protocol=20 for transferring information (including "topology information"?) =20 [Hemant] There isn't need to transfer topology information. We should = call it rev. adr. translation info which is IP addresses of AR (not all = routers in domain) and their AP IDs. =20 between ARs in two different domains *and* all the aforementioned = security=20 overhead.=20 Or, on the other hand, the two operators could agree to mutually = configure=20 their networks so that the network controlled handover algorithms direct = the=20 mobile to the appropriate AR in the neighbouring domain. The handover = algorithms=20 stay basically the same, the operators do not need to exchange topology=20 information (there are other, easier methods for finding out where the = access=20 points are mounted, if that was the intent). But no discovery protocol, = no=20 AR to AR signalling and no SA required between ARs (other then, perhaps = CT,=20 if you believe in CT for seamlessness). =20 [Hemant] There is no consensus that network controlled handoff is the = way to go. But, even for this case you need a path, protocol and = security mechanisms to transfer information between domains. You could = call it CARD. That is of course, you are not suggesting to keep static = information exchanged at the time SLA was struck and manually refresh it = whenever something changes in a network domain.=20 Lot's of L2 issues, but they exist in either scenario.=20 Gary=20 > -----Original Message-----=20 > From: Govind.Krishnamurthi@nokia.com=20 > [ mailto:Govind.Krishnamurthi@nokia.com]=20 > Sent: January 16, 2003 14:50=20 > To: kempf@docomolabs-usa.com; funato@docomolabs-usa.com;=20 > Hemant.Chaskar@nokia.com=20 > Cc: eunsoo@nec-lab.com; seamoby@ietf.org=20 > Subject: RE: [Seamoby] CARD between Routers - will CT do?=20 >=20 >=20 > Jim,=20 > comments inline.=20 >=20 > -----Original Message-----=20 > From: ext James Kempf [ mailto:kempf@docomolabs-usa.com]=20 > Sent: Thursday, January 16, 2003 12:49 PM=20 > To: Hemant Chaskar; funato@docomolabs-usa.com; Chaskar Hemant=20 > (NRC/Boston)=20 > Cc: eunsoo@nec-lab.com; seamoby@ietf.org=20 > Subject: Re: [Seamoby] CARD between Routers - will CT do?=20 >=20 >=20 > What do you mean by an SA? An IPSec SA?=20 > ---> By SA, I mean a trust relationship. It can be using an=20 > IPSec SA or=20 > any other means. They have enough information to authenticate=20 > each other.=20 >=20 > If so, how do you propose to have the=20 > routers use that for checking that the AP L2 addresses=20 > provided by the MN map=20 > into IP addresses that are authorized to route on the service=20 > provider's=20 > network?=20 >=20 > ----> We have illustrated one method to do this in our draft.=20 >=20 > Note that the IESG is requiring that the Security=20 > Considerations of all protocol=20 > drafts describe, precisely, how the protocol will be secured.=20 > It is no longer=20 > sufficient to say "use IPSec" or "use AAA". Requiring other=20 > protocols is OK, but=20 > it must be specified precisely how those protocols are used=20 > for securing the=20 > protocol in question.=20 >=20 > -----> OK.=20 >=20 > jak=20 >=20 > ----- Original Message -----=20 > From: "Hemant Chaskar" =20 > To: ; =20 > Cc: ; ;=20 > =20 > Sent: Wednesday, January 15, 2003 8:24 PM=20 > Subject: Re: [Seamoby] CARD between Routers - will CT do?=20 >=20 >=20 > > Hi Daichi:=20 > >=20 > > I do not think that establishment of SA between ARs should=20 > be within scope=20 > > of CARD. We should start from pre-requisite that SA can be=20 > established=20 > > between ARs. When ARs belong to same domain, this is=20 > simple. When they=20 > > belong to different domain it is harder. In either case,=20 > there can be=20 > > variety of ways to establish SAs - pre-shared key, domain specific=20 > > certificates, AAA, credentials exchanged during SLAs or any=20 > other means. Why=20 > > should CARD put any restriction on mechanism used to establish SA?=20 > >=20 > > So, instead of=20 > >=20 > > <--Interworking-->=20 > > |=20 > > Intra-domain CARD | Inter-domain CARD=20 > > protocol | protocol=20 > > --------------------|------------------------------=20 > > Intra-domain SA | Inter-domain SA=20 > > mechanism | mechanism=20 > > (CARD specific?) | (CARD specific?)=20 > >=20 > > I am saying that, if possible, we should try,=20 > >=20 > >=20 > >=20 > > CARD protocol=20 > > ----------------------------------------------=20 > > |=20 > > Intra-domain SA | Inter-domain SA=20 > > mechanisms | mechanisms=20 > > current/future best | (current/future best=20 > > practices) | practices)=20 > >=20 > > At this point, I cannot vouch for security of=20 > MN-report-based CARD approach.=20 > > But, could you describe what kind of attacks do you think=20 > MN-report-based=20 > > CARD is vulnerable to? In=20 > draft-trossen-seamoby-dycard-00.txt, we have shown=20 > > that certain simple mechanisms can foil security attacks in=20 > MN-report-based=20 > > CARD (To the least, if MN tells new AR arbitrary IP address=20 > as address of=20 > > old AR, it can be detected). Also, the side effect of=20 > attacks, if any, does=20 > > not adversely affect good MNs. But, of course, we could=20 > have missed some=20 > > attack possibilities.=20 > >=20 > >=20 > > Hemant=20 > >=20 > > >From: Daichi Funato =20 > > >To: Hemant.Chaskar@nokia.com=20 > > >CC: , ,=20 > =20 > > >Subject: Re: [Seamoby] CARD between Routers - will CT do?=20 > > >Date: Wed, 15 Jan 2003 19:10:15 -0800=20 > > >=20 > > >Hi Hemant,=20 > > >=20 > > > > Hemant --> I think we can start protocol design under=20 > the assumptions=20 > > >that=20 > > > > (i) old and new ARs can establish SA between them, (ii)=20 > they are willing=20 > > >to=20 > > > > participate in CARD protocol. Then, there may not be=20 > any need for=20 > > >intra-domain=20 > > > > / inter-domain classification.=20 > > >=20 > > >What kind of security mechanisms are you assuming?=20 > > >I think we should not leave the security mechanisms out of=20 > the scope.=20 > > >=20 > > >Especially, MN-report-based CARD is vulnerable to an attacker.=20 > > >How to protect the communication is an essential part of=20 > CARD, I think.=20 > > >Actually, IEEE IAPP includes a security mechanism by itself.=20 > > >Do we neglect that part in CARD?=20 > > >=20 > > >IMHO, if CARD can provide secure keys for ARs, these can=20 > be used by CT=20 > > >and FMIP as well. This is another type of capability discovery.=20 > > >What do you think?=20 > > >=20 > > >Best regards,=20 > > >Daichi=20 > > >=20 > > >-------------------------------------------------------------=20 > > >Daichi Funato =20 > > >DoCoMo Communications Laboratories USA, Inc.=20 > > >=20 > > >Confidential Note:=20 > > >Privileged/Confidential Information may be contained in this e-mail = > > >and any attachment to it. Unless you are the addressee indicated in = > > >this e-mail, please notify immediately the sender by reply e-mail=20 > > >that you have received this in error and delete it from=20 > your system.=20 > > >You may not use, copy or deliver this e-mail or any information=20 > > >contained in this e-mail to anyone. Thank you very much.=20 > > >-------------------------------------------------------------=20 > > >=20 > > >_______________________________________________=20 > > >Seamoby mailing list=20 > > >Seamoby@ietf.org=20 > > > https://www1.ietf.org/mailman/listinfo/seamoby=20 > >=20 > >=20 > > _________________________________________________________________=20 > > Add photos to your e-mail with MSN 8. Get 2 months FREE*.=20 > > http://join.msn.com/?page=3Dfeatures/featuredemail=20 > >=20 > >=20 >=20 > _______________________________________________=20 > Seamoby mailing list=20 > Seamoby@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/seamoby=20 > _______________________________________________=20 > Seamoby mailing list=20 > Seamoby@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/seamoby=20 >=20 ------_=_NextPart_001_01C2BE37.D42A49D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] CARD between Routers - will CT do?
Hi=20 Gary:
 
See=20 below:
 
-----Original Message-----
From: ext Gary Kenward=20 [mailto:gkenward@nortelnetworks.com]
Sent: Thursday, January = 16, 2003=20 4:01 PM
To: Krishnamurthi Govind (NRC/Boston);=20 kempf@docomolabs-usa.com; funato@docomolabs-usa.com; Chaskar Hemant=20 (NRC/Boston)
Cc: eunsoo@nec-lab.com;=20 seamoby@ietf.org
Subject: RE: [Seamoby] CARD between Routers - = will CT=20 do?

Inter-domain CARD:

Let me see if I understand this correctly: to perform = an=20 inter-system
handover based upon CARD, I would = need a=20 service agreement between
the two operators, = CARD at=20 each AR, CARD at the MN, a path and a protocol
for=20 transferring information (including "topology = information"?)  

[Hemant]=20 There isn't need to transfer topology information. We should call = it rev.=20 adr. translation info which is IP addresses of AR (not all routers in = domain)=20 and their AP IDs.

 
between ARs in=20 two different domains *and* all the aforementioned security =
overhead.

Or, on the other hand, the two operators could agree = to mutually=20 configure
their networks so that the network = controlled=20 handover algorithms direct the
mobile to the = appropriate=20 AR in the neighbouring domain. The handover algorithms
stay basically the same, the operators do not need to exchange = topology=20
information (there are other, easier methods = for finding=20 out where the access
points are mounted, if = that was the=20 intent). But no discovery protocol, no
AR to = AR=20 signalling and no SA required between ARs (other then, perhaps CT,=20
if you believe in CT for=20 seamlessness).  

[Hemant]=20 There is no consensus that network controlled handoff is the way to=20 go. But, even for this case you need a path, protocol and security=20 mechanisms to transfer information between domains. You could call = it CARD.=20 That is of course, you are not suggesting to keep static information = exchanged=20 at the time SLA was struck and manually refresh it whenever something = changes in=20 a network domain. 

Lot's of L2 issues, but they exist in either = scenario.=20

Gary

> -----Original Message-----
>=20 From: Govind.Krishnamurthi@nokia.com
> [mailto:Govind.Krishnamurth= i@nokia.com]=20
> Sent: January 16, 2003 14:50
>=20 To: kempf@docomolabs-usa.com; funato@docomolabs-usa.com; =
> Hemant.Chaskar@nokia.com
> = Cc:=20 eunsoo@nec-lab.com; seamoby@ietf.org
> = Subject: RE:=20 [Seamoby] CARD between Routers - will CT do?
>=20
>
> = Jim,
> comments inline.
> =
> -----Original Message-----
> = From: ext=20 James Kempf [mailto:kempf@docomolabs-usa.com<= /A>]=20
> Sent: Thursday, January 16, 2003 12:49 PM =
> To: Hemant Chaskar; funato@docomolabs-usa.com; Chaskar = Hemant=20
> (NRC/Boston)
> Cc:=20 eunsoo@nec-lab.com; seamoby@ietf.org
> = Subject: Re:=20 [Seamoby] CARD between Routers - will CT do?
>=20
>
> What do = you mean by an=20 SA? An IPSec SA?
> ---> By SA, I mean a = trust=20 relationship. It can be using an
> IPSec SA = or=20
> any other means. They have enough = information to=20 authenticate
> each other.
>
> If so, how do you propose = to have=20 the
> routers use that for checking that = the AP L2=20 addresses
> provided by the MN map =
> into IP addresses that are authorized to route on the = service=20
> provider's
> = network?
>
> = ----> We=20 have illustrated one method to do this in our draft.
>
> Note that the IESG is = requiring that=20 the Security
> Considerations of all = protocol=20
> drafts describe, precisely, how the protocol = will be=20 secured.
> It is no longer
> sufficient to say "use IPSec" or "use AAA". Requiring = other=20
> protocols is OK, but
>=20 it must be specified precisely how those protocols are used =
> for securing the
> protocol = in=20 question.
>
> = ----->=20 OK.
>
>          =   =20 jak
>
> ----- = Original=20 Message -----
> From: "Hemant Chaskar"=20 <hchaskar@hotmail.com>
> To:=20 <funato@docomolabs-usa.com>; = <Hemant.Chaskar@nokia.com>=20
> Cc: <eunsoo@nec-lab.com>;=20 <kempf@docomolabs-usa.com>;
>=20 <seamoby@ietf.org>
> Sent: Wednesday, = January=20 15, 2003 8:24 PM
> Subject: Re: [Seamoby] = CARD=20 between Routers - will CT do?
> =
>
> > Hi Daichi: =
> >
> > I do not think = that=20 establishment of SA between ARs should
> be = within=20 scope
> > of CARD. We should start from=20 pre-requisite that SA can be
> = established=20
> > between ARs. When ARs belong to same = domain, this is=20
> simple. When they
> >=20 belong to different domain it is harder. In either case, =
> there can be
> > variety = of ways to=20 establish SAs - pre-shared key, domain specific
>=20 > certificates, AAA, credentials exchanged during SLAs or any=20
> other means. Why
> >=20 should CARD put any restriction on mechanism used to establish = SA?=20
> >
> > So, = instead=20 of
> >
>=20 >           &nb= sp;          =20 <--Interworking-->
>=20 >           &nb= sp;           &nbs= p;     =20 |
>=20 >          Intra-domain=20 CARD   |       Inter-domain = CARD=20
>=20 >           &nb= sp;   =20 protocol     =20 |          protocol=20
> = >         =20 --------------------|------------------------------
>=20 >          Intra-domain=20 SA     |       = Inter-domain=20 SA
>=20 >           =20 mechanism        =20 |          mechanism =
> = >         (CARD=20 specific?)     |       = (CARD=20 specific?)
> >
> > I=20 am saying that, if possible, we should try,
>=20 >
> >
> = >=20
>=20 >           &nb= sp;           =20 CARD protocol
>=20 >         =20 ----------------------------------------------
>=20 >           &nb= sp;           &nbs= p;      =20 |
>=20 >          Intra-domain=20 SA      |      = Inter-domain=20 SA
>=20 >           &nb= sp;=20 mechanisms       =20 |         mechanisms =
> >         = current/future=20 best   |   (current/future best
>=20 >           &nb= sp;=20 practices)       =20 |          = practices)=20
> >
> > At this = point, I=20 cannot vouch for security of
> = MN-report-based CARD=20 approach.
> > But, could you describe = what kind of=20 attacks do you think
> = MN-report-based=20
> > CARD is vulnerable to? In
> draft-trossen-seamoby-dycard-00.txt, we have shown =
> > that certain simple mechanisms can foil security = attacks in=20
> MN-report-based
> >=20 CARD (To the least, if MN tells new AR arbitrary IP address =
> as address of
> > old AR, = it can be=20 detected). Also, the side effect of
> = attacks, if=20 any, does
> > not adversely affect good = MNs. But,=20 of course, we could
> have missed = some=20
> > attack possibilities.
>=20 >
> >
> = >=20 Hemant
> >
> >=20 >From: Daichi Funato <funato@docomolabs-usa.com> =
> > >To: Hemant.Chaskar@nokia.com
>=20 > >CC: <eunsoo@nec-lab.com>, = <kempf@docomolabs-usa.com>,=20
> <seamoby@ietf.org>
> > >Subject: Re: [Seamoby] CARD between Routers - = will CT=20 do?
> > >Date: Wed, 15 Jan 2003 = 19:10:15=20 -0800
> > >
> >=20 >Hi Hemant,
> > >
> > > > Hemant --> I think we can start protocol = design=20 under
> the assumptions
>=20 > >that
> > > > (i) old and = new ARs=20 can establish SA between them, (ii)
> they = are=20 willing
> > >to
>=20 > > > participate in CARD protocol. Then, there may not be=20
> any need for
> >=20 >intra-domain
> > > > / = inter-domain=20 classification.
> > > =
> > >What kind of security mechanisms are you = assuming?=20
> > >I think we should not leave the = security=20 mechanisms out of
> the scope. =
> > >
> > = >Especially,=20 MN-report-based CARD is vulnerable to an attacker.
>=20 > >How to protect the communication is an essential part of=20
> CARD, I think.
> >=20 >Actually, IEEE IAPP includes a security mechanism by itself.=20
> > >Do we neglect that part in CARD? =
> > >
> > >IMHO, if = CARD can=20 provide secure keys for ARs, these can
> be = used by=20 CT
> > >and FMIP as well. This is = another type=20 of capability discovery.
> > >What do = you=20 think?
> > >
> >=20 >Best regards,
> > >Daichi =
> > >
> >=20 >------------------------------------------------------------- =
> > >Daichi Funato=20 <funato@docomolabs-usa.com>
> > = >DoCoMo=20 Communications Laboratories USA, Inc.
> = >=20 >
> > >Confidential Note: =
> > >Privileged/Confidential Information may be = contained in=20 this e-mail
> > >and any attachment = to it.=20 Unless you are the addressee indicated in
> = >=20 >this e-mail, please notify immediately the sender by reply = e-mail=20
> > >that you have received this in error = and delete=20 it from
> your system.
>=20 > >You may not use, copy or deliver this e-mail or any = information=20
> > >contained in this e-mail to = anyone.  Thank=20 you very much.
> >=20 >------------------------------------------------------------- =
> > >
> >=20 >_______________________________________________
>=20 > >Seamoby mailing list
> >=20 >Seamoby@ietf.org
> > >https://www1.ietf= .org/mailman/listinfo/seamoby=20
> >
> > =
> >=20 _________________________________________________________________ =
> > Add photos to your e-mail with MSN 8. Get 2 = months=20 FREE*.
> > http://join.m= sn.com/?page=3Dfeatures/featuredemail=20
> >
> > =
>
>=20 _______________________________________________
>=20 Seamoby mailing list
> = Seamoby@ietf.org=20
> https://www1.ietf= .org/mailman/listinfo/seamoby=20
> = _______________________________________________=20
> Seamoby mailing list
>=20 Seamoby@ietf.org
> https://www1.ietf= .org/mailman/listinfo/seamoby=20
>

------_=_NextPart_001_01C2BE37.D42A49D0-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Jan 17 09:52:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24145 for ; Fri, 17 Jan 2003 09:52:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0HF7n305798 for seamoby-archive@odin.ietf.org; Fri, 17 Jan 2003 10:07:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HF7mJ05795 for ; Fri, 17 Jan 2003 10:07:48 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24128 for ; Fri, 17 Jan 2003 09:51:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HF62J05084; Fri, 17 Jan 2003 10:06:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HF5GJ05030 for ; Fri, 17 Jan 2003 10:05:16 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24046 for ; Fri, 17 Jan 2003 09:48:49 -0500 (EST) From: Hemant.Chaskar@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0HEq1B12592 for ; Fri, 17 Jan 2003 08:52:12 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 17 Jan 2003 08:51:49 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 17 Jan 2003 08:50:52 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2BE37.D42A49D0" Subject: RE: [Seamoby] CARD between Routers - will CT do? Date: Fri, 17 Jan 2003 09:50:51 -0500 Message-ID: Thread-Topic: [Seamoby] CARD between Routers - will CT do? Thread-Index: AcK9olewU0m7dRiJSQqr3ocmYQf6zgAlOsHw To: , , , Cc: , X-OriginalArrivalTime: 17 Jan 2003 14:50:52.0574 (UTC) FILETIME=[D4FEC3E0:01C2BE37] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C2BE37.D42A49D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Gary: =20 See below: =20 -----Original Message----- From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Thursday, January 16, 2003 4:01 PM To: Krishnamurthi Govind (NRC/Boston); kempf@docomolabs-usa.com; = funato@docomolabs-usa.com; Chaskar Hemant (NRC/Boston) Cc: eunsoo@nec-lab.com; seamoby@ietf.org Subject: RE: [Seamoby] CARD between Routers - will CT do? Inter-domain CARD:=20 Let me see if I understand this correctly: to perform an inter-system=20 handover based upon CARD, I would need a service agreement between=20 the two operators, CARD at each AR, CARD at the MN, a path and a = protocol=20 for transferring information (including "topology information"?) =20 [Hemant] There isn't need to transfer topology information. We should = call it rev. adr. translation info which is IP addresses of AR (not all = routers in domain) and their AP IDs. =20 between ARs in two different domains *and* all the aforementioned = security=20 overhead.=20 Or, on the other hand, the two operators could agree to mutually = configure=20 their networks so that the network controlled handover algorithms direct = the=20 mobile to the appropriate AR in the neighbouring domain. The handover = algorithms=20 stay basically the same, the operators do not need to exchange topology=20 information (there are other, easier methods for finding out where the = access=20 points are mounted, if that was the intent). But no discovery protocol, = no=20 AR to AR signalling and no SA required between ARs (other then, perhaps = CT,=20 if you believe in CT for seamlessness). =20 [Hemant] There is no consensus that network controlled handoff is the = way to go. But, even for this case you need a path, protocol and = security mechanisms to transfer information between domains. You could = call it CARD. That is of course, you are not suggesting to keep static = information exchanged at the time SLA was struck and manually refresh it = whenever something changes in a network domain.=20 Lot's of L2 issues, but they exist in either scenario.=20 Gary=20 > -----Original Message-----=20 > From: Govind.Krishnamurthi@nokia.com=20 > [ mailto:Govind.Krishnamurthi@nokia.com]=20 > Sent: January 16, 2003 14:50=20 > To: kempf@docomolabs-usa.com; funato@docomolabs-usa.com;=20 > Hemant.Chaskar@nokia.com=20 > Cc: eunsoo@nec-lab.com; seamoby@ietf.org=20 > Subject: RE: [Seamoby] CARD between Routers - will CT do?=20 >=20 >=20 > Jim,=20 > comments inline.=20 >=20 > -----Original Message-----=20 > From: ext James Kempf [ mailto:kempf@docomolabs-usa.com]=20 > Sent: Thursday, January 16, 2003 12:49 PM=20 > To: Hemant Chaskar; funato@docomolabs-usa.com; Chaskar Hemant=20 > (NRC/Boston)=20 > Cc: eunsoo@nec-lab.com; seamoby@ietf.org=20 > Subject: Re: [Seamoby] CARD between Routers - will CT do?=20 >=20 >=20 > What do you mean by an SA? An IPSec SA?=20 > ---> By SA, I mean a trust relationship. It can be using an=20 > IPSec SA or=20 > any other means. They have enough information to authenticate=20 > each other.=20 >=20 > If so, how do you propose to have the=20 > routers use that for checking that the AP L2 addresses=20 > provided by the MN map=20 > into IP addresses that are authorized to route on the service=20 > provider's=20 > network?=20 >=20 > ----> We have illustrated one method to do this in our draft.=20 >=20 > Note that the IESG is requiring that the Security=20 > Considerations of all protocol=20 > drafts describe, precisely, how the protocol will be secured.=20 > It is no longer=20 > sufficient to say "use IPSec" or "use AAA". Requiring other=20 > protocols is OK, but=20 > it must be specified precisely how those protocols are used=20 > for securing the=20 > protocol in question.=20 >=20 > -----> OK.=20 >=20 > jak=20 >=20 > ----- Original Message -----=20 > From: "Hemant Chaskar" =20 > To: ; =20 > Cc: ; ;=20 > =20 > Sent: Wednesday, January 15, 2003 8:24 PM=20 > Subject: Re: [Seamoby] CARD between Routers - will CT do?=20 >=20 >=20 > > Hi Daichi:=20 > >=20 > > I do not think that establishment of SA between ARs should=20 > be within scope=20 > > of CARD. We should start from pre-requisite that SA can be=20 > established=20 > > between ARs. When ARs belong to same domain, this is=20 > simple. When they=20 > > belong to different domain it is harder. In either case,=20 > there can be=20 > > variety of ways to establish SAs - pre-shared key, domain specific=20 > > certificates, AAA, credentials exchanged during SLAs or any=20 > other means. Why=20 > > should CARD put any restriction on mechanism used to establish SA?=20 > >=20 > > So, instead of=20 > >=20 > > <--Interworking-->=20 > > |=20 > > Intra-domain CARD | Inter-domain CARD=20 > > protocol | protocol=20 > > --------------------|------------------------------=20 > > Intra-domain SA | Inter-domain SA=20 > > mechanism | mechanism=20 > > (CARD specific?) | (CARD specific?)=20 > >=20 > > I am saying that, if possible, we should try,=20 > >=20 > >=20 > >=20 > > CARD protocol=20 > > ----------------------------------------------=20 > > |=20 > > Intra-domain SA | Inter-domain SA=20 > > mechanisms | mechanisms=20 > > current/future best | (current/future best=20 > > practices) | practices)=20 > >=20 > > At this point, I cannot vouch for security of=20 > MN-report-based CARD approach.=20 > > But, could you describe what kind of attacks do you think=20 > MN-report-based=20 > > CARD is vulnerable to? In=20 > draft-trossen-seamoby-dycard-00.txt, we have shown=20 > > that certain simple mechanisms can foil security attacks in=20 > MN-report-based=20 > > CARD (To the least, if MN tells new AR arbitrary IP address=20 > as address of=20 > > old AR, it can be detected). Also, the side effect of=20 > attacks, if any, does=20 > > not adversely affect good MNs. But, of course, we could=20 > have missed some=20 > > attack possibilities.=20 > >=20 > >=20 > > Hemant=20 > >=20 > > >From: Daichi Funato =20 > > >To: Hemant.Chaskar@nokia.com=20 > > >CC: , ,=20 > =20 > > >Subject: Re: [Seamoby] CARD between Routers - will CT do?=20 > > >Date: Wed, 15 Jan 2003 19:10:15 -0800=20 > > >=20 > > >Hi Hemant,=20 > > >=20 > > > > Hemant --> I think we can start protocol design under=20 > the assumptions=20 > > >that=20 > > > > (i) old and new ARs can establish SA between them, (ii)=20 > they are willing=20 > > >to=20 > > > > participate in CARD protocol. Then, there may not be=20 > any need for=20 > > >intra-domain=20 > > > > / inter-domain classification.=20 > > >=20 > > >What kind of security mechanisms are you assuming?=20 > > >I think we should not leave the security mechanisms out of=20 > the scope.=20 > > >=20 > > >Especially, MN-report-based CARD is vulnerable to an attacker.=20 > > >How to protect the communication is an essential part of=20 > CARD, I think.=20 > > >Actually, IEEE IAPP includes a security mechanism by itself.=20 > > >Do we neglect that part in CARD?=20 > > >=20 > > >IMHO, if CARD can provide secure keys for ARs, these can=20 > be used by CT=20 > > >and FMIP as well. This is another type of capability discovery.=20 > > >What do you think?=20 > > >=20 > > >Best regards,=20 > > >Daichi=20 > > >=20 > > >-------------------------------------------------------------=20 > > >Daichi Funato =20 > > >DoCoMo Communications Laboratories USA, Inc.=20 > > >=20 > > >Confidential Note:=20 > > >Privileged/Confidential Information may be contained in this e-mail = > > >and any attachment to it. Unless you are the addressee indicated in = > > >this e-mail, please notify immediately the sender by reply e-mail=20 > > >that you have received this in error and delete it from=20 > your system.=20 > > >You may not use, copy or deliver this e-mail or any information=20 > > >contained in this e-mail to anyone. Thank you very much.=20 > > >-------------------------------------------------------------=20 > > >=20 > > >_______________________________________________=20 > > >Seamoby mailing list=20 > > >Seamoby@ietf.org=20 > > > https://www1.ietf.org/mailman/listinfo/seamoby=20 > >=20 > >=20 > > _________________________________________________________________=20 > > Add photos to your e-mail with MSN 8. Get 2 months FREE*.=20 > > http://join.msn.com/?page=3Dfeatures/featuredemail=20 > >=20 > >=20 >=20 > _______________________________________________=20 > Seamoby mailing list=20 > Seamoby@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/seamoby=20 > _______________________________________________=20 > Seamoby mailing list=20 > Seamoby@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/seamoby=20 >=20 ------_=_NextPart_001_01C2BE37.D42A49D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Seamoby] CARD between Routers - will CT do?
Hi=20 Gary:
 
See=20 below:
 
-----Original Message-----
From: ext Gary Kenward=20 [mailto:gkenward@nortelnetworks.com]
Sent: Thursday, January = 16, 2003=20 4:01 PM
To: Krishnamurthi Govind (NRC/Boston);=20 kempf@docomolabs-usa.com; funato@docomolabs-usa.com; Chaskar Hemant=20 (NRC/Boston)
Cc: eunsoo@nec-lab.com;=20 seamoby@ietf.org
Subject: RE: [Seamoby] CARD between Routers - = will CT=20 do?

Inter-domain CARD:

Let me see if I understand this correctly: to perform = an=20 inter-system
handover based upon CARD, I would = need a=20 service agreement between
the two operators, = CARD at=20 each AR, CARD at the MN, a path and a protocol
for=20 transferring information (including "topology = information"?)  

[Hemant]=20 There isn't need to transfer topology information. We should call = it rev.=20 adr. translation info which is IP addresses of AR (not all routers in = domain)=20 and their AP IDs.

 
between ARs in=20 two different domains *and* all the aforementioned security =
overhead.

Or, on the other hand, the two operators could agree = to mutually=20 configure
their networks so that the network = controlled=20 handover algorithms direct the
mobile to the = appropriate=20 AR in the neighbouring domain. The handover algorithms
stay basically the same, the operators do not need to exchange = topology=20
information (there are other, easier methods = for finding=20 out where the access
points are mounted, if = that was the=20 intent). But no discovery protocol, no
AR to = AR=20 signalling and no SA required between ARs (other then, perhaps CT,=20
if you believe in CT for=20 seamlessness).  

[Hemant]=20 There is no consensus that network controlled handoff is the way to=20 go. But, even for this case you need a path, protocol and security=20 mechanisms to transfer information between domains. You could call = it CARD.=20 That is of course, you are not suggesting to keep static information = exchanged=20 at the time SLA was struck and manually refresh it whenever something = changes in=20 a network domain. 

Lot's of L2 issues, but they exist in either = scenario.=20

Gary

> -----Original Message-----
>=20 From: Govind.Krishnamurthi@nokia.com
> [mailto:Govind.Krishnamurth= i@nokia.com]=20
> Sent: January 16, 2003 14:50
>=20 To: kempf@docomolabs-usa.com; funato@docomolabs-usa.com; =
> Hemant.Chaskar@nokia.com
> = Cc:=20 eunsoo@nec-lab.com; seamoby@ietf.org
> = Subject: RE:=20 [Seamoby] CARD between Routers - will CT do?
>=20
>
> = Jim,
> comments inline.
> =
> -----Original Message-----
> = From: ext=20 James Kempf [mailto:kempf@docomolabs-usa.com<= /A>]=20
> Sent: Thursday, January 16, 2003 12:49 PM =
> To: Hemant Chaskar; funato@docomolabs-usa.com; Chaskar = Hemant=20
> (NRC/Boston)
> Cc:=20 eunsoo@nec-lab.com; seamoby@ietf.org
> = Subject: Re:=20 [Seamoby] CARD between Routers - will CT do?
>=20
>
> What do = you mean by an=20 SA? An IPSec SA?
> ---> By SA, I mean a = trust=20 relationship. It can be using an
> IPSec SA = or=20
> any other means. They have enough = information to=20 authenticate
> each other.
>
> If so, how do you propose = to have=20 the
> routers use that for checking that = the AP L2=20 addresses
> provided by the MN map =
> into IP addresses that are authorized to route on the = service=20
> provider's
> = network?
>
> = ----> We=20 have illustrated one method to do this in our draft.
>
> Note that the IESG is = requiring that=20 the Security
> Considerations of all = protocol=20
> drafts describe, precisely, how the protocol = will be=20 secured.
> It is no longer
> sufficient to say "use IPSec" or "use AAA". Requiring = other=20
> protocols is OK, but
>=20 it must be specified precisely how those protocols are used =
> for securing the
> protocol = in=20 question.
>
> = ----->=20 OK.
>
>          =   =20 jak
>
> ----- = Original=20 Message -----
> From: "Hemant Chaskar"=20 <hchaskar@hotmail.com>
> To:=20 <funato@docomolabs-usa.com>; = <Hemant.Chaskar@nokia.com>=20
> Cc: <eunsoo@nec-lab.com>;=20 <kempf@docomolabs-usa.com>;
>=20 <seamoby@ietf.org>
> Sent: Wednesday, = January=20 15, 2003 8:24 PM
> Subject: Re: [Seamoby] = CARD=20 between Routers - will CT do?
> =
>
> > Hi Daichi: =
> >
> > I do not think = that=20 establishment of SA between ARs should
> be = within=20 scope
> > of CARD. We should start from=20 pre-requisite that SA can be
> = established=20
> > between ARs. When ARs belong to same = domain, this is=20
> simple. When they
> >=20 belong to different domain it is harder. In either case, =
> there can be
> > variety = of ways to=20 establish SAs - pre-shared key, domain specific
>=20 > certificates, AAA, credentials exchanged during SLAs or any=20
> other means. Why
> >=20 should CARD put any restriction on mechanism used to establish = SA?=20
> >
> > So, = instead=20 of
> >
>=20 >           &nb= sp;          =20 <--Interworking-->
>=20 >           &nb= sp;           &nbs= p;     =20 |
>=20 >          Intra-domain=20 CARD   |       Inter-domain = CARD=20
>=20 >           &nb= sp;   =20 protocol     =20 |          protocol=20
> = >         =20 --------------------|------------------------------
>=20 >          Intra-domain=20 SA     |       = Inter-domain=20 SA
>=20 >           =20 mechanism        =20 |          mechanism =
> = >         (CARD=20 specific?)     |       = (CARD=20 specific?)
> >
> > I=20 am saying that, if possible, we should try,
>=20 >
> >
> = >=20
>=20 >           &nb= sp;           =20 CARD protocol
>=20 >         =20 ----------------------------------------------
>=20 >           &nb= sp;           &nbs= p;      =20 |
>=20 >          Intra-domain=20 SA      |      = Inter-domain=20 SA
>=20 >           &nb= sp;=20 mechanisms       =20 |         mechanisms =
> >         = current/future=20 best   |   (current/future best
>=20 >           &nb= sp;=20 practices)       =20 |          = practices)=20
> >
> > At this = point, I=20 cannot vouch for security of
> = MN-report-based CARD=20 approach.
> > But, could you describe = what kind of=20 attacks do you think
> = MN-report-based=20
> > CARD is vulnerable to? In
> draft-trossen-seamoby-dycard-00.txt, we have shown =
> > that certain simple mechanisms can foil security = attacks in=20
> MN-report-based
> >=20 CARD (To the least, if MN tells new AR arbitrary IP address =
> as address of
> > old AR, = it can be=20 detected). Also, the side effect of
> = attacks, if=20 any, does
> > not adversely affect good = MNs. But,=20 of course, we could
> have missed = some=20
> > attack possibilities.
>=20 >
> >
> = >=20 Hemant
> >
> >=20 >From: Daichi Funato <funato@docomolabs-usa.com> =
> > >To: Hemant.Chaskar@nokia.com
>=20 > >CC: <eunsoo@nec-lab.com>, = <kempf@docomolabs-usa.com>,=20
> <seamoby@ietf.org>
> > >Subject: Re: [Seamoby] CARD between Routers - = will CT=20 do?
> > >Date: Wed, 15 Jan 2003 = 19:10:15=20 -0800
> > >
> >=20 >Hi Hemant,
> > >
> > > > Hemant --> I think we can start protocol = design=20 under
> the assumptions
>=20 > >that
> > > > (i) old and = new ARs=20 can establish SA between them, (ii)
> they = are=20 willing
> > >to
>=20 > > > participate in CARD protocol. Then, there may not be=20
> any need for
> >=20 >intra-domain
> > > > / = inter-domain=20 classification.
> > > =
> > >What kind of security mechanisms are you = assuming?=20
> > >I think we should not leave the = security=20 mechanisms out of
> the scope. =
> > >
> > = >Especially,=20 MN-report-based CARD is vulnerable to an attacker.
>=20 > >How to protect the communication is an essential part of=20
> CARD, I think.
> >=20 >Actually, IEEE IAPP includes a security mechanism by itself.=20
> > >Do we neglect that part in CARD? =
> > >
> > >IMHO, if = CARD can=20 provide secure keys for ARs, these can
> be = used by=20 CT
> > >and FMIP as well. This is = another type=20 of capability discovery.
> > >What do = you=20 think?
> > >
> >=20 >Best regards,
> > >Daichi =
> > >
> >=20 >------------------------------------------------------------- =
> > >Daichi Funato=20 <funato@docomolabs-usa.com>
> > = >DoCoMo=20 Communications Laboratories USA, Inc.
> = >=20 >
> > >Confidential Note: =
> > >Privileged/Confidential Information may be = contained in=20 this e-mail
> > >and any attachment = to it.=20 Unless you are the addressee indicated in
> = >=20 >this e-mail, please notify immediately the sender by reply = e-mail=20
> > >that you have received this in error = and delete=20 it from
> your system.
>=20 > >You may not use, copy or deliver this e-mail or any = information=20
> > >contained in this e-mail to = anyone.  Thank=20 you very much.
> >=20 >------------------------------------------------------------- =
> > >
> >=20 >_______________________________________________
>=20 > >Seamoby mailing list
> >=20 >Seamoby@ietf.org
> > >https://www1.ietf= .org/mailman/listinfo/seamoby=20
> >
> > =
> >=20 _________________________________________________________________ =
> > Add photos to your e-mail with MSN 8. Get 2 = months=20 FREE*.
> > http://join.m= sn.com/?page=3Dfeatures/featuredemail=20
> >
> > =
>
>=20 _______________________________________________
>=20 Seamoby mailing list
> = Seamoby@ietf.org=20
> https://www1.ietf= .org/mailman/listinfo/seamoby=20
> = _______________________________________________=20
> Seamoby mailing list
>=20 Seamoby@ietf.org
> https://www1.ietf= .org/mailman/listinfo/seamoby=20
>

------_=_NextPart_001_01C2BE37.D42A49D0-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Jan 17 10:32:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26128 for ; Fri, 17 Jan 2003 10:32:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HFlAJ08602; Fri, 17 Jan 2003 10:47:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HFhhJ08350 for ; Fri, 17 Jan 2003 10:43:43 -0500 Received: from zcars04e.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25792 for ; Fri, 17 Jan 2003 10:27:29 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0HFUIS01144; Fri, 17 Jan 2003 10:30:18 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 17 Jan 2003 10:30:18 -0500 Message-ID: From: "Gary Kenward" To: "'Hemant.Chaskar@nokia.com'" , Govind.Krishnamurthi@nokia.com, kempf@docomolabs-usa.com, funato@docomolabs-usa.com Cc: eunsoo@nec-lab.com, seamoby@ietf.org Subject: RE: [Seamoby] CARD between Routers - will CT do? Date: Fri, 17 Jan 2003 10:30:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2BE3D.56193410" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2BE3D.56193410 Content-Type: text/plain; charset="iso-8859-1" Thanks Hemant. I still don't understand the need for CARD. The advantage of network controlled handover, or mobile assisted handover, is that you don't have to transfer information across a limited resource channel to an entity, the MN that is clearly less trustworthy. In addition, it's always worth while for the MN to have less responsibilities, as this lowers complexity, power consumption, etc. Thanks again, Gary -----Original Message----- From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] Sent: January 17, 2003 09:51 To: Kenward, Gary [CAR:AN10:EXCH]; Govind.Krishnamurthi@nokia.com; kempf@docomolabs-usa.com; funato@docomolabs-usa.com Cc: eunsoo@nec-lab.com; seamoby@ietf.org Subject: RE: [Seamoby] CARD between Routers - will CT do? Hi Gary: See below: -----Original Message----- From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Thursday, January 16, 2003 4:01 PM To: Krishnamurthi Govind (NRC/Boston); kempf@docomolabs-usa.com; funato@docomolabs-usa.com; Chaskar Hemant (NRC/Boston) Cc: eunsoo@nec-lab.com; seamoby@ietf.org Subject: RE: [Seamoby] CARD between Routers - will CT do? Inter-domain CARD: Let me see if I understand this correctly: to perform an inter-system handover based upon CARD, I would need a service agreement between the two operators, CARD at each AR, CARD at the MN, a path and a protocol for transferring information (including "topology information"?) [Hemant] There isn't need to transfer topology information. We should call it rev. adr. translation info which is IP addresses of AR (not all routers in domain) and their AP IDs. between ARs in two different domains *and* all the aforementioned security overhead. Or, on the other hand, the two operators could agree to mutually configure their networks so that the network controlled handover algorithms direct the mobile to the appropriate AR in the neighbouring domain. The handover algorithms stay basically the same, the operators do not need to exchange topology information (there are other, easier methods for finding out where the access points are mounted, if that was the intent). But no discovery protocol, no AR to AR signalling and no SA required between ARs (other then, perhaps CT, if you believe in CT for seamlessness). [Hemant] There is no consensus that network controlled handoff is the way to go. But, even for this case you need a path, protocol and security mechanisms to transfer information between domains. You could call it CARD. That is of course, you are not suggesting to keep static information exchanged at the time SLA was struck and manually refresh it whenever something changes in a network domain. Lot's of L2 issues, but they exist in either scenario. Gary > -----Original Message----- > From: Govind.Krishnamurthi@nokia.com > [ mailto:Govind.Krishnamurthi@nokia.com ] > Sent: January 16, 2003 14:50 > To: kempf@docomolabs-usa.com; funato@docomolabs-usa.com; > Hemant.Chaskar@nokia.com > Cc: eunsoo@nec-lab.com; seamoby@ietf.org > Subject: RE: [Seamoby] CARD between Routers - will CT do? > > > Jim, > comments inline. > > -----Original Message----- > From: ext James Kempf [ mailto:kempf@docomolabs-usa.com ] > Sent: Thursday, January 16, 2003 12:49 PM > To: Hemant Chaskar; funato@docomolabs-usa.com; Chaskar Hemant > (NRC/Boston) > Cc: eunsoo@nec-lab.com; seamoby@ietf.org > Subject: Re: [Seamoby] CARD between Routers - will CT do? > > > What do you mean by an SA? An IPSec SA? > ---> By SA, I mean a trust relationship. It can be using an > IPSec SA or > any other means. They have enough information to authenticate > each other. > > If so, how do you propose to have the > routers use that for checking that the AP L2 addresses > provided by the MN map > into IP addresses that are authorized to route on the service > provider's > network? > > ----> We have illustrated one method to do this in our draft. > > Note that the IESG is requiring that the Security > Considerations of all protocol > drafts describe, precisely, how the protocol will be secured. > It is no longer > sufficient to say "use IPSec" or "use AAA". Requiring other > protocols is OK, but > it must be specified precisely how those protocols are used > for securing the > protocol in question. > > -----> OK. > > jak > > ----- Original Message ----- > From: "Hemant Chaskar" > To: ; > Cc: ; ; > > Sent: Wednesday, January 15, 2003 8:24 PM > Subject: Re: [Seamoby] CARD between Routers - will CT do? > > > > Hi Daichi: > > > > I do not think that establishment of SA between ARs should > be within scope > > of CARD. We should start from pre-requisite that SA can be > established > > between ARs. When ARs belong to same domain, this is > simple. When they > > belong to different domain it is harder. In either case, > there can be > > variety of ways to establish SAs - pre-shared key, domain specific > > certificates, AAA, credentials exchanged during SLAs or any > other means. Why > > should CARD put any restriction on mechanism used to establish SA? > > > > So, instead of > > > > <--Interworking--> > > | > > Intra-domain CARD | Inter-domain CARD > > protocol | protocol > > --------------------|------------------------------ > > Intra-domain SA | Inter-domain SA > > mechanism | mechanism > > (CARD specific?) | (CARD specific?) > > > > I am saying that, if possible, we should try, > > > > > > > > CARD protocol > > ---------------------------------------------- > > | > > Intra-domain SA | Inter-domain SA > > mechanisms | mechanisms > > current/future best | (current/future best > > practices) | practices) > > > > At this point, I cannot vouch for security of > MN-report-based CARD approach. > > But, could you describe what kind of attacks do you think > MN-report-based > > CARD is vulnerable to? In > draft-trossen-seamoby-dycard-00.txt, we have shown > > that certain simple mechanisms can foil security attacks in > MN-report-based > > CARD (To the least, if MN tells new AR arbitrary IP address > as address of > > old AR, it can be detected). Also, the side effect of > attacks, if any, does > > not adversely affect good MNs. But, of course, we could > have missed some > > attack possibilities. > > > > > > Hemant > > > > >From: Daichi Funato > > >To: Hemant.Chaskar@nokia.com > > >CC: , , > > > >Subject: Re: [Seamoby] CARD between Routers - will CT do? > > >Date: Wed, 15 Jan 2003 19:10:15 -0800 > > > > > >Hi Hemant, > > > > > > > Hemant --> I think we can start protocol design under > the assumptions > > >that > > > > (i) old and new ARs can establish SA between them, (ii) > they are willing > > >to > > > > participate in CARD protocol. Then, there may not be > any need for > > >intra-domain > > > > / inter-domain classification. > > > > > >What kind of security mechanisms are you assuming? > > >I think we should not leave the security mechanisms out of > the scope. > > > > > >Especially, MN-report-based CARD is vulnerable to an attacker. > > >How to protect the communication is an essential part of > CARD, I think. > > >Actually, IEEE IAPP includes a security mechanism by itself. > > >Do we neglect that part in CARD? > > > > > >IMHO, if CARD can provide secure keys for ARs, these can > be used by CT > > >and FMIP as well. This is another type of capability discovery. > > >What do you think? > > > > > >Best regards, > > >Daichi > > > > > >------------------------------------------------------------- > > >Daichi Funato > > >DoCoMo Communications Laboratories USA, Inc. > > > > > >Confidential Note: > > >Privileged/Confidential Information may be contained in this e-mail > > >and any attachment to it. Unless you are the addressee indicated in > > >this e-mail, please notify immediately the sender by reply e-mail > > >that you have received this in error and delete it from > your system. > > >You may not use, copy or deliver this e-mail or any information > > >contained in this e-mail to anyone. Thank you very much. > > >------------------------------------------------------------- > > > > > >_______________________________________________ > > >Seamoby mailing list > > >Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _________________________________________________________________ > > Add photos to your e-mail with MSN 8. Get 2 months FREE*. > > http://join.msn.com/?page=features/featuredemail > > > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > ------_=_NextPart_001_01C2BE3D.56193410 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] CARD between Routers - will CT do?
Thanks Hemant.
 
I still don't understand the need for CARD.
 
The advantage of network controlled handover, or mobile assisted handover,
is that you don't have to transfer information across a limited resource channel
to an entity, the MN that is clearly less trustworthy. In addition, it's always worth
while for the MN to have less responsibilities, as this lowers complexity, power
consumption, etc.
 
Thanks again,
Gary
-----Original Message-----
From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com]
Sent: January 17, 2003 09:51
To: Kenward, Gary [CAR:AN10:EXCH]; Govind.Krishnamurthi@nokia.com; kempf@docomolabs-usa.com; funato@docomolabs-usa.com
Cc: eunsoo@nec-lab.com; seamoby@ietf.org
Subject: RE: [Seamoby] CARD between Routers - will CT do?

Hi Gary:
 
See below:
 
-----Original Message-----
From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Thursday, January 16, 2003 4:01 PM
To: Krishnamurthi Govind (NRC/Boston); kempf@docomolabs-usa.com; funato@docomolabs-usa.com; Chaskar Hemant (NRC/Boston)
Cc: eunsoo@nec-lab.com; seamoby@ietf.org
Subject: RE: [Seamoby] CARD between Routers - will CT do?

Inter-domain CARD:

Let me see if I understand this correctly: to perform an inter-system
handover based upon CARD, I would need a service agreement between
the two operators, CARD at each AR, CARD at the MN, a path and a protocol
for transferring information (including "topology information"?)  

[Hemant] There isn't need to transfer topology information. We should call it rev. adr. translation info which is IP addresses of AR (not all routers in domain) and their AP IDs.


between ARs in two different domains *and* all the aforementioned security
overhead.

Or, on the other hand, the two operators could agree to mutually configure
their networks so that the network controlled handover algorithms direct the
mobile to the appropriate AR in the neighbouring domain. The handover algorithms
stay basically the same, the operators do not need to exchange topology
information (there are other, easier methods for finding out where the access
points are mounted, if that was the intent). But no discovery protocol, no
AR to AR signalling and no SA required between ARs (other then, perhaps CT,
if you believe in CT for seamlessness).  

[Hemant] There is no consensus that network controlled handoff is the way to go. But, even for this case you need a path, protocol and security mechanisms to transfer information between domains. You could call it CARD. That is of course, you are not suggesting to keep static information exchanged at the time SLA was struck and manually refresh it whenever something changes in a network domain. 

Lot's of L2 issues, but they exist in either scenario.

Gary

> -----Original Message-----
> From: Govind.Krishnamurthi@nokia.com
> [mailto:Govind.Krishnamurthi@nokia.com]
> Sent: January 16, 2003 14:50
> To: kempf@docomolabs-usa.com; funato@docomolabs-usa.com;
> Hemant.Chaskar@nokia.com
> Cc: eunsoo@nec-lab.com; seamoby@ietf.org
> Subject: RE: [Seamoby] CARD between Routers - will CT do?
>
>
> Jim,
> comments inline.
>
> -----Original Message-----
> From: ext James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: Thursday, January 16, 2003 12:49 PM
> To: Hemant Chaskar; funato@docomolabs-usa.com; Chaskar Hemant
> (NRC/Boston)
> Cc: eunsoo@nec-lab.com; seamoby@ietf.org
> Subject: Re: [Seamoby] CARD between Routers - will CT do?
>
>
> What do you mean by an SA? An IPSec SA?
> ---> By SA, I mean a trust relationship. It can be using an
> IPSec SA or
> any other means. They have enough information to authenticate
> each other.
>
> If so, how do you propose to have the
> routers use that for checking that the AP L2 addresses
> provided by the MN map
> into IP addresses that are authorized to route on the service
> provider's
> network?
>
> ----> We have illustrated one method to do this in our draft.
>
> Note that the IESG is requiring that the Security
> Considerations of all protocol
> drafts describe, precisely, how the protocol will be secured.
> It is no longer
> sufficient to say "use IPSec" or "use AAA". Requiring other
> protocols is OK, but
> it must be specified precisely how those protocols are used
> for securing the
> protocol in question.
>
> -----> OK.
>
>             jak
>
> ----- Original Message -----
> From: "Hemant Chaskar" <hchaskar@hotmail.com>
> To: <funato@docomolabs-usa.com>; <Hemant.Chaskar@nokia.com>
> Cc: <eunsoo@nec-lab.com>; <kempf@docomolabs-usa.com>;
> <seamoby@ietf.org>
> Sent: Wednesday, January 15, 2003 8:24 PM
> Subject: Re: [Seamoby] CARD between Routers - will CT do?
>
>
> > Hi Daichi:
> >
> > I do not think that establishment of SA between ARs should
> be within scope
> > of CARD. We should start from pre-requisite that SA can be
> established
> > between ARs. When ARs belong to same domain, this is
> simple. When they
> > belong to different domain it is harder. In either case,
> there can be
> > variety of ways to establish SAs - pre-shared key, domain specific
> > certificates, AAA, credentials exchanged during SLAs or any
> other means. Why
> > should CARD put any restriction on mechanism used to establish SA?
> >
> > So, instead of
> >
> >                       <--Interworking-->
> >                              |
> >          Intra-domain CARD   |       Inter-domain CARD
> >                protocol      |          protocol
> >          --------------------|------------------------------
> >          Intra-domain SA     |       Inter-domain SA
> >            mechanism         |          mechanism
> >         (CARD specific?)     |       (CARD specific?)
> >
> > I am saying that, if possible, we should try,
> >
> >
> >
> >                        CARD protocol
> >          ----------------------------------------------
> >                               |
> >          Intra-domain SA      |      Inter-domain SA
> >             mechanisms        |         mechanisms
> >         current/future best   |   (current/future best
> >             practices)        |          practices)
> >
> > At this point, I cannot vouch for security of
> MN-report-based CARD approach.
> > But, could you describe what kind of attacks do you think
> MN-report-based
> > CARD is vulnerable to? In
> draft-trossen-seamoby-dycard-00.txt, we have shown
> > that certain simple mechanisms can foil security attacks in
> MN-report-based
> > CARD (To the least, if MN tells new AR arbitrary IP address
> as address of
> > old AR, it can be detected). Also, the side effect of
> attacks, if any, does
> > not adversely affect good MNs. But, of course, we could
> have missed some
> > attack possibilities.
> >
> >
> > Hemant
> >
> > >From: Daichi Funato <funato@docomolabs-usa.com>
> > >To: Hemant.Chaskar@nokia.com
> > >CC: <eunsoo@nec-lab.com>, <kempf@docomolabs-usa.com>,
> <seamoby@ietf.org>
> > >Subject: Re: [Seamoby] CARD between Routers - will CT do?
> > >Date: Wed, 15 Jan 2003 19:10:15 -0800
> > >
> > >Hi Hemant,
> > >
> > > > Hemant --> I think we can start protocol design under
> the assumptions
> > >that
> > > > (i) old and new ARs can establish SA between them, (ii)
> they are willing
> > >to
> > > > participate in CARD protocol. Then, there may not be
> any need for
> > >intra-domain
> > > > / inter-domain classification.
> > >
> > >What kind of security mechanisms are you assuming?
> > >I think we should not leave the security mechanisms out of
> the scope.
> > >
> > >Especially, MN-report-based CARD is vulnerable to an attacker.
> > >How to protect the communication is an essential part of
> CARD, I think.
> > >Actually, IEEE IAPP includes a security mechanism by itself.
> > >Do we neglect that part in CARD?
> > >
> > >IMHO, if CARD can provide secure keys for ARs, these can
> be used by CT
> > >and FMIP as well. This is another type of capability discovery.
> > >What do you think?
> > >
> > >Best regards,
> > >Daichi
> > >
> > >-------------------------------------------------------------
> > >Daichi Funato <funato@docomolabs-usa.com>
> > >DoCoMo Communications Laboratories USA, Inc.
> > >
> > >Confidential Note:
> > >Privileged/Confidential Information may be contained in this e-mail
> > >and any attachment to it. Unless you are the addressee indicated in
> > >this e-mail, please notify immediately the sender by reply e-mail
> > >that you have received this in error and delete it from
> your system.
> > >You may not use, copy or deliver this e-mail or any information
> > >contained in this e-mail to anyone.  Thank you very much.
> > >-------------------------------------------------------------
> > >
> > >_______________________________________________
> > >Seamoby mailing list
> > >Seamoby@ietf.org
> > >https://www1.ietf.org/mailman/listinfo/seamoby
> >
> >
> > _________________________________________________________________
> > Add photos to your e-mail with MSN 8. Get 2 months FREE*.
> > http://join.msn.com/?page=features/featuredemail
> >
> >
>
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

------_=_NextPart_001_01C2BE3D.56193410-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Jan 17 10:33:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26152 for ; Fri, 17 Jan 2003 10:33:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0HFn7K08779 for seamoby-archive@odin.ietf.org; Fri, 17 Jan 2003 10:49:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HFn6J08776 for ; Fri, 17 Jan 2003 10:49:06 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26142 for ; Fri, 17 Jan 2003 10:32:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HFlAJ08602; Fri, 17 Jan 2003 10:47:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HFhhJ08350 for ; Fri, 17 Jan 2003 10:43:43 -0500 Received: from zcars04e.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25792 for ; Fri, 17 Jan 2003 10:27:29 -0500 (EST) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0HFUIS01144; Fri, 17 Jan 2003 10:30:18 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 17 Jan 2003 10:30:18 -0500 Message-ID: From: "Gary Kenward" To: "'Hemant.Chaskar@nokia.com'" , Govind.Krishnamurthi@nokia.com, kempf@docomolabs-usa.com, funato@docomolabs-usa.com Cc: eunsoo@nec-lab.com, seamoby@ietf.org Subject: RE: [Seamoby] CARD between Routers - will CT do? Date: Fri, 17 Jan 2003 10:30:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2BE3D.56193410" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2BE3D.56193410 Content-Type: text/plain; charset="iso-8859-1" Thanks Hemant. I still don't understand the need for CARD. The advantage of network controlled handover, or mobile assisted handover, is that you don't have to transfer information across a limited resource channel to an entity, the MN that is clearly less trustworthy. In addition, it's always worth while for the MN to have less responsibilities, as this lowers complexity, power consumption, etc. Thanks again, Gary -----Original Message----- From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com] Sent: January 17, 2003 09:51 To: Kenward, Gary [CAR:AN10:EXCH]; Govind.Krishnamurthi@nokia.com; kempf@docomolabs-usa.com; funato@docomolabs-usa.com Cc: eunsoo@nec-lab.com; seamoby@ietf.org Subject: RE: [Seamoby] CARD between Routers - will CT do? Hi Gary: See below: -----Original Message----- From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Thursday, January 16, 2003 4:01 PM To: Krishnamurthi Govind (NRC/Boston); kempf@docomolabs-usa.com; funato@docomolabs-usa.com; Chaskar Hemant (NRC/Boston) Cc: eunsoo@nec-lab.com; seamoby@ietf.org Subject: RE: [Seamoby] CARD between Routers - will CT do? Inter-domain CARD: Let me see if I understand this correctly: to perform an inter-system handover based upon CARD, I would need a service agreement between the two operators, CARD at each AR, CARD at the MN, a path and a protocol for transferring information (including "topology information"?) [Hemant] There isn't need to transfer topology information. We should call it rev. adr. translation info which is IP addresses of AR (not all routers in domain) and their AP IDs. between ARs in two different domains *and* all the aforementioned security overhead. Or, on the other hand, the two operators could agree to mutually configure their networks so that the network controlled handover algorithms direct the mobile to the appropriate AR in the neighbouring domain. The handover algorithms stay basically the same, the operators do not need to exchange topology information (there are other, easier methods for finding out where the access points are mounted, if that was the intent). But no discovery protocol, no AR to AR signalling and no SA required between ARs (other then, perhaps CT, if you believe in CT for seamlessness). [Hemant] There is no consensus that network controlled handoff is the way to go. But, even for this case you need a path, protocol and security mechanisms to transfer information between domains. You could call it CARD. That is of course, you are not suggesting to keep static information exchanged at the time SLA was struck and manually refresh it whenever something changes in a network domain. Lot's of L2 issues, but they exist in either scenario. Gary > -----Original Message----- > From: Govind.Krishnamurthi@nokia.com > [ mailto:Govind.Krishnamurthi@nokia.com ] > Sent: January 16, 2003 14:50 > To: kempf@docomolabs-usa.com; funato@docomolabs-usa.com; > Hemant.Chaskar@nokia.com > Cc: eunsoo@nec-lab.com; seamoby@ietf.org > Subject: RE: [Seamoby] CARD between Routers - will CT do? > > > Jim, > comments inline. > > -----Original Message----- > From: ext James Kempf [ mailto:kempf@docomolabs-usa.com ] > Sent: Thursday, January 16, 2003 12:49 PM > To: Hemant Chaskar; funato@docomolabs-usa.com; Chaskar Hemant > (NRC/Boston) > Cc: eunsoo@nec-lab.com; seamoby@ietf.org > Subject: Re: [Seamoby] CARD between Routers - will CT do? > > > What do you mean by an SA? An IPSec SA? > ---> By SA, I mean a trust relationship. It can be using an > IPSec SA or > any other means. They have enough information to authenticate > each other. > > If so, how do you propose to have the > routers use that for checking that the AP L2 addresses > provided by the MN map > into IP addresses that are authorized to route on the service > provider's > network? > > ----> We have illustrated one method to do this in our draft. > > Note that the IESG is requiring that the Security > Considerations of all protocol > drafts describe, precisely, how the protocol will be secured. > It is no longer > sufficient to say "use IPSec" or "use AAA". Requiring other > protocols is OK, but > it must be specified precisely how those protocols are used > for securing the > protocol in question. > > -----> OK. > > jak > > ----- Original Message ----- > From: "Hemant Chaskar" > To: ; > Cc: ; ; > > Sent: Wednesday, January 15, 2003 8:24 PM > Subject: Re: [Seamoby] CARD between Routers - will CT do? > > > > Hi Daichi: > > > > I do not think that establishment of SA between ARs should > be within scope > > of CARD. We should start from pre-requisite that SA can be > established > > between ARs. When ARs belong to same domain, this is > simple. When they > > belong to different domain it is harder. In either case, > there can be > > variety of ways to establish SAs - pre-shared key, domain specific > > certificates, AAA, credentials exchanged during SLAs or any > other means. Why > > should CARD put any restriction on mechanism used to establish SA? > > > > So, instead of > > > > <--Interworking--> > > | > > Intra-domain CARD | Inter-domain CARD > > protocol | protocol > > --------------------|------------------------------ > > Intra-domain SA | Inter-domain SA > > mechanism | mechanism > > (CARD specific?) | (CARD specific?) > > > > I am saying that, if possible, we should try, > > > > > > > > CARD protocol > > ---------------------------------------------- > > | > > Intra-domain SA | Inter-domain SA > > mechanisms | mechanisms > > current/future best | (current/future best > > practices) | practices) > > > > At this point, I cannot vouch for security of > MN-report-based CARD approach. > > But, could you describe what kind of attacks do you think > MN-report-based > > CARD is vulnerable to? In > draft-trossen-seamoby-dycard-00.txt, we have shown > > that certain simple mechanisms can foil security attacks in > MN-report-based > > CARD (To the least, if MN tells new AR arbitrary IP address > as address of > > old AR, it can be detected). Also, the side effect of > attacks, if any, does > > not adversely affect good MNs. But, of course, we could > have missed some > > attack possibilities. > > > > > > Hemant > > > > >From: Daichi Funato > > >To: Hemant.Chaskar@nokia.com > > >CC: , , > > > >Subject: Re: [Seamoby] CARD between Routers - will CT do? > > >Date: Wed, 15 Jan 2003 19:10:15 -0800 > > > > > >Hi Hemant, > > > > > > > Hemant --> I think we can start protocol design under > the assumptions > > >that > > > > (i) old and new ARs can establish SA between them, (ii) > they are willing > > >to > > > > participate in CARD protocol. Then, there may not be > any need for > > >intra-domain > > > > / inter-domain classification. > > > > > >What kind of security mechanisms are you assuming? > > >I think we should not leave the security mechanisms out of > the scope. > > > > > >Especially, MN-report-based CARD is vulnerable to an attacker. > > >How to protect the communication is an essential part of > CARD, I think. > > >Actually, IEEE IAPP includes a security mechanism by itself. > > >Do we neglect that part in CARD? > > > > > >IMHO, if CARD can provide secure keys for ARs, these can > be used by CT > > >and FMIP as well. This is another type of capability discovery. > > >What do you think? > > > > > >Best regards, > > >Daichi > > > > > >------------------------------------------------------------- > > >Daichi Funato > > >DoCoMo Communications Laboratories USA, Inc. > > > > > >Confidential Note: > > >Privileged/Confidential Information may be contained in this e-mail > > >and any attachment to it. Unless you are the addressee indicated in > > >this e-mail, please notify immediately the sender by reply e-mail > > >that you have received this in error and delete it from > your system. > > >You may not use, copy or deliver this e-mail or any information > > >contained in this e-mail to anyone. Thank you very much. > > >------------------------------------------------------------- > > > > > >_______________________________________________ > > >Seamoby mailing list > > >Seamoby@ietf.org > > > https://www1.ietf.org/mailman/listinfo/seamoby > > > > > > _________________________________________________________________ > > Add photos to your e-mail with MSN 8. Get 2 months FREE*. > > http://join.msn.com/?page=features/featuredemail > > > > > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby > ------_=_NextPart_001_01C2BE3D.56193410 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] CARD between Routers - will CT do?
Thanks Hemant.
 
I still don't understand the need for CARD.
 
The advantage of network controlled handover, or mobile assisted handover,
is that you don't have to transfer information across a limited resource channel
to an entity, the MN that is clearly less trustworthy. In addition, it's always worth
while for the MN to have less responsibilities, as this lowers complexity, power
consumption, etc.
 
Thanks again,
Gary
-----Original Message-----
From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com]
Sent: January 17, 2003 09:51
To: Kenward, Gary [CAR:AN10:EXCH]; Govind.Krishnamurthi@nokia.com; kempf@docomolabs-usa.com; funato@docomolabs-usa.com
Cc: eunsoo@nec-lab.com; seamoby@ietf.org
Subject: RE: [Seamoby] CARD between Routers - will CT do?

Hi Gary:
 
See below:
 
-----Original Message-----
From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Thursday, January 16, 2003 4:01 PM
To: Krishnamurthi Govind (NRC/Boston); kempf@docomolabs-usa.com; funato@docomolabs-usa.com; Chaskar Hemant (NRC/Boston)
Cc: eunsoo@nec-lab.com; seamoby@ietf.org
Subject: RE: [Seamoby] CARD between Routers - will CT do?

Inter-domain CARD:

Let me see if I understand this correctly: to perform an inter-system
handover based upon CARD, I would need a service agreement between
the two operators, CARD at each AR, CARD at the MN, a path and a protocol
for transferring information (including "topology information"?)  

[Hemant] There isn't need to transfer topology information. We should call it rev. adr. translation info which is IP addresses of AR (not all routers in domain) and their AP IDs.


between ARs in two different domains *and* all the aforementioned security
overhead.

Or, on the other hand, the two operators could agree to mutually configure
their networks so that the network controlled handover algorithms direct the
mobile to the appropriate AR in the neighbouring domain. The handover algorithms
stay basically the same, the operators do not need to exchange topology
information (there are other, easier methods for finding out where the access
points are mounted, if that was the intent). But no discovery protocol, no
AR to AR signalling and no SA required between ARs (other then, perhaps CT,
if you believe in CT for seamlessness).  

[Hemant] There is no consensus that network controlled handoff is the way to go. But, even for this case you need a path, protocol and security mechanisms to transfer information between domains. You could call it CARD. That is of course, you are not suggesting to keep static information exchanged at the time SLA was struck and manually refresh it whenever something changes in a network domain. 

Lot's of L2 issues, but they exist in either scenario.

Gary

> -----Original Message-----
> From: Govind.Krishnamurthi@nokia.com
> [mailto:Govind.Krishnamurthi@nokia.com]
> Sent: January 16, 2003 14:50
> To: kempf@docomolabs-usa.com; funato@docomolabs-usa.com;
> Hemant.Chaskar@nokia.com
> Cc: eunsoo@nec-lab.com; seamoby@ietf.org
> Subject: RE: [Seamoby] CARD between Routers - will CT do?
>
>
> Jim,
> comments inline.
>
> -----Original Message-----
> From: ext James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: Thursday, January 16, 2003 12:49 PM
> To: Hemant Chaskar; funato@docomolabs-usa.com; Chaskar Hemant
> (NRC/Boston)
> Cc: eunsoo@nec-lab.com; seamoby@ietf.org
> Subject: Re: [Seamoby] CARD between Routers - will CT do?
>
>
> What do you mean by an SA? An IPSec SA?
> ---> By SA, I mean a trust relationship. It can be using an
> IPSec SA or
> any other means. They have enough information to authenticate
> each other.
>
> If so, how do you propose to have the
> routers use that for checking that the AP L2 addresses
> provided by the MN map
> into IP addresses that are authorized to route on the service
> provider's
> network?
>
> ----> We have illustrated one method to do this in our draft.
>
> Note that the IESG is requiring that the Security
> Considerations of all protocol
> drafts describe, precisely, how the protocol will be secured.
> It is no longer
> sufficient to say "use IPSec" or "use AAA". Requiring other
> protocols is OK, but
> it must be specified precisely how those protocols are used
> for securing the
> protocol in question.
>
> -----> OK.
>
>             jak
>
> ----- Original Message -----
> From: "Hemant Chaskar" <hchaskar@hotmail.com>
> To: <funato@docomolabs-usa.com>; <Hemant.Chaskar@nokia.com>
> Cc: <eunsoo@nec-lab.com>; <kempf@docomolabs-usa.com>;
> <seamoby@ietf.org>
> Sent: Wednesday, January 15, 2003 8:24 PM
> Subject: Re: [Seamoby] CARD between Routers - will CT do?
>
>
> > Hi Daichi:
> >
> > I do not think that establishment of SA between ARs should
> be within scope
> > of CARD. We should start from pre-requisite that SA can be
> established
> > between ARs. When ARs belong to same domain, this is
> simple. When they
> > belong to different domain it is harder. In either case,
> there can be
> > variety of ways to establish SAs - pre-shared key, domain specific
> > certificates, AAA, credentials exchanged during SLAs or any
> other means. Why
> > should CARD put any restriction on mechanism used to establish SA?
> >
> > So, instead of
> >
> >                       <--Interworking-->
> >                              |
> >          Intra-domain CARD   |       Inter-domain CARD
> >                protocol      |          protocol
> >          --------------------|------------------------------
> >          Intra-domain SA     |       Inter-domain SA
> >            mechanism         |          mechanism
> >         (CARD specific?)     |       (CARD specific?)
> >
> > I am saying that, if possible, we should try,
> >
> >
> >
> >                        CARD protocol
> >          ----------------------------------------------
> >                               |
> >          Intra-domain SA      |      Inter-domain SA
> >             mechanisms        |         mechanisms
> >         current/future best   |   (current/future best
> >             practices)        |          practices)
> >
> > At this point, I cannot vouch for security of
> MN-report-based CARD approach.
> > But, could you describe what kind of attacks do you think
> MN-report-based
> > CARD is vulnerable to? In
> draft-trossen-seamoby-dycard-00.txt, we have shown
> > that certain simple mechanisms can foil security attacks in
> MN-report-based
> > CARD (To the least, if MN tells new AR arbitrary IP address
> as address of
> > old AR, it can be detected). Also, the side effect of
> attacks, if any, does
> > not adversely affect good MNs. But, of course, we could
> have missed some
> > attack possibilities.
> >
> >
> > Hemant
> >
> > >From: Daichi Funato <funato@docomolabs-usa.com>
> > >To: Hemant.Chaskar@nokia.com
> > >CC: <eunsoo@nec-lab.com>, <kempf@docomolabs-usa.com>,
> <seamoby@ietf.org>
> > >Subject: Re: [Seamoby] CARD between Routers - will CT do?
> > >Date: Wed, 15 Jan 2003 19:10:15 -0800
> > >
> > >Hi Hemant,
> > >
> > > > Hemant --> I think we can start protocol design under
> the assumptions
> > >that
> > > > (i) old and new ARs can establish SA between them, (ii)
> they are willing
> > >to
> > > > participate in CARD protocol. Then, there may not be
> any need for
> > >intra-domain
> > > > / inter-domain classification.
> > >
> > >What kind of security mechanisms are you assuming?
> > >I think we should not leave the security mechanisms out of
> the scope.
> > >
> > >Especially, MN-report-based CARD is vulnerable to an attacker.
> > >How to protect the communication is an essential part of
> CARD, I think.
> > >Actually, IEEE IAPP includes a security mechanism by itself.
> > >Do we neglect that part in CARD?
> > >
> > >IMHO, if CARD can provide secure keys for ARs, these can
> be used by CT
> > >and FMIP as well. This is another type of capability discovery.
> > >What do you think?
> > >
> > >Best regards,
> > >Daichi
> > >
> > >-------------------------------------------------------------
> > >Daichi Funato <funato@docomolabs-usa.com>
> > >DoCoMo Communications Laboratories USA, Inc.
> > >
> > >Confidential Note:
> > >Privileged/Confidential Information may be contained in this e-mail
> > >and any attachment to it. Unless you are the addressee indicated in
> > >this e-mail, please notify immediately the sender by reply e-mail
> > >that you have received this in error and delete it from
> your system.
> > >You may not use, copy or deliver this e-mail or any information
> > >contained in this e-mail to anyone.  Thank you very much.
> > >-------------------------------------------------------------
> > >
> > >_______________________________________________
> > >Seamoby mailing list
> > >Seamoby@ietf.org
> > >https://www1.ietf.org/mailman/listinfo/seamoby
> >
> >
> > _________________________________________________________________
> > Add photos to your e-mail with MSN 8. Get 2 months FREE*.
> > http://join.msn.com/?page=features/featuredemail
> >
> >
>
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
> _______________________________________________
> Seamoby mailing list
> Seamoby@ietf.org
> https://www1.ietf.org/mailman/listinfo/seamoby
>

------_=_NextPart_001_01C2BE3D.56193410-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Fri Jan 17 16:36:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05133 for ; Fri, 17 Jan 2003 16:36:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HLpFJ32135; Fri, 17 Jan 2003 16:51:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HLa9J30988 for ; Fri, 17 Jan 2003 16:36:09 -0500 Received: from fep03-mail.bloor.is.net.cable.rogers.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04748 for ; Fri, 17 Jan 2003 16:19:52 -0500 (EST) Received: from ee.ryerson.ca ([24.112.78.44]) by fep03-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.05.06 201-253-122-126-106-20020509) with ESMTP id <20030117212212.RSJP148587.fep03-mail.bloor.is.net.cable.rogers.com@ee.ryerson.ca> for ; Fri, 17 Jan 2003 16:22:12 -0500 Message-ID: <3E287428.6000407@ee.ryerson.ca> Date: Fri, 17 Jan 2003 16:22:48 -0500 From: Muhammad Jaseemuddin Organization: Ryerson University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: seamoby@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH PLAIN at fep03-mail.bloor.is.net.cable.rogers.com from [24.112.78.44] using ID at Fri, 17 Jan 2003 16:22:12 -0500 Content-Transfer-Encoding: 7bit Subject: [Seamoby] CFP: IEEE VTC Symposium on IP Mobility 2003 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Call for Papers - IP Mobility 2003 IEEE VTC Symposium on IP Mobility October 4-9, 2003 Orlando, FL, USA in Conjunction with IEEE VTC Fall 2003 Submission Deadline: February 15, 2003 Scope ===== Mobility support in IP network has been an area of active research and development. The impacts of mobility and wireless medium at all layers of Internet architecture have generated wide range of interest in the research community. IETF has been working on standardizing protocols for inter-domain and intra-domain mobility, context transfer, routing for network mobility and ad-hoc networks. This symposium is aimed at providing researchers and practitioners a forum for presenting their research at all layers of Internet architecture and sharing experiences. It will provide a unique opportunity to people from academia and industry to exchange their ideas on short-term and long-term research issues. The theme of this symposium is **Support for Network Mobility**. The outcome of the symposium is expected to present a view on how close to reality is IP Mobility and set a direction for research to deal with emerging issues. The papers must discuss issues and solutions related to support for wireless medium and mobility in IP network. The symposium solicits papers related to but not limited to the following areas: * Routing for host (e.g. terminals) and network (e.g. trains, buses) mobility, protocols and performance * New approaches to wide-area and local mobility * Quality of Service models, resource management, and provisioning * Traffic Engineering in mobile wireless IP access networks * Transport protocol design for mobile wireless networks * Security including security threat models, threat analysis and their impact on routing * Application level protocol design and performance * Mobile and wireless applications, their service requirements and performance * Content delivery support in IP network for mobile users * Multicasting for mobile wireless services * Emerging network architectures (e.g. multi-hop ad-hoc network, sensor network) * Internetworking of different network types (e.g. ad-hoc to cellular, wireless LAN to cellular) * Inter-vehicular network architecture * Mobile wireless IP access network deployment and management Posters are also solicited on the projects related to the symposium theme. Submission Instructions ======================= Authors MUST submit an extended abstract (up to 2 pages) through the EDAS web site (http://www.edas.info/), together with a short abstract (approximately 150 words) in the EDAS web site form. Please note that the potential authors should create your own account in the EDAS web site (http://www.edas.info/) before submitting paper(s). Although either MS Word or PDF file format is acceptable when submitting the extended abstracts, it is strongly suggested that authors should submit papers using PDF format. The submission(s) should include complete contacting information of the author(s), such as the name, mailing address, telephone and fax numbers, and email address. All submitted papers are subject to peer review. Submissions can also be made using the links of call for technical papers in the conference web site: http://www.vtc2003.org/. Important Dates Extended Abstract Due: February 15, 2003 Acceptance Notification: April 15, 2003 Camera Ready Copy of Full Paper Due: July 15, 2003 Symposium Date: October 4, 2003 Organization ============ Program Co-Chairs: Muhammad Jaseemuddin (jaseem@ee.ryerson.ca) Department of Electrical and Computer Engineering Ryerson University Toronto, Canada Hongyi Li (hyli@nortelnetworks.com) Wireless Technology Lab Nortel Networks Ottawa, Canada Publicity Co-Chair: Junaid Zubairi (junaid.zubairi@fredonia.edu) Department of Mathematics and Computer Science SUNY at Fredonia Fredonia, NY, USA Technical Program Committee =========================== * Ahmed Helmy (USC) * Yasser Rasheed (Intel) * Raouf Boutaba (University of Waterloo) * Sajal Das (The University of Texas at Arlington) * Haseeb Akhtar (inCode Telecom group, CA) * Lars Wolf (TU Braunschweig, Germany) * Samir R. Das (SUNY at Stony Brook) * Thiery Ernst (Wide, Keio U Japan) * Abdelsalam Helal (U of Florida, Gainesville) * Govindan Ravindran (Soma Networks) _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Fri Jan 17 16:36:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05156 for ; Fri, 17 Jan 2003 16:36:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0HLqNR32221 for seamoby-archive@odin.ietf.org; Fri, 17 Jan 2003 16:52:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HLqNJ32218 for ; Fri, 17 Jan 2003 16:52:23 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05148 for ; Fri, 17 Jan 2003 16:36:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HLpFJ32135; Fri, 17 Jan 2003 16:51:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HLa9J30988 for ; Fri, 17 Jan 2003 16:36:09 -0500 Received: from fep03-mail.bloor.is.net.cable.rogers.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04748 for ; Fri, 17 Jan 2003 16:19:52 -0500 (EST) Received: from ee.ryerson.ca ([24.112.78.44]) by fep03-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.05.06 201-253-122-126-106-20020509) with ESMTP id <20030117212212.RSJP148587.fep03-mail.bloor.is.net.cable.rogers.com@ee.ryerson.ca> for ; Fri, 17 Jan 2003 16:22:12 -0500 Message-ID: <3E287428.6000407@ee.ryerson.ca> Date: Fri, 17 Jan 2003 16:22:48 -0500 From: Muhammad Jaseemuddin Organization: Ryerson University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: seamoby@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH PLAIN at fep03-mail.bloor.is.net.cable.rogers.com from [24.112.78.44] using ID at Fri, 17 Jan 2003 16:22:12 -0500 Content-Transfer-Encoding: 7bit Subject: [Seamoby] CFP: IEEE VTC Symposium on IP Mobility 2003 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Call for Papers - IP Mobility 2003 IEEE VTC Symposium on IP Mobility October 4-9, 2003 Orlando, FL, USA in Conjunction with IEEE VTC Fall 2003 Submission Deadline: February 15, 2003 Scope ===== Mobility support in IP network has been an area of active research and development. The impacts of mobility and wireless medium at all layers of Internet architecture have generated wide range of interest in the research community. IETF has been working on standardizing protocols for inter-domain and intra-domain mobility, context transfer, routing for network mobility and ad-hoc networks. This symposium is aimed at providing researchers and practitioners a forum for presenting their research at all layers of Internet architecture and sharing experiences. It will provide a unique opportunity to people from academia and industry to exchange their ideas on short-term and long-term research issues. The theme of this symposium is **Support for Network Mobility**. The outcome of the symposium is expected to present a view on how close to reality is IP Mobility and set a direction for research to deal with emerging issues. The papers must discuss issues and solutions related to support for wireless medium and mobility in IP network. The symposium solicits papers related to but not limited to the following areas: * Routing for host (e.g. terminals) and network (e.g. trains, buses) mobility, protocols and performance * New approaches to wide-area and local mobility * Quality of Service models, resource management, and provisioning * Traffic Engineering in mobile wireless IP access networks * Transport protocol design for mobile wireless networks * Security including security threat models, threat analysis and their impact on routing * Application level protocol design and performance * Mobile and wireless applications, their service requirements and performance * Content delivery support in IP network for mobile users * Multicasting for mobile wireless services * Emerging network architectures (e.g. multi-hop ad-hoc network, sensor network) * Internetworking of different network types (e.g. ad-hoc to cellular, wireless LAN to cellular) * Inter-vehicular network architecture * Mobile wireless IP access network deployment and management Posters are also solicited on the projects related to the symposium theme. Submission Instructions ======================= Authors MUST submit an extended abstract (up to 2 pages) through the EDAS web site (http://www.edas.info/), together with a short abstract (approximately 150 words) in the EDAS web site form. Please note that the potential authors should create your own account in the EDAS web site (http://www.edas.info/) before submitting paper(s). Although either MS Word or PDF file format is acceptable when submitting the extended abstracts, it is strongly suggested that authors should submit papers using PDF format. The submission(s) should include complete contacting information of the author(s), such as the name, mailing address, telephone and fax numbers, and email address. All submitted papers are subject to peer review. Submissions can also be made using the links of call for technical papers in the conference web site: http://www.vtc2003.org/. Important Dates Extended Abstract Due: February 15, 2003 Acceptance Notification: April 15, 2003 Camera Ready Copy of Full Paper Due: July 15, 2003 Symposium Date: October 4, 2003 Organization ============ Program Co-Chairs: Muhammad Jaseemuddin (jaseem@ee.ryerson.ca) Department of Electrical and Computer Engineering Ryerson University Toronto, Canada Hongyi Li (hyli@nortelnetworks.com) Wireless Technology Lab Nortel Networks Ottawa, Canada Publicity Co-Chair: Junaid Zubairi (junaid.zubairi@fredonia.edu) Department of Mathematics and Computer Science SUNY at Fredonia Fredonia, NY, USA Technical Program Committee =========================== * Ahmed Helmy (USC) * Yasser Rasheed (Intel) * Raouf Boutaba (University of Waterloo) * Sajal Das (The University of Texas at Arlington) * Haseeb Akhtar (inCode Telecom group, CA) * Lars Wolf (TU Braunschweig, Germany) * Samir R. Das (SUNY at Stony Brook) * Thiery Ernst (Wide, Keio U Japan) * Abdelsalam Helal (U of Florida, Gainesville) * Govindan Ravindran (Soma Networks) _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Jan 19 16:57:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26108 for ; Sun, 19 Jan 2003 16:57:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0JMD7J24922; Sun, 19 Jan 2003 17:13:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G34CJ02329 for ; Wed, 15 Jan 2003 22:04:12 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18895 for ; Wed, 15 Jan 2003 21:48:46 -0500 (EST) Date: Wed, 15 Jan 2003 18:50:06 -0800 From: Daichi Funato To: Hemant.Chaskar@nokia.com Subject: Re: [Seamoby] CARD between Routers - will CT do? Cc: , , In-Reply-To: References: Message-Id: <20030115164317.65A8.FUNATO@docomolabs-usa.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Hemant, > Hemant --> I think we can start protocol design under the assumptions that > (i) old and new ARs can establish SA between them, (ii) they are willing to > participate in CARD protocol. Then, there may not be any need for intra-domain > / inter-domain classification. What kind of security mechanisms are you assuming? I think we should not leave the security mechanisms out of the scope. Especially, MN-report-based CARD is vulnerable to an attacker. How to protect the communication is an essential part of CARD, I think. Actually, IEEE IAPP includes a security mechanism by itself. Do we neglect that part in CARD? IMHO, if CARD can provide secure keys for ARs, it can be used by CT and FMIP as well. This is another type of capability discovery. What do you think? Best regards, Daichi ------------------------------------------------------------- Daichi Funato DoCoMo Communications Laboratories USA, Inc. Confidential Note: Privileged/Confidential Information may be contained in this e-mail and any attachment to it. Unless you are the addressee indicated in this e-mail, please notify immediately the sender by reply e-mail that you have received this in error and delete it from your system. You may not use, copy or deliver this e-mail or any information contained in this e-mail to anyone. Thank you very much. ------------------------------------------------------------- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Jan 19 16:57:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26125 for ; Sun, 19 Jan 2003 16:57:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0JMDWJ24960; Sun, 19 Jan 2003 17:13:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0H84pJ07831 for ; Fri, 17 Jan 2003 03:04:51 -0500 Received: from maredsous.cs.rice.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15033 for ; Fri, 17 Jan 2003 02:48:51 -0500 (EST) Received: (from root@localhost) by maredsous.cs.rice.edu id h0H7rBX26989; Fri, 17 Jan 2003 01:53:11 -0600 (CST) Date: Fri, 17 Jan 2003 01:53:11 -0600 (CST) Message-Id: <200301170753.h0H7rBX26989@maredsous.cs.rice.edu> From: Dave Johnson To: seamoby@ietf.org Subject: [Seamoby] CFP: MobiCom 2003 -- Papers due March 5, 2003 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , CALL FOR PAPERS MobiCom 2003 The Ninth Annual International Conference on Mobile Computing and Networking September 14-19, 2003 San Diego, California, USA http://www.sigmobile.org/mobicom/2003/ Sponsored by ACM SIGMOBILE ACM MobiCom 2003, the Ninth Annual International Conference on Mobile Computing and Networking, is the ninth in a series of annual conferences sponsored by ACM SIGMOBILE dedicated to addressing the challenges in the areas of mobile computing and wireless and mobile networking. The MobiCom conference series serves as the premier international forum addressing networks, systems, algorithms, and applications that support the symbiosis of mobile computers and wireless networks. MobiCom is a highly selective, single-track conference focusing on all issues in mobile computing and wireless and mobile networking at the link layer and above. MobiCom 2003 will be held September 14-19, 2003, at the Westin Horton Plaza Hotel in beautiful, sunny San Diego, California. PAPERS: Authors are invited to submit full papers presenting new research related to the theory or practice of mobile computing and networking. All submissions must describe original research, not published or currently under review for another conference or journal. Areas of interest include, but are not limited to: - Applications and computing services supporting mobile users - Architectures, protocols, and algorithms to cope with mobility, limited bandwidth, or intermittent connectivity - Database and data management issues in mobile computing - Operating system and middleware support for mobile computing and networking - Distributed systems aspects of mobile computing - New mobile and wireless applications - Integration and interworking of wired and wireless networks - Performance of mobile and wireless networks and systems - Location-dependent applications and protocols - Security and privacy of mobile/wireless systems - Mobile ad hoc and sensor networks - Wireless multimedia systems - Algorithms and protocols for power management and control - Service creation and management environments for mobile/wireless systems The program committee will referee all papers, and accepted papers will be published in the conference proceedings. Papers of particular merit will be proposed for publication in the ACM/Kluwer Wireless Networks (WINET) and Mobile Networks and Applications (MONET) journals. CHALLENGES PAPERS: The conference also solicits short papers (maximum of 8 pages) that challenge the mobile computing community with revolutionary new technologies or visionary applications. Such papers should provide stimulating ideas or grand visions that may open up exciting avenues of far-reaching future research; descriptions of new products or simple evolution of existing work are not appropriate as Challenges Papers. Challenges Papers will be reviewed and should be submitted using the normal submission procedure but must be clearly identified as intended as Challenges Papers. SUBMISSION INSTRUCTIONS: All paper submissions will be handled electronically. Authors should prepare a Portable Document Format (PDF) or PostScript version of their full paper. Papers must be no longer than 15 pages (8 pages for Challenges submissions), in font size no smaller than 10 points, and must fit properly on US "Letter"-sized paper (8.5x11 inches) with reasonable margins. Detailed instructions on the paper submission procedure and format will be available on the conference web pages. The paper submission deadline for all papers is March 5, 2003. All submitted papers will be judged based on their quality through double-blind reviewing, where the identities of the authors are withheld from the reviewers. Authors' names must not appear in the paper or in the PostScript or PDF file. Submitted papers (or substantially similar papers) must not be currently under review for any other publication. Please direct any questions about the paper submission process to the Program Co-Chairs at mobicom_pcchairs@acm.org. TUTORIALS: Proposals for tutorials are solicited. Evaluation of tutorial proposals will be based on the expertise and experience of the instructors, and on the relevance of the subject matter. Potential instructors are requested to submit a tutorial proposal of at most 5 pages, including a biographical sketch, to the Tutorial Co-Chairs by April 7, 2003. PANELS: Panels are solicited that examine innovative, controversial, or otherwise provocative issues of interest. Panel proposals should not exceed 3 pages, including biographical sketches of the panelists. Potential panel organizers should contact the Panel Co-Chairs by April 21, 2003. RESEARCH DEMOS AND EXHIBITS: Proposals for research demos are solicited. Proposals should not exceed 3 pages and should include a description of the demo and equipment to be used. Send proposals to the Research Demo Chair by July 26, 2003. We are also planning an Expo featuring exhibits of the latest mobile computing products and services. BEST STUDENT PAPER AWARD: Papers with a student as a primary author will be considered for the Best Student Paper award, with a cash award of $1000 USD. Students must indicate with their submission that they would like to be considered for this award. IMPORTANT DATES: Paper submissions due: March 5, 2003 Notification of acceptance: June 16, 2003 Camera-ready version due: July 18, 2003 GENERAL CHAIR: David B. Johnson Rice University dbj@cs.rice.edu PROGRAM CO-CHAIRS: Anthony D. Joseph University of California, Berkeley adj@eecs.berkeley.edu Nitin H. Vaidya University of Illinois at Urbana-Champaign nhv@uiuc.edu FOR MORE INFORMATION: Please contact the General Chair or Program Co-Chairs for more information. For information on ACM SIGMOBILE and the MobiCom series of conferences, see http://www.sigmobile.org/ or contact mobicom_info@acm.org. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Jan 19 16:57:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26142 for ; Sun, 19 Jan 2003 16:57:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0JMDcJ24979; Sun, 19 Jan 2003 17:13:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0JIucJ15505 for ; Sun, 19 Jan 2003 13:56:38 -0500 Received: from patan.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23710 for ; Sun, 19 Jan 2003 13:39:25 -0500 (EST) Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA28024; Sun, 19 Jan 2003 11:42:48 -0700 (MST) Received: from localhost (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h0JIgeP26913; Sun, 19 Jan 2003 19:42:41 +0100 (MET) Date: Sun, 19 Jan 2003 17:58:11 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [Seamoby] CARD - FMIPv6 protocol interworking To: Marco Liebsch Cc: Erik Nordmark , Hemant.Chaskar@nokia.com, ASINGH1@motorola.com, mankin@psg.com, kempf@docomolabs-usa.com, Seamoby@ietf.org In-Reply-To: "Your message with ID" <3E2805D8.20402@ccrle.nec.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , > We discussed this issue within the design team. To avoid modification of > other protocols > (FMIPv6, Neighbor Disc.) for discovery of whether or not the > communication peer > supports CARD protocol piggybacking, what about the following: > > The ICMP message for CARD protocol stand-alone deployment has a flag, > indicating piggybacking capability of the message sender, if present. > First CARD message sent (for example mobile to AR) is to be a > stand-alone CARD message, > indicating the sender's capability of piggybacking. The appropriate > reply message, in this > example from AR, indicates, whether or not the AR itself is able to > perform piggybacking. > In case of both entities support piggybacking, further CARD messages can > be piggybacked. > The CARD reply could already be piggybacked in case of the AR supports > piggybacking and > in case of an appropriate "carrier" protocol message is to be sent anyway. > > For the latter proposal it's important to separate protocol messages' > sequence numbers. > Hence, the piggybacked CARD reply message would carry the CARD message > sequence number > in the option to be piggybacked. This keeps CARD protocol sequence > numbers de-coupled > from the "carrier protocol's" sequence numbers. This should work. It adds some amount of complexity thus I hope it provides sufficient performance benefits to compensate. Erik _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Sun Jan 19 16:57:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26159 for ; Sun, 19 Jan 2003 16:57:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0JMEPn25008 for seamoby-archive@odin.ietf.org; Sun, 19 Jan 2003 17:14:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0JMEPJ25005 for ; Sun, 19 Jan 2003 17:14:25 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26122 for ; Sun, 19 Jan 2003 16:57:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0JMD7J24922; Sun, 19 Jan 2003 17:13:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G34CJ02329 for ; Wed, 15 Jan 2003 22:04:12 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18895 for ; Wed, 15 Jan 2003 21:48:46 -0500 (EST) Date: Wed, 15 Jan 2003 18:50:06 -0800 From: Daichi Funato To: Hemant.Chaskar@nokia.com Subject: Re: [Seamoby] CARD between Routers - will CT do? Cc: , , In-Reply-To: References: Message-Id: <20030115164317.65A8.FUNATO@docomolabs-usa.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Hemant, > Hemant --> I think we can start protocol design under the assumptions that > (i) old and new ARs can establish SA between them, (ii) they are willing to > participate in CARD protocol. Then, there may not be any need for intra-domain > / inter-domain classification. What kind of security mechanisms are you assuming? I think we should not leave the security mechanisms out of the scope. Especially, MN-report-based CARD is vulnerable to an attacker. How to protect the communication is an essential part of CARD, I think. Actually, IEEE IAPP includes a security mechanism by itself. Do we neglect that part in CARD? IMHO, if CARD can provide secure keys for ARs, it can be used by CT and FMIP as well. This is another type of capability discovery. What do you think? Best regards, Daichi ------------------------------------------------------------- Daichi Funato DoCoMo Communications Laboratories USA, Inc. Confidential Note: Privileged/Confidential Information may be contained in this e-mail and any attachment to it. Unless you are the addressee indicated in this e-mail, please notify immediately the sender by reply e-mail that you have received this in error and delete it from your system. You may not use, copy or deliver this e-mail or any information contained in this e-mail to anyone. Thank you very much. ------------------------------------------------------------- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Sun Jan 19 16:57:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26173 for ; Sun, 19 Jan 2003 16:57:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0JMEY125026 for seamoby-archive@odin.ietf.org; Sun, 19 Jan 2003 17:14:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0JMEXJ25023 for ; Sun, 19 Jan 2003 17:14:33 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26139 for ; Sun, 19 Jan 2003 16:57:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0JMDWJ24960; Sun, 19 Jan 2003 17:13:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0H84pJ07831 for ; Fri, 17 Jan 2003 03:04:51 -0500 Received: from maredsous.cs.rice.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15033 for ; Fri, 17 Jan 2003 02:48:51 -0500 (EST) Received: (from root@localhost) by maredsous.cs.rice.edu id h0H7rBX26989; Fri, 17 Jan 2003 01:53:11 -0600 (CST) Date: Fri, 17 Jan 2003 01:53:11 -0600 (CST) Message-Id: <200301170753.h0H7rBX26989@maredsous.cs.rice.edu> From: Dave Johnson To: seamoby@ietf.org Subject: [Seamoby] CFP: MobiCom 2003 -- Papers due March 5, 2003 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , CALL FOR PAPERS MobiCom 2003 The Ninth Annual International Conference on Mobile Computing and Networking September 14-19, 2003 San Diego, California, USA http://www.sigmobile.org/mobicom/2003/ Sponsored by ACM SIGMOBILE ACM MobiCom 2003, the Ninth Annual International Conference on Mobile Computing and Networking, is the ninth in a series of annual conferences sponsored by ACM SIGMOBILE dedicated to addressing the challenges in the areas of mobile computing and wireless and mobile networking. The MobiCom conference series serves as the premier international forum addressing networks, systems, algorithms, and applications that support the symbiosis of mobile computers and wireless networks. MobiCom is a highly selective, single-track conference focusing on all issues in mobile computing and wireless and mobile networking at the link layer and above. MobiCom 2003 will be held September 14-19, 2003, at the Westin Horton Plaza Hotel in beautiful, sunny San Diego, California. PAPERS: Authors are invited to submit full papers presenting new research related to the theory or practice of mobile computing and networking. All submissions must describe original research, not published or currently under review for another conference or journal. Areas of interest include, but are not limited to: - Applications and computing services supporting mobile users - Architectures, protocols, and algorithms to cope with mobility, limited bandwidth, or intermittent connectivity - Database and data management issues in mobile computing - Operating system and middleware support for mobile computing and networking - Distributed systems aspects of mobile computing - New mobile and wireless applications - Integration and interworking of wired and wireless networks - Performance of mobile and wireless networks and systems - Location-dependent applications and protocols - Security and privacy of mobile/wireless systems - Mobile ad hoc and sensor networks - Wireless multimedia systems - Algorithms and protocols for power management and control - Service creation and management environments for mobile/wireless systems The program committee will referee all papers, and accepted papers will be published in the conference proceedings. Papers of particular merit will be proposed for publication in the ACM/Kluwer Wireless Networks (WINET) and Mobile Networks and Applications (MONET) journals. CHALLENGES PAPERS: The conference also solicits short papers (maximum of 8 pages) that challenge the mobile computing community with revolutionary new technologies or visionary applications. Such papers should provide stimulating ideas or grand visions that may open up exciting avenues of far-reaching future research; descriptions of new products or simple evolution of existing work are not appropriate as Challenges Papers. Challenges Papers will be reviewed and should be submitted using the normal submission procedure but must be clearly identified as intended as Challenges Papers. SUBMISSION INSTRUCTIONS: All paper submissions will be handled electronically. Authors should prepare a Portable Document Format (PDF) or PostScript version of their full paper. Papers must be no longer than 15 pages (8 pages for Challenges submissions), in font size no smaller than 10 points, and must fit properly on US "Letter"-sized paper (8.5x11 inches) with reasonable margins. Detailed instructions on the paper submission procedure and format will be available on the conference web pages. The paper submission deadline for all papers is March 5, 2003. All submitted papers will be judged based on their quality through double-blind reviewing, where the identities of the authors are withheld from the reviewers. Authors' names must not appear in the paper or in the PostScript or PDF file. Submitted papers (or substantially similar papers) must not be currently under review for any other publication. Please direct any questions about the paper submission process to the Program Co-Chairs at mobicom_pcchairs@acm.org. TUTORIALS: Proposals for tutorials are solicited. Evaluation of tutorial proposals will be based on the expertise and experience of the instructors, and on the relevance of the subject matter. Potential instructors are requested to submit a tutorial proposal of at most 5 pages, including a biographical sketch, to the Tutorial Co-Chairs by April 7, 2003. PANELS: Panels are solicited that examine innovative, controversial, or otherwise provocative issues of interest. Panel proposals should not exceed 3 pages, including biographical sketches of the panelists. Potential panel organizers should contact the Panel Co-Chairs by April 21, 2003. RESEARCH DEMOS AND EXHIBITS: Proposals for research demos are solicited. Proposals should not exceed 3 pages and should include a description of the demo and equipment to be used. Send proposals to the Research Demo Chair by July 26, 2003. We are also planning an Expo featuring exhibits of the latest mobile computing products and services. BEST STUDENT PAPER AWARD: Papers with a student as a primary author will be considered for the Best Student Paper award, with a cash award of $1000 USD. Students must indicate with their submission that they would like to be considered for this award. IMPORTANT DATES: Paper submissions due: March 5, 2003 Notification of acceptance: June 16, 2003 Camera-ready version due: July 18, 2003 GENERAL CHAIR: David B. Johnson Rice University dbj@cs.rice.edu PROGRAM CO-CHAIRS: Anthony D. Joseph University of California, Berkeley adj@eecs.berkeley.edu Nitin H. Vaidya University of Illinois at Urbana-Champaign nhv@uiuc.edu FOR MORE INFORMATION: Please contact the General Chair or Program Co-Chairs for more information. For information on ACM SIGMOBILE and the MobiCom series of conferences, see http://www.sigmobile.org/ or contact mobicom_info@acm.org. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Sun Jan 19 16:58:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26187 for ; Sun, 19 Jan 2003 16:58:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0JMEmg25045 for seamoby-archive@odin.ietf.org; Sun, 19 Jan 2003 17:14:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0JMElJ25042 for ; Sun, 19 Jan 2003 17:14:47 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26156 for ; Sun, 19 Jan 2003 16:57:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0JMDcJ24979; Sun, 19 Jan 2003 17:13:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0JIucJ15505 for ; Sun, 19 Jan 2003 13:56:38 -0500 Received: from patan.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23710 for ; Sun, 19 Jan 2003 13:39:25 -0500 (EST) Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA28024; Sun, 19 Jan 2003 11:42:48 -0700 (MST) Received: from localhost (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h0JIgeP26913; Sun, 19 Jan 2003 19:42:41 +0100 (MET) Date: Sun, 19 Jan 2003 17:58:11 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [Seamoby] CARD - FMIPv6 protocol interworking To: Marco Liebsch Cc: Erik Nordmark , Hemant.Chaskar@nokia.com, ASINGH1@motorola.com, mankin@psg.com, kempf@docomolabs-usa.com, Seamoby@ietf.org In-Reply-To: "Your message with ID" <3E2805D8.20402@ccrle.nec.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , > We discussed this issue within the design team. To avoid modification of > other protocols > (FMIPv6, Neighbor Disc.) for discovery of whether or not the > communication peer > supports CARD protocol piggybacking, what about the following: > > The ICMP message for CARD protocol stand-alone deployment has a flag, > indicating piggybacking capability of the message sender, if present. > First CARD message sent (for example mobile to AR) is to be a > stand-alone CARD message, > indicating the sender's capability of piggybacking. The appropriate > reply message, in this > example from AR, indicates, whether or not the AR itself is able to > perform piggybacking. > In case of both entities support piggybacking, further CARD messages can > be piggybacked. > The CARD reply could already be piggybacked in case of the AR supports > piggybacking and > in case of an appropriate "carrier" protocol message is to be sent anyway. > > For the latter proposal it's important to separate protocol messages' > sequence numbers. > Hence, the piggybacked CARD reply message would carry the CARD message > sequence number > in the option to be piggybacked. This keeps CARD protocol sequence > numbers de-coupled > from the "carrier protocol's" sequence numbers. This should work. It adds some amount of complexity thus I hope it provides sufficient performance benefits to compensate. Erik _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Sun Jan 19 16:58:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26205 for ; Sun, 19 Jan 2003 16:58:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0JMDQJ24941; Sun, 19 Jan 2003 17:13:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GEdqJ26411 for ; Thu, 16 Jan 2003 09:39:52 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11816 for ; Thu, 16 Jan 2003 09:24:13 -0500 (EST) Received: from eunsoo ([138.15.107.234]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 16 Jan 2003 09:27:35 -0500 Message-ID: <006401c2bd84$e17502f0$ea6b0f8a@eunsoo> From: "Eunsoo Shim" To: "Hemant Chaskar" , Cc: , References: Subject: Re: [Seamoby] CARD between Routers - will CT do? Date: Thu, 16 Jan 2003 09:29:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 16 Jan 2003 14:27:35.0585 (UTC) FILETIME=[69E96910:01C2BD6B] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > I do not think that establishment of SA between ARs should be within scope > of CARD. We should start from pre-requisite that SA can be established > between ARs. When ARs belong to same domain, this is simple. When they > belong to different domain it is harder. In either case, there can be > variety of ways to establish SAs - pre-shared key, domain specific > certificates, AAA, credentials exchanged during SLAs or any other means. Why > should CARD put any restriction on mechanism used to establish SA? > > So, instead of > > <--Interworking--> > | > Intra-domain CARD | Inter-domain CARD > protocol | protocol > --------------------|------------------------------ > Intra-domain SA | Inter-domain SA > mechanism | mechanism > (CARD specific?) | (CARD specific?) > > I am saying that, if possible, we should try, > > > > CARD protocol > ---------------------------------------------- > | > Intra-domain SA | Inter-domain SA > mechanisms | mechanisms > current/future best | (current/future best > practices) | practices) > I also prefer one CARD protocol that works for inter-domain and intra-domain operations. We need to analyze security threats on CARD in details and find out security requirements and solutions. To discuss the security threats, first of all, we need to identify the discovery mechanisms we want to consider. There were two proposals before the design team was formed. To continue discussion on security issues, I am looking for proposals on base discovery mechanisms from the design team. If the design team has the same proposals from the existing two proposals, then we can start security analysis of the discovery mechanisms. Regards, Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Sun Jan 19 16:59:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26223 for ; Sun, 19 Jan 2003 16:59:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0JMFtq25081 for seamoby-archive@odin.ietf.org; Sun, 19 Jan 2003 17:15:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0JMFtJ25078 for ; Sun, 19 Jan 2003 17:15:55 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26219 for ; Sun, 19 Jan 2003 16:58:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0JMDQJ24941; Sun, 19 Jan 2003 17:13:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GEdqJ26411 for ; Thu, 16 Jan 2003 09:39:52 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11816 for ; Thu, 16 Jan 2003 09:24:13 -0500 (EST) Received: from eunsoo ([138.15.107.234]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 16 Jan 2003 09:27:35 -0500 Message-ID: <006401c2bd84$e17502f0$ea6b0f8a@eunsoo> From: "Eunsoo Shim" To: "Hemant Chaskar" , Cc: , References: Subject: Re: [Seamoby] CARD between Routers - will CT do? Date: Thu, 16 Jan 2003 09:29:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 16 Jan 2003 14:27:35.0585 (UTC) FILETIME=[69E96910:01C2BD6B] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I do not think that establishment of SA between ARs should be within scope > of CARD. We should start from pre-requisite that SA can be established > between ARs. When ARs belong to same domain, this is simple. When they > belong to different domain it is harder. In either case, there can be > variety of ways to establish SAs - pre-shared key, domain specific > certificates, AAA, credentials exchanged during SLAs or any other means. Why > should CARD put any restriction on mechanism used to establish SA? > > So, instead of > > <--Interworking--> > | > Intra-domain CARD | Inter-domain CARD > protocol | protocol > --------------------|------------------------------ > Intra-domain SA | Inter-domain SA > mechanism | mechanism > (CARD specific?) | (CARD specific?) > > I am saying that, if possible, we should try, > > > > CARD protocol > ---------------------------------------------- > | > Intra-domain SA | Inter-domain SA > mechanisms | mechanisms > current/future best | (current/future best > practices) | practices) > I also prefer one CARD protocol that works for inter-domain and intra-domain operations. We need to analyze security threats on CARD in details and find out security requirements and solutions. To discuss the security threats, first of all, we need to identify the discovery mechanisms we want to consider. There were two proposals before the design team was formed. To continue discussion on security issues, I am looking for proposals on base discovery mechanisms from the design team. If the design team has the same proposals from the existing two proposals, then we can start security analysis of the discovery mechanisms. Regards, Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Jan 20 08:49:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20193 for ; Mon, 20 Jan 2003 08:49:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KE65J20874; Mon, 20 Jan 2003 09:06:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KE4fJ20775 for ; Mon, 20 Jan 2003 09:04:41 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20103 for ; Mon, 20 Jan 2003 08:47:04 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0KDoZB10879 for ; Mon, 20 Jan 2003 07:50:36 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 20 Jan 2003 07:50:26 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 20 Jan 2003 05:49:54 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CARD between Routers - will CT do? Date: Mon, 20 Jan 2003 08:49:52 -0500 Message-ID: Thread-Topic: [Seamoby] CARD between Routers - will CT do? Thread-Index: AcLAB1WXJGzIWy1AQZiq8brZWnSxlwAgzT3Q To: , , Cc: , X-OriginalArrivalTime: 20 Jan 2003 13:49:54.0120 (UTC) FILETIME=[CFA03C80:01C2C08A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0KE4fJ20776 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hello Eunsoo, I also prefer one CARD protocol that works for inter-domain and intra-domain operations. We need to analyze security threats on CARD in details and find out security requirements and solutions. To discuss the security threats, first of all, we need to identify the discovery mechanisms we want to consider. There were two proposals before the design team was formed. To continue discussion on security issues, I am looking for proposals on base discovery mechanisms from the design team. If the design team has the same proposals from the existing two proposals, then we can start security analysis of the discovery mechanisms. Regards, Eunsoo [Govind] The requirements document elaborates some of the security issues. Do you think we would need something additional than that. How we achieve these security targets is a different issue. Thanks, Govind. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Jan 20 08:50:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20211 for ; Mon, 20 Jan 2003 08:50:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0KE7PD21374 for seamoby-archive@odin.ietf.org; Mon, 20 Jan 2003 09:07:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KE7OJ21371 for ; Mon, 20 Jan 2003 09:07:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20208 for ; Mon, 20 Jan 2003 08:49:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KE65J20874; Mon, 20 Jan 2003 09:06:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KE4fJ20775 for ; Mon, 20 Jan 2003 09:04:41 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20103 for ; Mon, 20 Jan 2003 08:47:04 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0KDoZB10879 for ; Mon, 20 Jan 2003 07:50:36 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 20 Jan 2003 07:50:26 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 20 Jan 2003 05:49:54 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] CARD between Routers - will CT do? Date: Mon, 20 Jan 2003 08:49:52 -0500 Message-ID: Thread-Topic: [Seamoby] CARD between Routers - will CT do? Thread-Index: AcLAB1WXJGzIWy1AQZiq8brZWnSxlwAgzT3Q To: , , Cc: , X-OriginalArrivalTime: 20 Jan 2003 13:49:54.0120 (UTC) FILETIME=[CFA03C80:01C2C08A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0KE4fJ20776 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hello Eunsoo, I also prefer one CARD protocol that works for inter-domain and intra-domain operations. We need to analyze security threats on CARD in details and find out security requirements and solutions. To discuss the security threats, first of all, we need to identify the discovery mechanisms we want to consider. There were two proposals before the design team was formed. To continue discussion on security issues, I am looking for proposals on base discovery mechanisms from the design team. If the design team has the same proposals from the existing two proposals, then we can start security analysis of the discovery mechanisms. Regards, Eunsoo [Govind] The requirements document elaborates some of the security issues. Do you think we would need something additional than that. How we achieve these security targets is a different issue. Thanks, Govind. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Jan 20 09:20:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20780 for ; Mon, 20 Jan 2003 09:20:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KEbDJ22916; Mon, 20 Jan 2003 09:37:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KEafJ22525 for ; Mon, 20 Jan 2003 09:36:41 -0500 Received: from bsn-mail-01.bstormnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20773 for ; Mon, 20 Jan 2003 09:19:06 -0500 (EST) Subject: RE: [Seamoby] CARD between Routers - will CT do? From: Pat Calhoun To: Govind.Krishnamurthi@nokia.com Cc: eunsoo@nec-labs.com, hchaskar@hotmail.com, funato@docomolabs-usa.com, James Kempf , seamoby@ietf.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1043072506.7690.27.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 20 Jan 2003 06:21:48 -0800 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit All, I believe that we have plenty of work on our plate, and are significantly behind our existing milestones. As a consequence, I really don't see the need to tackle the inter-domain problem at this time. let's leave this one dead, and continue making progress. PatC On Mon, 2003-01-20 at 05:49, Govind.Krishnamurthi@nokia.com wrote: > Hello Eunsoo, > > I also prefer one CARD protocol that works for inter-domain and intra-domain > operations. > We need to analyze security threats on CARD in details and find out security > requirements and solutions. > To discuss the security threats, first of all, we need to identify the > discovery mechanisms we want to consider. > There were two proposals before the design team was formed. > To continue discussion on security issues, I am looking for proposals on > base discovery mechanisms from the design team. > If the design team has the same proposals from the existing two proposals, > then we can start security analysis of the discovery mechanisms. > Regards, > > Eunsoo > > > [Govind] The requirements document elaborates some of the security issues. > Do you think we would need something additional than that. How we achieve > these security targets is a different issue. > > Thanks, > Govind. > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Jan 20 09:21:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20816 for ; Mon, 20 Jan 2003 09:21:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0KEcDH23228 for seamoby-archive@odin.ietf.org; Mon, 20 Jan 2003 09:38:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KEcDJ23225 for ; Mon, 20 Jan 2003 09:38:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20794 for ; Mon, 20 Jan 2003 09:20:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KEbDJ22916; Mon, 20 Jan 2003 09:37:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KEafJ22525 for ; Mon, 20 Jan 2003 09:36:41 -0500 Received: from bsn-mail-01.bstormnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20773 for ; Mon, 20 Jan 2003 09:19:06 -0500 (EST) Subject: RE: [Seamoby] CARD between Routers - will CT do? From: Pat Calhoun To: Govind.Krishnamurthi@nokia.com Cc: eunsoo@nec-labs.com, hchaskar@hotmail.com, funato@docomolabs-usa.com, James Kempf , seamoby@ietf.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1043072506.7690.27.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 20 Jan 2003 06:21:48 -0800 Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit All, I believe that we have plenty of work on our plate, and are significantly behind our existing milestones. As a consequence, I really don't see the need to tackle the inter-domain problem at this time. let's leave this one dead, and continue making progress. PatC On Mon, 2003-01-20 at 05:49, Govind.Krishnamurthi@nokia.com wrote: > Hello Eunsoo, > > I also prefer one CARD protocol that works for inter-domain and intra-domain > operations. > We need to analyze security threats on CARD in details and find out security > requirements and solutions. > To discuss the security threats, first of all, we need to identify the > discovery mechanisms we want to consider. > There were two proposals before the design team was formed. > To continue discussion on security issues, I am looking for proposals on > base discovery mechanisms from the design team. > If the design team has the same proposals from the existing two proposals, > then we can start security analysis of the discovery mechanisms. > Regards, > > Eunsoo > > > [Govind] The requirements document elaborates some of the security issues. > Do you think we would need something additional than that. How we achieve > these security targets is a different issue. > > Thanks, > Govind. > > _______________________________________________ > Seamoby mailing list > Seamoby@ietf.org > https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Jan 20 18:31:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04402 for ; Mon, 20 Jan 2003 18:31:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KNlbJ24770; Mon, 20 Jan 2003 18:47:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KNkUJ24740 for ; Mon, 20 Jan 2003 18:46:30 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04334 for ; Mon, 20 Jan 2003 18:28:43 -0500 (EST) Received: from eunsoo ([138.15.107.234]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 20 Jan 2003 18:32:08 -0500 Message-ID: <001901c2c0f5$9b04d1a0$ea6b0f8a@eunsoo> From: "Eunsoo Shim" To: , , Cc: , References: Subject: Re: [Seamoby] CARD between Routers - will CT do? Date: Mon, 20 Jan 2003 18:34:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 20 Jan 2003 23:32:08.0788 (UTC) FILETIME=[264F8940:01C2C0DC] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, Govind, The security requirements described in the requirements draft are a good starting guideline. What I am looking for now is security threat analysis of particular discovery mechanisms so that we can judge whether we can design a secure CARD protocol with reasonable complexity based on such mechanisms. Since the design team (according to Hemant's email) put out two pre-candidates for discussion in the mailing list, I think we should have a quick review of each about whether each can meet the requirements described in the requirements draft and, in particular, what security threats are involved with each pre-candidate and how those can be resolved. For a specific mechanism, I guess we will find more detailed requirements regarding security. Regards, Eunsoo ----- Original Message ----- From: To: ; ; Cc: ; Sent: Monday, January 20, 2003 5:49 AM Subject: RE: [Seamoby] CARD between Routers - will CT do? Hello Eunsoo, I also prefer one CARD protocol that works for inter-domain and intra-domain operations. We need to analyze security threats on CARD in details and find out security requirements and solutions. To discuss the security threats, first of all, we need to identify the discovery mechanisms we want to consider. There were two proposals before the design team was formed. To continue discussion on security issues, I am looking for proposals on base discovery mechanisms from the design team. If the design team has the same proposals from the existing two proposals, then we can start security analysis of the discovery mechanisms. Regards, Eunsoo [Govind] The requirements document elaborates some of the security issues. Do you think we would need something additional than that. How we achieve these security targets is a different issue. Thanks, Govind. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Jan 20 18:32:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04420 for ; Mon, 20 Jan 2003 18:32:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0KNnVr24855 for seamoby-archive@odin.ietf.org; Mon, 20 Jan 2003 18:49:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KNnVJ24852 for ; Mon, 20 Jan 2003 18:49:31 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04416 for ; Mon, 20 Jan 2003 18:31:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KNlbJ24770; Mon, 20 Jan 2003 18:47:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KNkUJ24740 for ; Mon, 20 Jan 2003 18:46:30 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04334 for ; Mon, 20 Jan 2003 18:28:43 -0500 (EST) Received: from eunsoo ([138.15.107.234]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 20 Jan 2003 18:32:08 -0500 Message-ID: <001901c2c0f5$9b04d1a0$ea6b0f8a@eunsoo> From: "Eunsoo Shim" To: , , Cc: , References: Subject: Re: [Seamoby] CARD between Routers - will CT do? Date: Mon, 20 Jan 2003 18:34:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 20 Jan 2003 23:32:08.0788 (UTC) FILETIME=[264F8940:01C2C0DC] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Govind, The security requirements described in the requirements draft are a good starting guideline. What I am looking for now is security threat analysis of particular discovery mechanisms so that we can judge whether we can design a secure CARD protocol with reasonable complexity based on such mechanisms. Since the design team (according to Hemant's email) put out two pre-candidates for discussion in the mailing list, I think we should have a quick review of each about whether each can meet the requirements described in the requirements draft and, in particular, what security threats are involved with each pre-candidate and how those can be resolved. For a specific mechanism, I guess we will find more detailed requirements regarding security. Regards, Eunsoo ----- Original Message ----- From: To: ; ; Cc: ; Sent: Monday, January 20, 2003 5:49 AM Subject: RE: [Seamoby] CARD between Routers - will CT do? Hello Eunsoo, I also prefer one CARD protocol that works for inter-domain and intra-domain operations. We need to analyze security threats on CARD in details and find out security requirements and solutions. To discuss the security threats, first of all, we need to identify the discovery mechanisms we want to consider. There were two proposals before the design team was formed. To continue discussion on security issues, I am looking for proposals on base discovery mechanisms from the design team. If the design team has the same proposals from the existing two proposals, then we can start security analysis of the discovery mechanisms. Regards, Eunsoo [Govind] The requirements document elaborates some of the security issues. Do you think we would need something additional than that. How we achieve these security targets is a different issue. Thanks, Govind. _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Mon Jan 20 18:59:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04836 for ; Mon, 20 Jan 2003 18:59:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0L0GEJ26421; Mon, 20 Jan 2003 19:16:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0L0FkJ26399 for ; Mon, 20 Jan 2003 19:15:46 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04822 for ; Mon, 20 Jan 2003 18:57:58 -0500 (EST) Received: from eunsoo ([138.15.107.234]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 20 Jan 2003 19:01:24 -0500 Message-ID: <007201c2c0f9$b150afc0$ea6b0f8a@eunsoo> From: "Eunsoo Shim" To: , , References: Date: Mon, 20 Jan 2003 19:03:37 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 21 Jan 2003 00:01:24.0284 (UTC) FILETIME=[3CAAF7C0:01C2C0E0] Content-Transfer-Encoding: 7bit Subject: [Seamoby] Re: choices for rev. adr. translation mechanisms [was: CARD between Routers - will CT do?] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, I see a few problems with the rev.adr.translation server based approach. 1) The reverse address translation server can tell only that the there is a registered access router with the given L2 address (probably L2 address of the BS associated to an access router) but it cannot tell whether the access router is a CAR of the current AR. Now the current AR relies on the fact that a MN provided the L2 address matching to a registered AR. It comes with the following security threat. Security threat: A malicious MN (tampered MN) provides a L2 address which is the L2 address of a registered AR but not a CAR of the current AR, that is, no overlapping coverage with the current AR. Then the current AR will build a CAR table with IP addresses of ARs that are not CARs. As long as we assume a MN can be tampered, this attack is very easy to play since it is easy to collect the L2 addresses of registered access routers. 2) Another issue with the approach is that it requires static configuration. It is better than static configuration of CAR table at each AR but still it is much less flexible than something more dynamic. The motivation of CARD is dynamic discovery to avoid inflexible static configuration. I'd prefer less static configuration. 3) It requires a dedicated network element for CARD, that is, the reverse address translation server. The requirements draft says it is not allowed. 4) Scalability: Since L2 address does not come with any domain identity typically, I am not sure whether the reverse address translation can work inter-domain. Whenever the local domain server cannot find a matching entry, it will have to forward the query to all of the federated domains' servers. It does not look scalable. Could anybody correct me if I am wrong about the issues in the above? Regards, Eunsoo ----- Original Message ----- From: To: ; ; Sent: Friday, January 17, 2003 6:44 AM Subject: choices for rev. adr. translation mechanisms [was: CARD between Routers - will CT do?] Hi, Based on the discussion we had so far, DT has following choices. WG feedback on how to proceed - a) accept one approach, b) combine the two, c) reject both, d) delay the decision; would be valuable. This will prevent drastic modifications to subsequent versions of draft. I will try to summarize the premises we have: Approach 1: Based on MN-reports about neighborhood: ---------- - Similar to draft-trossen-seamoby-dycard-00.txt (First handoff between a pair of ARs is hard handoff. This MN tells new AR where it came from, i.e., IP address of old AR. Let us call it bootstrap handoff - HO_bt) - No rev. adr. trans. servers required - HO_bt cannot use fast/seamless handoff protocols, subsequent handoffs can - If ARs verify trust relationship between them (via preferred security mechanism such as AAA, certificates, SLAs or other), could be secured from malicious MNs (new AR asks old AR if this MN was indeed connected to it within reasonable past) - Distinction between intra and inter domain is in the method of establishing trust relationship between ARs, CARD protocol is the same for both cases (Establishing trust relationship is easy for intra case, harder for inter case. One example of how trust relation could be established in inter case: When HA_bt tells new AR about old AR's IP address, new AR asks old AR to provide credentials, say, in the form of certificate and vice versa. If ARs are satisfied with each others' credentials, then only they go for further capability and rev. adr. translation information exchange. Other credential mechanisms are possible too. Such security mechanisms can be further studied if WG were to choose this approach) Approach 2: Rev. adr. trans. server based approach: ----------- (Intra-domain scope, similar to draft-funato-seamoby-gaard-01.txt) - Network domain maintains rev. adr. trans. server that stores rev. adr. translation information of ARs in the domain - Old AR queries rev. adr. trans. server in its domain to resolve a first L2 ID to IP address (bootstrap query - Query_bt) - Rev. adr. trans. server replies with IP address of new AR (in the same domain) - Later, old and new ARs can engage in peer-to-peer capability and rev. adr. translation information exchange bypassing the rev. adr. tran. server - Easily secured (Extending Approach 2 to interdomain scope): - Form federation of rev. adr. trans. servers in different domains. For this we can go for one of following approaches: (i) rev. adr. translation servers in different domains exchange information. This is similar to IPTEL WG's Telephony Routing over IP (TRIP) Protocol (which does information exchange between ITADs (IP Telephony Admin Domains) about IP-PSTN gateways they can reach), which in turn is similar to BGP. or, (ii) build DNS like tree of rev. adr. trans. servers, or (iii) require that AP ID has enough information that Query_bt can be routed over Internet to correct rev. adr. translation server, or (iv) flood the federation of servers with Query_bt - When going inter domain, there is no guarantee that response to Query_bt comes before handoff is imminent. So this handoff may not be able to use fast/seamless handoff protocols, subsequent handoffs can - Security mechanism needs to be provided by server federation Note, in any case, ISPs cannot hide rev. adr. translation information from each other. If this is intolerable, we should proceed with understanding that seamless handoff protocols SHOULD be used intra domain. This is because, these protocols will need old AR to know IP address of new AR. Comments? Hemant _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Mon Jan 20 19:00:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04921 for ; Mon, 20 Jan 2003 19:00:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0L0Hgr26464 for seamoby-archive@odin.ietf.org; Mon, 20 Jan 2003 19:17:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0L0HgJ26461 for ; Mon, 20 Jan 2003 19:17:42 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04853 for ; Mon, 20 Jan 2003 18:59:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0L0GEJ26421; Mon, 20 Jan 2003 19:16:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0L0FkJ26399 for ; Mon, 20 Jan 2003 19:15:46 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04822 for ; Mon, 20 Jan 2003 18:57:58 -0500 (EST) Received: from eunsoo ([138.15.107.234]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 20 Jan 2003 19:01:24 -0500 Message-ID: <007201c2c0f9$b150afc0$ea6b0f8a@eunsoo> From: "Eunsoo Shim" To: , , References: Date: Mon, 20 Jan 2003 19:03:37 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 21 Jan 2003 00:01:24.0284 (UTC) FILETIME=[3CAAF7C0:01C2C0E0] Content-Transfer-Encoding: 7bit Subject: [Seamoby] Re: choices for rev. adr. translation mechanisms [was: CARD between Routers - will CT do?] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, I see a few problems with the rev.adr.translation server based approach. 1) The reverse address translation server can tell only that the there is a registered access router with the given L2 address (probably L2 address of the BS associated to an access router) but it cannot tell whether the access router is a CAR of the current AR. Now the current AR relies on the fact that a MN provided the L2 address matching to a registered AR. It comes with the following security threat. Security threat: A malicious MN (tampered MN) provides a L2 address which is the L2 address of a registered AR but not a CAR of the current AR, that is, no overlapping coverage with the current AR. Then the current AR will build a CAR table with IP addresses of ARs that are not CARs. As long as we assume a MN can be tampered, this attack is very easy to play since it is easy to collect the L2 addresses of registered access routers. 2) Another issue with the approach is that it requires static configuration. It is better than static configuration of CAR table at each AR but still it is much less flexible than something more dynamic. The motivation of CARD is dynamic discovery to avoid inflexible static configuration. I'd prefer less static configuration. 3) It requires a dedicated network element for CARD, that is, the reverse address translation server. The requirements draft says it is not allowed. 4) Scalability: Since L2 address does not come with any domain identity typically, I am not sure whether the reverse address translation can work inter-domain. Whenever the local domain server cannot find a matching entry, it will have to forward the query to all of the federated domains' servers. It does not look scalable. Could anybody correct me if I am wrong about the issues in the above? Regards, Eunsoo ----- Original Message ----- From: To: ; ; Sent: Friday, January 17, 2003 6:44 AM Subject: choices for rev. adr. translation mechanisms [was: CARD between Routers - will CT do?] Hi, Based on the discussion we had so far, DT has following choices. WG feedback on how to proceed - a) accept one approach, b) combine the two, c) reject both, d) delay the decision; would be valuable. This will prevent drastic modifications to subsequent versions of draft. I will try to summarize the premises we have: Approach 1: Based on MN-reports about neighborhood: ---------- - Similar to draft-trossen-seamoby-dycard-00.txt (First handoff between a pair of ARs is hard handoff. This MN tells new AR where it came from, i.e., IP address of old AR. Let us call it bootstrap handoff - HO_bt) - No rev. adr. trans. servers required - HO_bt cannot use fast/seamless handoff protocols, subsequent handoffs can - If ARs verify trust relationship between them (via preferred security mechanism such as AAA, certificates, SLAs or other), could be secured from malicious MNs (new AR asks old AR if this MN was indeed connected to it within reasonable past) - Distinction between intra and inter domain is in the method of establishing trust relationship between ARs, CARD protocol is the same for both cases (Establishing trust relationship is easy for intra case, harder for inter case. One example of how trust relation could be established in inter case: When HA_bt tells new AR about old AR's IP address, new AR asks old AR to provide credentials, say, in the form of certificate and vice versa. If ARs are satisfied with each others' credentials, then only they go for further capability and rev. adr. translation information exchange. Other credential mechanisms are possible too. Such security mechanisms can be further studied if WG were to choose this approach) Approach 2: Rev. adr. trans. server based approach: ----------- (Intra-domain scope, similar to draft-funato-seamoby-gaard-01.txt) - Network domain maintains rev. adr. trans. server that stores rev. adr. translation information of ARs in the domain - Old AR queries rev. adr. trans. server in its domain to resolve a first L2 ID to IP address (bootstrap query - Query_bt) - Rev. adr. trans. server replies with IP address of new AR (in the same domain) - Later, old and new ARs can engage in peer-to-peer capability and rev. adr. translation information exchange bypassing the rev. adr. tran. server - Easily secured (Extending Approach 2 to interdomain scope): - Form federation of rev. adr. trans. servers in different domains. For this we can go for one of following approaches: (i) rev. adr. translation servers in different domains exchange information. This is similar to IPTEL WG's Telephony Routing over IP (TRIP) Protocol (which does information exchange between ITADs (IP Telephony Admin Domains) about IP-PSTN gateways they can reach), which in turn is similar to BGP. or, (ii) build DNS like tree of rev. adr. trans. servers, or (iii) require that AP ID has enough information that Query_bt can be routed over Internet to correct rev. adr. translation server, or (iv) flood the federation of servers with Query_bt - When going inter domain, there is no guarantee that response to Query_bt comes before handoff is imminent. So this handoff may not be able to use fast/seamless handoff protocols, subsequent handoffs can - Security mechanism needs to be provided by server federation Note, in any case, ISPs cannot hide rev. adr. translation information from each other. If this is intolerable, we should proceed with understanding that seamless handoff protocols SHOULD be used intra domain. This is because, these protocols will need old AR to know IP address of new AR. Comments? Hemant _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Jan 21 13:11:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07319 for ; Tue, 21 Jan 2003 13:11:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LIRMJ05337; Tue, 21 Jan 2003 13:27:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LIOQJ05137 for ; Tue, 21 Jan 2003 13:24:26 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07186 for ; Tue, 21 Jan 2003 13:06:15 -0500 (EST) Message-ID: <019601c2c178$0ad65490$5c6015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , , References: <007201c2c0f9$b150afc0$ea6b0f8a@eunsoo> Date: Tue, 21 Jan 2003 10:08:04 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Re: choices for rev. adr. translation mechanisms [was: CARD between Routers - will CT do?] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > I see a few problems with the rev.adr.translation server based approach. > > 1) The reverse address translation server can tell only that the there is a > registered access router with the given L2 address (probably L2 address of > the BS associated to an access router) but it cannot tell whether the access > router is a CAR of the current AR. Now the current AR relies on the fact > that a MN provided the L2 address matching to a registered AR. It comes with > the following security threat. > > Security threat: > A malicious MN (tampered MN) provides a L2 address which is the L2 address > of a registered AR but not a CAR of the current AR, that is, no overlapping > coverage with the current AR. Then the current AR will build a CAR table > with IP addresses of ARs that are not CARs. As long as we assume a MN can be > tampered, this attack is very easy to play since it is easy to collect the > L2 addresses of registered access routers. > Doesn't matter. At the time of handover, the MN or AR will receive from layer 2 the address of the AP to which the MN is moving. Or, the MN will ask for CARs and match the AP layer 2 addresses in the CAR table with the addresses of the APs it can hear. Thus, an AP address that is provided by a malicious MN but has no wireless connectivity to the current AR will get filtered out when the MN or AR uses the information for handover, so it can do no harm. There is still the issue of the bogus AP sticking around. The AR can handle this by making the CARD information soft state, so it times out AR layer 2 addresses if it doesn't receive a confirmation from another MN within a certain period of time. Thus, any bogus information only has limited lifetime, and even within that lifetime, can't do more than occupy a table slot in the router's memory. In fact, the AR can use the number of MNs reporting a particular address to weight the relevence of a reported AP. So if 20 MNs report it, the AP address is more likely to stick around than if only 1 reports it. A related, but more serious, problem is if the MN undertakes a DoS attack by flooding the AR with real or bogus layer 2 addresses. The CARD protocol between the MN and AR must prevent this. > 2) Another issue with the approach is that it requires static configuration. > It is better than static configuration of CAR table at each AR but still it > is much less flexible than something more dynamic. The motivation of CARD is > dynamic discovery to avoid inflexible static configuration. I'd prefer less > static configuration. > There could be a protocol between the server and the APs that allows them to dynamically report this information. The problem with having this information directly exchanged between routers is that each router would have to keep a table of all AP/AR matches, which could be lots of information and thus a scalability problem for the ARs. > 3) It requires a dedicated network element for CARD, that is, the reverse > address translation server. The requirements draft says it is not allowed. > Right, well maybe the requirements are in error here. Why was this requirement put in? The IESG has not approved the requirements yet, BTW. > 4) Scalability: > Since L2 address does not come with any domain identity typically, I am not > sure whether the reverse address translation can work inter-domain. Whenever > the local domain server cannot find a matching entry, it will have to > forward the query to all of the federated domains' servers. It does not look > scalable. > As Pat mentioned, the interdomain problem is out of scope. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Jan 21 13:11:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07352 for ; Tue, 21 Jan 2003 13:11:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0LITYp05481 for seamoby-archive@odin.ietf.org; Tue, 21 Jan 2003 13:29:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LITYJ05478 for ; Tue, 21 Jan 2003 13:29:34 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07333 for ; Tue, 21 Jan 2003 13:11:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LIRMJ05337; Tue, 21 Jan 2003 13:27:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LIOQJ05137 for ; Tue, 21 Jan 2003 13:24:26 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07186 for ; Tue, 21 Jan 2003 13:06:15 -0500 (EST) Message-ID: <019601c2c178$0ad65490$5c6015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , , References: <007201c2c0f9$b150afc0$ea6b0f8a@eunsoo> Date: Tue, 21 Jan 2003 10:08:04 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Seamoby] Re: choices for rev. adr. translation mechanisms [was: CARD between Routers - will CT do?] Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I see a few problems with the rev.adr.translation server based approach. > > 1) The reverse address translation server can tell only that the there is a > registered access router with the given L2 address (probably L2 address of > the BS associated to an access router) but it cannot tell whether the access > router is a CAR of the current AR. Now the current AR relies on the fact > that a MN provided the L2 address matching to a registered AR. It comes with > the following security threat. > > Security threat: > A malicious MN (tampered MN) provides a L2 address which is the L2 address > of a registered AR but not a CAR of the current AR, that is, no overlapping > coverage with the current AR. Then the current AR will build a CAR table > with IP addresses of ARs that are not CARs. As long as we assume a MN can be > tampered, this attack is very easy to play since it is easy to collect the > L2 addresses of registered access routers. > Doesn't matter. At the time of handover, the MN or AR will receive from layer 2 the address of the AP to which the MN is moving. Or, the MN will ask for CARs and match the AP layer 2 addresses in the CAR table with the addresses of the APs it can hear. Thus, an AP address that is provided by a malicious MN but has no wireless connectivity to the current AR will get filtered out when the MN or AR uses the information for handover, so it can do no harm. There is still the issue of the bogus AP sticking around. The AR can handle this by making the CARD information soft state, so it times out AR layer 2 addresses if it doesn't receive a confirmation from another MN within a certain period of time. Thus, any bogus information only has limited lifetime, and even within that lifetime, can't do more than occupy a table slot in the router's memory. In fact, the AR can use the number of MNs reporting a particular address to weight the relevence of a reported AP. So if 20 MNs report it, the AP address is more likely to stick around than if only 1 reports it. A related, but more serious, problem is if the MN undertakes a DoS attack by flooding the AR with real or bogus layer 2 addresses. The CARD protocol between the MN and AR must prevent this. > 2) Another issue with the approach is that it requires static configuration. > It is better than static configuration of CAR table at each AR but still it > is much less flexible than something more dynamic. The motivation of CARD is > dynamic discovery to avoid inflexible static configuration. I'd prefer less > static configuration. > There could be a protocol between the server and the APs that allows them to dynamically report this information. The problem with having this information directly exchanged between routers is that each router would have to keep a table of all AP/AR matches, which could be lots of information and thus a scalability problem for the ARs. > 3) It requires a dedicated network element for CARD, that is, the reverse > address translation server. The requirements draft says it is not allowed. > Right, well maybe the requirements are in error here. Why was this requirement put in? The IESG has not approved the requirements yet, BTW. > 4) Scalability: > Since L2 address does not come with any domain identity typically, I am not > sure whether the reverse address translation can work inter-domain. Whenever > the local domain server cannot find a matching entry, it will have to > forward the query to all of the federated domains' servers. It does not look > scalable. > As Pat mentioned, the interdomain problem is out of scope. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Jan 21 16:07:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12032 for ; Tue, 21 Jan 2003 16:07:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LLNXJ17115; Tue, 21 Jan 2003 16:23:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LLMjJ17086 for ; Tue, 21 Jan 2003 16:22:45 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11954 for ; Tue, 21 Jan 2003 16:04:19 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0LL73B08360 for ; Tue, 21 Jan 2003 15:07:18 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 21 Jan 2003 15:06:53 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 21 Jan 2003 13:06:48 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Re: choices for rev. adr. translation mechanisms [was: CARD between Routers - will CT do?] Date: Tue, 21 Jan 2003 16:06:46 -0500 Message-ID: Thread-Topic: [Seamoby] Re: choices for rev. adr. translation mechanisms [was: CARD between Routers - will CT do?] Thread-Index: AcLBeY/SSP80w9vvRCaAX33X33UoFQADBBcg To: , , , X-OriginalArrivalTime: 21 Jan 2003 21:06:48.0534 (UTC) FILETIME=[030C1F60:01C2C191] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0LLMjJ17087 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hello Jim, comments inline. -Govind. > I see a few problems with the rev.adr.translation server based approach. > > 1) The reverse address translation server can tell only that the there is a > registered access router with the given L2 address (probably L2 address of > the BS associated to an access router) but it cannot tell whether the access > router is a CAR of the current AR. Now the current AR relies on the fact > that a MN provided the L2 address matching to a registered AR. It comes with > the following security threat. > > Security threat: > A malicious MN (tampered MN) provides a L2 address which is the L2 address > of a registered AR but not a CAR of the current AR, that is, no overlapping > coverage with the current AR. Then the current AR will build a CAR table > with IP addresses of ARs that are not CARs. As long as we assume a MN can be > tampered, this attack is very easy to play since it is easy to collect the > L2 addresses of registered access routers. > Doesn't matter. At the time of handover, the MN or AR will receive from layer 2 the address of the AP to which the MN is moving. Or, the MN will ask for CARs and match the AP layer 2 addresses in the CAR table with the addresses of the APs it can hear. Thus, an AP address that is provided by a malicious MN but has no wireless connectivity to the current AR will get filtered out when the MN or AR uses the information for handover, so it can do no harm. There is still the issue of the bogus AP sticking around. The AR can handle this by making the CARD information soft state, so it times out AR layer 2 addresses if it doesn't receive a confirmation from another MN within a certain period of time. Thus, any bogus information only has limited lifetime, and even within that lifetime, can't do more than occupy a table slot in the router's memory. In fact, the AR can use the number of MNs reporting a particular address to weight the relevence of a reported AP. So if 20 MNs report it, the AP address is more likely to stick around than if only 1 reports it. [Govind] This seems to be very similar to the approach taken by dycard. A related, but more serious, problem is if the MN undertakes a DoS attack by flooding the AR with real or bogus layer 2 addresses. The CARD protocol between the MN and AR must prevent this. > 2) Another issue with the approach is that it requires static configuration. > It is better than static configuration of CAR table at each AR but still it > is much less flexible than something more dynamic. The motivation of CARD is > dynamic discovery to avoid inflexible static configuration. I'd prefer less > static configuration. > There could be a protocol between the server and the APs that allows them to dynamically report this information. The problem with having this information directly exchanged between routers is that each router would have to keep a table of all AP/AR matches, which could be lots of information and thus a scalability problem for the ARs. [Govind] An AR only needs to keep information about its handover neighbors.. not every AP/AR in the domain (considering only the intra domain case). So why is there a scalability issue here? OTOH, there may be scalability/availability issues for the server for the very reason that you mention. Also, if the server approach also stores the information that it gets in a local cache, the amount of information that is stored is the same. > 3) It requires a dedicated network element for CARD, that is, the reverse > address translation server. The requirements draft says it is not allowed. > Right, well maybe the requirements are in error here. Why was this requirement put in? The IESG has not approved the requirements yet, BTW. [Govind] I agree that the IESG is still considering the draft, but the requirement draft has passed WG last call, therefore I don't see the reason (for sake of progress) why we should debate this issue now, unless ofcourse if the IESG has issues with this. > 4) Scalability: > Since L2 address does not come with any domain identity typically, I am not > sure whether the reverse address translation can work inter-domain. Whenever > the local domain server cannot find a matching entry, it will have to > forward the query to all of the federated domains' servers. It does not look > scalable. > As Pat mentioned, the interdomain problem is out of scope. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Jan 21 16:07:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12053 for ; Tue, 21 Jan 2003 16:07:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0LLPdY17213 for seamoby-archive@odin.ietf.org; Tue, 21 Jan 2003 16:25:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LLPdJ17210 for ; Tue, 21 Jan 2003 16:25:39 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12047 for ; Tue, 21 Jan 2003 16:07:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LLNXJ17115; Tue, 21 Jan 2003 16:23:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LLMjJ17086 for ; Tue, 21 Jan 2003 16:22:45 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11954 for ; Tue, 21 Jan 2003 16:04:19 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0LL73B08360 for ; Tue, 21 Jan 2003 15:07:18 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 21 Jan 2003 15:06:53 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 21 Jan 2003 13:06:48 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Re: choices for rev. adr. translation mechanisms [was: CARD between Routers - will CT do?] Date: Tue, 21 Jan 2003 16:06:46 -0500 Message-ID: Thread-Topic: [Seamoby] Re: choices for rev. adr. translation mechanisms [was: CARD between Routers - will CT do?] Thread-Index: AcLBeY/SSP80w9vvRCaAX33X33UoFQADBBcg To: , , , X-OriginalArrivalTime: 21 Jan 2003 21:06:48.0534 (UTC) FILETIME=[030C1F60:01C2C191] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0LLMjJ17087 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hello Jim, comments inline. -Govind. > I see a few problems with the rev.adr.translation server based approach. > > 1) The reverse address translation server can tell only that the there is a > registered access router with the given L2 address (probably L2 address of > the BS associated to an access router) but it cannot tell whether the access > router is a CAR of the current AR. Now the current AR relies on the fact > that a MN provided the L2 address matching to a registered AR. It comes with > the following security threat. > > Security threat: > A malicious MN (tampered MN) provides a L2 address which is the L2 address > of a registered AR but not a CAR of the current AR, that is, no overlapping > coverage with the current AR. Then the current AR will build a CAR table > with IP addresses of ARs that are not CARs. As long as we assume a MN can be > tampered, this attack is very easy to play since it is easy to collect the > L2 addresses of registered access routers. > Doesn't matter. At the time of handover, the MN or AR will receive from layer 2 the address of the AP to which the MN is moving. Or, the MN will ask for CARs and match the AP layer 2 addresses in the CAR table with the addresses of the APs it can hear. Thus, an AP address that is provided by a malicious MN but has no wireless connectivity to the current AR will get filtered out when the MN or AR uses the information for handover, so it can do no harm. There is still the issue of the bogus AP sticking around. The AR can handle this by making the CARD information soft state, so it times out AR layer 2 addresses if it doesn't receive a confirmation from another MN within a certain period of time. Thus, any bogus information only has limited lifetime, and even within that lifetime, can't do more than occupy a table slot in the router's memory. In fact, the AR can use the number of MNs reporting a particular address to weight the relevence of a reported AP. So if 20 MNs report it, the AP address is more likely to stick around than if only 1 reports it. [Govind] This seems to be very similar to the approach taken by dycard. A related, but more serious, problem is if the MN undertakes a DoS attack by flooding the AR with real or bogus layer 2 addresses. The CARD protocol between the MN and AR must prevent this. > 2) Another issue with the approach is that it requires static configuration. > It is better than static configuration of CAR table at each AR but still it > is much less flexible than something more dynamic. The motivation of CARD is > dynamic discovery to avoid inflexible static configuration. I'd prefer less > static configuration. > There could be a protocol between the server and the APs that allows them to dynamically report this information. The problem with having this information directly exchanged between routers is that each router would have to keep a table of all AP/AR matches, which could be lots of information and thus a scalability problem for the ARs. [Govind] An AR only needs to keep information about its handover neighbors.. not every AP/AR in the domain (considering only the intra domain case). So why is there a scalability issue here? OTOH, there may be scalability/availability issues for the server for the very reason that you mention. Also, if the server approach also stores the information that it gets in a local cache, the amount of information that is stored is the same. > 3) It requires a dedicated network element for CARD, that is, the reverse > address translation server. The requirements draft says it is not allowed. > Right, well maybe the requirements are in error here. Why was this requirement put in? The IESG has not approved the requirements yet, BTW. [Govind] I agree that the IESG is still considering the draft, but the requirement draft has passed WG last call, therefore I don't see the reason (for sake of progress) why we should debate this issue now, unless ofcourse if the IESG has issues with this. > 4) Scalability: > Since L2 address does not come with any domain identity typically, I am not > sure whether the reverse address translation can work inter-domain. Whenever > the local domain server cannot find a matching entry, it will have to > forward the query to all of the federated domains' servers. It does not look > scalable. > As Pat mentioned, the interdomain problem is out of scope. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Jan 21 18:22:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14986 for ; Tue, 21 Jan 2003 18:22:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LNdFJ25937; Tue, 21 Jan 2003 18:39:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LNbgJ25890 for ; Tue, 21 Jan 2003 18:37:42 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14923 for ; Tue, 21 Jan 2003 18:19:26 -0500 (EST) Message-ID: <02fd01c2c1a3$ca6c7250$5c6015ac@T23KEMPF> From: "James Kempf" To: , , , References: Subject: Re: [Seamoby] Re: choices for rev. adr. translation mechanisms [was: CARD between Routers - will CT do?] Date: Tue, 21 Jan 2003 15:21:12 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > [Govind] An AR only needs to keep information about its handover neighbors.. > not every AP/AR in the domain (considering only the intra domain case). > So why is there a scalability issue here? OTOH, there may be scalability/availability > issues for the server for the very reason that you mention. > Also, if the server approach also stores the information > that it gets in a local cache, the amount of information that is stored > is the same. > How does an AR know what is a handover neighbor or not, independently of the MN providing this information as part of CARD? The information provided by the MN establishes wireless connectivity via handover between this AR's APs and another AR's APs. The authenticated information provided by an authorized server or an interrouter prototol provides information on what are valid AP to AR mappings for this service provider. These are not the same, and you cannot deduce one set of information from the other. > [Govind] I agree that the IESG is still considering the draft, but the requirement > draft has passed WG last call, therefore I don't see the reason (for sake of progress) > why we should debate this issue now, unless ofcourse if the IESG has issues with this. > OK, so it would be interesting to see some scalability figures here, how does the server based v.s. router based protocol scale? The scalability may not be such a problem, and there may be ways of limiting the amount of information that is propagated. From a robustness standpoint, and interrouter protocol might be preferable, since there is no single point of failure, but I think scalability might argue in the opposite direction. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Jan 21 18:23:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15013 for ; Tue, 21 Jan 2003 18:23:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0LNf0q26004 for seamoby-archive@odin.ietf.org; Tue, 21 Jan 2003 18:41:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LNf0J26001 for ; Tue, 21 Jan 2003 18:41:00 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15000 for ; Tue, 21 Jan 2003 18:22:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LNdFJ25937; Tue, 21 Jan 2003 18:39:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LNbgJ25890 for ; Tue, 21 Jan 2003 18:37:42 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14923 for ; Tue, 21 Jan 2003 18:19:26 -0500 (EST) Message-ID: <02fd01c2c1a3$ca6c7250$5c6015ac@T23KEMPF> From: "James Kempf" To: , , , References: Subject: Re: [Seamoby] Re: choices for rev. adr. translation mechanisms [was: CARD between Routers - will CT do?] Date: Tue, 21 Jan 2003 15:21:12 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > [Govind] An AR only needs to keep information about its handover neighbors.. > not every AP/AR in the domain (considering only the intra domain case). > So why is there a scalability issue here? OTOH, there may be scalability/availability > issues for the server for the very reason that you mention. > Also, if the server approach also stores the information > that it gets in a local cache, the amount of information that is stored > is the same. > How does an AR know what is a handover neighbor or not, independently of the MN providing this information as part of CARD? The information provided by the MN establishes wireless connectivity via handover between this AR's APs and another AR's APs. The authenticated information provided by an authorized server or an interrouter prototol provides information on what are valid AP to AR mappings for this service provider. These are not the same, and you cannot deduce one set of information from the other. > [Govind] I agree that the IESG is still considering the draft, but the requirement > draft has passed WG last call, therefore I don't see the reason (for sake of progress) > why we should debate this issue now, unless ofcourse if the IESG has issues with this. > OK, so it would be interesting to see some scalability figures here, how does the server based v.s. router based protocol scale? The scalability may not be such a problem, and there may be ways of limiting the amount of information that is propagated. From a robustness standpoint, and interrouter protocol might be preferable, since there is no single point of failure, but I think scalability might argue in the opposite direction. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Tue Jan 21 18:53:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15654 for ; Tue, 21 Jan 2003 18:53:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M0AJJ27809; Tue, 21 Jan 2003 19:10:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M09SJ27764 for ; Tue, 21 Jan 2003 19:09:28 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15580 for ; Tue, 21 Jan 2003 18:51:11 -0500 (EST) Received: from eunsoo ([138.15.107.234]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 21 Jan 2003 18:54:37 -0500 Message-ID: <016e01c2c1c1$e96a4560$ea6b0f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , , References: <007201c2c0f9$b150afc0$ea6b0f8a@eunsoo> <019601c2c178$0ad65490$5c6015ac@T23KEMPF> Subject: [Seamoby] security issue reg. rev.adr.translation mechanism [was: choices for rev. adr. translation mechanisms] Date: Tue, 21 Jan 2003 18:56:50 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 21 Jan 2003 23:54:37.0827 (UTC) FILETIME=[74D04D30:01C2C1A8] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Since there are many issues, I'd suggest we discuss one by one. My comments are inline. > > I see a few problems with the rev.adr.translation server based approach. > > > > 1) The reverse address translation server can tell only that the there is a > > registered access router with the given L2 address (probably L2 address of > > the BS associated to an access router) but it cannot tell whether the access > > router is a CAR of the current AR. Now the current AR relies on the fact > > that a MN provided the L2 address matching to a registered AR. It comes with > > the following security threat. > > > > Security threat: > > A malicious MN (tampered MN) provides a L2 address which is the L2 address > > of a registered AR but not a CAR of the current AR, that is, no overlapping > > coverage with the current AR. Then the current AR will build a CAR table > > with IP addresses of ARs that are not CARs. As long as we assume a MN can be > > tampered, this attack is very easy to play since it is easy to collect the > > L2 addresses of registered access routers. > > > > Doesn't matter. > > At the time of handover, the MN or AR will receive from layer 2 the address of > the AP to which the MN is moving. Or, the MN will ask for CARs and match the AP > layer 2 addresses in the CAR table with the addresses of the APs it can hear. > Thus, an AP address that is provided by a malicious MN but has no wireless > connectivity to the current AR will get filtered out when the MN or AR uses the > information for handover, so it can do no harm. > [eunsoo] Let's consider a dual-mode mobile terminal whose interface runs on one mode at a time. It is like an 802.11a/b interface that can run at 802.11a or 802.11b at a time and the mobile terminal should select the operation mode. Also consider a wireless network where multiple 802.11a and 802.11b access points are distributed. Currently the mobile terminal is connected to a 802.11b AP and to an AR via the 802.11b AP. Since the mobile terminal cannot receive beacons of 802.11a APs, it is good if the current AR provides the list of CARs and the associated APs to the mobile terminal so that the mobile terminal needs to check accessibility to any 802.11a only when there are 802.11a APs associated to the CARs. The current AR can provide information of pre-discovered CARs and the associated APs to the mobile terminal. If the current AR's CAR table contains an entry based on the L2 address of the malicious MN, the information is wrong and the mobile terminal may spend time and power to scan for 802.11a APs which do not exist nearby. This is an example of a CAR table that contains a wrong information. In general, if we cannot trust the integrity of the CAR table generated by the discovery process, it is difficult to develop applications using the information in the CAR table. That's why the requirements draft says it should(must?) verify that a claimed CAR is a real CAR. > There is still the issue of the bogus AP sticking around. The AR can handle this > by making the CARD information soft state, so it times out AR layer 2 addresses > if it doesn't receive a confirmation from another MN within a certain period of > time. Thus, any bogus information only has limited lifetime, and even within > that lifetime, can't do more than occupy a table slot in the router's memory. In > fact, the AR can use the number of MNs reporting a particular address to weight > the relevence of a reported AP. So if 20 MNs report it, the AP address is more > likely to stick around than if only 1 reports it. > [eunsoo] Keeping the information in the CAR table as soft state is a certainly good approach for security. I think we should apply it. However still it is preferrable to try to maintain the integrity of the CAR table as much as possible. If we allow easy insertion of false information into the CAR table, the CAR table won't be so useful. It may be useful just for L2 address to IP address mapping. Even though L2 address to IP address mapping is important for fast handoff, it is not all applications of the CAR table. > A related, but more serious, problem is if the MN undertakes a DoS attack by > flooding the AR with real or bogus layer 2 addresses. The CARD protocol between > the MN and AR must prevent this. > [eunsoo] Yes. Regards, Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Tue Jan 21 18:54:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15682 for ; Tue, 21 Jan 2003 18:54:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0M0C4n27908 for seamoby-archive@odin.ietf.org; Tue, 21 Jan 2003 19:12:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M0C4J27905 for ; Tue, 21 Jan 2003 19:12:04 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15672 for ; Tue, 21 Jan 2003 18:53:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M0AJJ27809; Tue, 21 Jan 2003 19:10:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M09SJ27764 for ; Tue, 21 Jan 2003 19:09:28 -0500 Received: from mailer.nec-labs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15580 for ; Tue, 21 Jan 2003 18:51:11 -0500 (EST) Received: from eunsoo ([138.15.107.234]) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 21 Jan 2003 18:54:37 -0500 Message-ID: <016e01c2c1c1$e96a4560$ea6b0f8a@eunsoo> From: "Eunsoo Shim" To: "James Kempf" , , References: <007201c2c0f9$b150afc0$ea6b0f8a@eunsoo> <019601c2c178$0ad65490$5c6015ac@T23KEMPF> Subject: [Seamoby] security issue reg. rev.adr.translation mechanism [was: choices for rev. adr. translation mechanisms] Date: Tue, 21 Jan 2003 18:56:50 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-OriginalArrivalTime: 21 Jan 2003 23:54:37.0827 (UTC) FILETIME=[74D04D30:01C2C1A8] Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Since there are many issues, I'd suggest we discuss one by one. My comments are inline. > > I see a few problems with the rev.adr.translation server based approach. > > > > 1) The reverse address translation server can tell only that the there is a > > registered access router with the given L2 address (probably L2 address of > > the BS associated to an access router) but it cannot tell whether the access > > router is a CAR of the current AR. Now the current AR relies on the fact > > that a MN provided the L2 address matching to a registered AR. It comes with > > the following security threat. > > > > Security threat: > > A malicious MN (tampered MN) provides a L2 address which is the L2 address > > of a registered AR but not a CAR of the current AR, that is, no overlapping > > coverage with the current AR. Then the current AR will build a CAR table > > with IP addresses of ARs that are not CARs. As long as we assume a MN can be > > tampered, this attack is very easy to play since it is easy to collect the > > L2 addresses of registered access routers. > > > > Doesn't matter. > > At the time of handover, the MN or AR will receive from layer 2 the address of > the AP to which the MN is moving. Or, the MN will ask for CARs and match the AP > layer 2 addresses in the CAR table with the addresses of the APs it can hear. > Thus, an AP address that is provided by a malicious MN but has no wireless > connectivity to the current AR will get filtered out when the MN or AR uses the > information for handover, so it can do no harm. > [eunsoo] Let's consider a dual-mode mobile terminal whose interface runs on one mode at a time. It is like an 802.11a/b interface that can run at 802.11a or 802.11b at a time and the mobile terminal should select the operation mode. Also consider a wireless network where multiple 802.11a and 802.11b access points are distributed. Currently the mobile terminal is connected to a 802.11b AP and to an AR via the 802.11b AP. Since the mobile terminal cannot receive beacons of 802.11a APs, it is good if the current AR provides the list of CARs and the associated APs to the mobile terminal so that the mobile terminal needs to check accessibility to any 802.11a only when there are 802.11a APs associated to the CARs. The current AR can provide information of pre-discovered CARs and the associated APs to the mobile terminal. If the current AR's CAR table contains an entry based on the L2 address of the malicious MN, the information is wrong and the mobile terminal may spend time and power to scan for 802.11a APs which do not exist nearby. This is an example of a CAR table that contains a wrong information. In general, if we cannot trust the integrity of the CAR table generated by the discovery process, it is difficult to develop applications using the information in the CAR table. That's why the requirements draft says it should(must?) verify that a claimed CAR is a real CAR. > There is still the issue of the bogus AP sticking around. The AR can handle this > by making the CARD information soft state, so it times out AR layer 2 addresses > if it doesn't receive a confirmation from another MN within a certain period of > time. Thus, any bogus information only has limited lifetime, and even within > that lifetime, can't do more than occupy a table slot in the router's memory. In > fact, the AR can use the number of MNs reporting a particular address to weight > the relevence of a reported AP. So if 20 MNs report it, the AP address is more > likely to stick around than if only 1 reports it. > [eunsoo] Keeping the information in the CAR table as soft state is a certainly good approach for security. I think we should apply it. However still it is preferrable to try to maintain the integrity of the CAR table as much as possible. If we allow easy insertion of false information into the CAR table, the CAR table won't be so useful. It may be useful just for L2 address to IP address mapping. Even though L2 address to IP address mapping is important for fast handoff, it is not all applications of the CAR table. > A related, but more serious, problem is if the MN undertakes a DoS attack by > flooding the AR with real or bogus layer 2 addresses. The CARD protocol between > the MN and AR must prevent this. > [eunsoo] Yes. Regards, Eunsoo _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Jan 22 10:20:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27464 for ; Wed, 22 Jan 2003 10:20:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MFb8J29454; Wed, 22 Jan 2003 10:37:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MFZaJ29125 for ; Wed, 22 Jan 2003 10:35:36 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27319 for ; Wed, 22 Jan 2003 10:16:48 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0MFK3B25483 for ; Wed, 22 Jan 2003 09:20:13 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 22 Jan 2003 09:19:51 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 22 Jan 2003 07:19:49 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Re: choices for rev. adr. translation mechanisms [was: CARD between Routers - will CT do?] Date: Wed, 22 Jan 2003 10:19:48 -0500 Message-ID: Thread-Topic: [Seamoby] Re: choices for rev. adr. translation mechanisms [was: CARD between Routers - will CT do?] Thread-Index: AcLBpAaQzwxN7h8eRKaPRn9Q6IRQBAAhRLjQ To: , , , X-OriginalArrivalTime: 22 Jan 2003 15:19:49.0820 (UTC) FILETIME=[B48A37C0:01C2C229] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0MFZaJ29126 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Jim, How does an AR know what is a handover neighbor or not, independently of the MN providing this information as part of CARD? The information provided by the MN establishes wireless connectivity via handover between this AR's APs and another AR's APs. The authenticated information provided by an authorized server or an interrouter prototol provides information on what are valid AP to AR mappings for this service provider. These are not the same, and you cannot deduce one set of information from the other. [Govind] If I understand you right, you are talking about the method of populating the cache at the AR. There are several ways to do this. One way is explained in the dycard draft. But the point that I was trying to get across is that an AR does not have have to maintain any more information that it needs for making handover decisions, i.e. its GAAR (using an old term) information. OK, so it would be interesting to see some scalability figures here, how does the server based v.s. router based protocol scale? The scalability may not be such a problem, and there may be ways of limiting the amount of information that is propagated. From a robustness standpoint, and interrouter protocol might be preferable, since there is no single point of failure, but I think scalability might argue in the opposite direction. [Govind] I don't really see a scalability problem right now with the non-server based protocol. However, we can discuss this once the design team gets a document out. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Jan 22 10:20:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27498 for ; Wed, 22 Jan 2003 10:20:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0MFcwj29976 for seamoby-archive@odin.ietf.org; Wed, 22 Jan 2003 10:38:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MFcwJ29973 for ; Wed, 22 Jan 2003 10:38:58 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27478 for ; Wed, 22 Jan 2003 10:20:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MFb8J29454; Wed, 22 Jan 2003 10:37:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MFZaJ29125 for ; Wed, 22 Jan 2003 10:35:36 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27319 for ; Wed, 22 Jan 2003 10:16:48 -0500 (EST) From: Govind.Krishnamurthi@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0MFK3B25483 for ; Wed, 22 Jan 2003 09:20:13 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 22 Jan 2003 09:19:51 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 22 Jan 2003 07:19:49 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Seamoby] Re: choices for rev. adr. translation mechanisms [was: CARD between Routers - will CT do?] Date: Wed, 22 Jan 2003 10:19:48 -0500 Message-ID: Thread-Topic: [Seamoby] Re: choices for rev. adr. translation mechanisms [was: CARD between Routers - will CT do?] Thread-Index: AcLBpAaQzwxN7h8eRKaPRn9Q6IRQBAAhRLjQ To: , , , X-OriginalArrivalTime: 22 Jan 2003 15:19:49.0820 (UTC) FILETIME=[B48A37C0:01C2C229] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0MFZaJ29126 Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Jim, How does an AR know what is a handover neighbor or not, independently of the MN providing this information as part of CARD? The information provided by the MN establishes wireless connectivity via handover between this AR's APs and another AR's APs. The authenticated information provided by an authorized server or an interrouter prototol provides information on what are valid AP to AR mappings for this service provider. These are not the same, and you cannot deduce one set of information from the other. [Govind] If I understand you right, you are talking about the method of populating the cache at the AR. There are several ways to do this. One way is explained in the dycard draft. But the point that I was trying to get across is that an AR does not have have to maintain any more information that it needs for making handover decisions, i.e. its GAAR (using an old term) information. OK, so it would be interesting to see some scalability figures here, how does the server based v.s. router based protocol scale? The scalability may not be such a problem, and there may be ways of limiting the amount of information that is propagated. From a robustness standpoint, and interrouter protocol might be preferable, since there is no single point of failure, but I think scalability might argue in the opposite direction. [Govind] I don't really see a scalability problem right now with the non-server based protocol. However, we can discuss this once the design team gets a document out. jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From seamoby-admin@ietf.org Wed Jan 22 11:59:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01011 for ; Wed, 22 Jan 2003 11:59:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MHBiJ04727; Wed, 22 Jan 2003 12:11:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MHAYJ04665 for ; Wed, 22 Jan 2003 12:10:34 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00719 for ; Wed, 22 Jan 2003 11:51:56 -0500 (EST) Message-ID: <000e01c2c236$d296dcc0$5c6015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , , References: <007201c2c0f9$b150afc0$ea6b0f8a@eunsoo> <019601c2c178$0ad65490$5c6015ac@T23KEMPF> <016e01c2c1c1$e96a4560$ea6b0f8a@eunsoo> Subject: Re: [Seamoby] security issue reg. rev.adr.translation mechanism [was: choices for rev. adr. translation mechanisms] Date: Wed, 22 Jan 2003 08:53:03 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > [eunsoo] Let's consider a dual-mode mobile terminal whose interface runs on > one mode at a time. It is like an 802.11a/b interface that can run at > 802.11a or 802.11b at a time and the mobile terminal should select the > operation mode. Also consider a wireless network where multiple 802.11a and > 802.11b access points are distributed. > Currently the mobile terminal is connected to a 802.11b AP and to an AR via > the 802.11b AP. Since the mobile terminal cannot receive beacons of 802.11a > APs, it is good if the current AR provides the list of CARs and the > associated APs to the mobile terminal so that the mobile terminal needs to > check accessibility to any 802.11a only when there are 802.11a APs > associated to the CARs. > The current AR can provide information of pre-discovered CARs and the > associated APs to the mobile terminal. If the current AR's CAR table > contains an entry based on the L2 address of the malicious MN, the > information is wrong and the mobile terminal may spend time and power to > scan for 802.11a APs which do not exist nearby. This is an example of a CAR > table that contains a wrong information. In general, if we cannot trust the > integrity of the CAR table generated by the discovery process, it is > difficult to develop applications using the information in the CAR table. > That's why the requirements draft says it should(must?) verify that a > claimed CAR is a real CAR. > But this doesn't result in the MN taking any action that would result in compromising its IP service. It is just a failure of the optimization. If there were no CAR, the MN would have to take exactly the same action and scan. When it scans, it will quickly find out that someone has lied to the AR and can tell the AR, thus causing the AR to flush the bogus AP. If the AR uses an algorithm that weighs how long it keeps an AP in the table by the number of MNs reporting the AP, then the bogus AP will get flushed very quickly even if the MN doesn't tell the AR that someone has lied. To maintain good quality, the AR can associate the L2 address of the MN reporting the data with the report, then refuse to take any reports from someone who lies. This won't work if the MN changes its L2 address arbitrarily, of course. I can't see any way to solve this, short of requiring a person to meticulously record whether an AP is connected to a potential CAR or not by going around and measuring wireless connectivity between ARs prior to anyone using the network. Requiring this would violate one of the primary goals of CAR, to faciliate autoconfiguration. Most of the proposals I've seen for CAR involve having the AR infer wireless connectivity by using the AP address provided by the MN or, alternatively, the AR address of a previous AP, then using some kind of authenticated lookup to determine whether the AP address is a legitimate AP connected to a legitimate AR. Do you have any suggestions about how an AR, independently of the MN reporting an AP or AR address, can determine whether there is wireless connectivity with another AR without having such an extensive, hand entered database? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby From mailnull@www1.ietf.org Wed Jan 22 12:00:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01054 for ; Wed, 22 Jan 2003 12:00:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0MHIVN05116 for seamoby-archive@odin.ietf.org; Wed, 22 Jan 2003 12:18:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MHIVJ05113 for ; Wed, 22 Jan 2003 12:18:31 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01025 for ; Wed, 22 Jan 2003 11:59:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MHBiJ04727; Wed, 22 Jan 2003 12:11:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MHAYJ04665 for ; Wed, 22 Jan 2003 12:10:34 -0500 Received: from fridge.docomolabs-usa.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00719 for ; Wed, 22 Jan 2003 11:51:56 -0500 (EST) Message-ID: <000e01c2c236$d296dcc0$5c6015ac@T23KEMPF> From: "James Kempf" To: "Eunsoo Shim" , , References: <007201c2c0f9$b150afc0$ea6b0f8a@eunsoo> <019601c2c178$0ad65490$5c6015ac@T23KEMPF> <016e01c2c1c1$e96a4560$ea6b0f8a@eunsoo> Subject: Re: [Seamoby] security issue reg. rev.adr.translation mechanism [was: choices for rev. adr. translation mechanisms] Date: Wed, 22 Jan 2003 08:53:03 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-BeenThere: seamoby@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > [eunsoo] Let's consider a dual-mode mobile terminal whose interface runs on > one mode at a time. It is like an 802.11a/b interface that can run at > 802.11a or 802.11b at a time and the mobile terminal should select the > operation mode. Also consider a wireless network where multiple 802.11a and > 802.11b access points are distributed. > Currently the mobile terminal is connected to a 802.11b AP and to an AR via > the 802.11b AP. Since the mobile terminal cannot receive beacons of 802.11a > APs, it is good if the current AR provides the list of CARs and the > associated APs to the mobile terminal so that the mobile terminal needs to > check accessibility to any 802.11a only when there are 802.11a APs > associated to the CARs. > The current AR can provide information of pre-discovered CARs and the > associated APs to the mobile terminal. If the current AR's CAR table > contains an entry based on the L2 address of the malicious MN, the > information is wrong and the mobile terminal may spend time and power to > scan for 802.11a APs which do not exist nearby. This is an example of a CAR > table that contains a wrong information. In general, if we cannot trust the > integrity of the CAR table generated by the discovery process, it is > difficult to develop applications using the information in the CAR table. > That's why the requirements draft says it should(must?) verify that a > claimed CAR is a real CAR. > But this doesn't result in the MN taking any action that would result in compromising its IP service. It is just a failure of the optimization. If there were no CAR, the MN would have to take exactly the same action and scan. When it scans, it will quickly find out that someone has lied to the AR and can tell the AR, thus causing the AR to flush the bogus AP. If the AR uses an algorithm that weighs how long it keeps an AP in the table by the number of MNs reporting the AP, then the bogus AP will get flushed very quickly even if the MN doesn't tell the AR that someone has lied. To maintain good quality, the AR can associate the L2 address of the MN reporting the data with the report, then refuse to take any reports from someone who lies. This won't work if the MN changes its L2 address arbitrarily, of course. I can't see any way to solve this, short of requiring a person to meticulously record whether an AP is connected to a potential CAR or not by going around and measuring wireless connectivity between ARs prior to anyone using the network. Requiring this would violate one of the primary goals of CAR, to faciliate autoconfiguration. Most of the proposals I've seen for CAR involve having the AR infer wireless connectivity by using the AP address provided by the MN or, alternatively, the AR address of a previous AP, then using some kind of authenticated lookup to determine whether the AP address is a legitimate AP connected to a legitimate AR. Do you have any suggestions about how an AR, independently of the MN reporting an AP or AR address, can determine whether there is wireless connectivity with another AR without having such an extensive, hand entered database? jak _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby