From mailman-bounces@ietf.org Fri Oct 1 07:43:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20455 for ; Fri, 1 Oct 2004 07:43:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDLxn-00058l-DG for mip6-web-archive@ietf.org; Fri, 01 Oct 2004 07:52:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDJrZ-0002dV-9l for mip6-web-archive@ietf.org; Fri, 01 Oct 2004 05:38:05 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: mip6-web-archive@ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Oct 2004 05:16:04 -0400 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit 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, mailman-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: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for mip6-web-archive@ietf.org: List Password // URL ---- -------- mip6@ietf.org motoka https://www1.ietf.org/mailman/options/mip6/mip6-web-archive%40ietf.org From mip6-bounces@ietf.org Fri Oct 1 12:51:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23713 for ; Fri, 1 Oct 2004 12:51:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDQlE-0003BO-E3 for mip6-web-archive@ietf.org; Fri, 01 Oct 2004 13:00:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDPhf-0002B8-8v; Fri, 01 Oct 2004 11:52:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDMRo-0000sG-GQ for mip6@megatron.ietf.org; Fri, 01 Oct 2004 08:23:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23325 for ; Fri, 1 Oct 2004 08:23:37 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDMaF-0005yc-F3 for mip6@ietf.org; Fri, 01 Oct 2004 08:32:24 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i91COjDx011760; Fri, 1 Oct 2004 05:24:45 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id i91CMF0H026927; Fri, 1 Oct 2004 07:22:15 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id A0FFC88CF71; Fri, 1 Oct 2004 14:23:28 +0200 (CEST) Message-ID: <415D4C40.6010707@motorola.com> Date: Fri, 01 Oct 2004 14:23:28 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: livsix@enrl.motlabs.com X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: usagi-users@linux-ipv6.org, mip6@ietf.org, Hong-Yon Lach , Christophe Janneteau Subject: [Mip6] Announcement: new version of the LIVSIX IPv6 Stack for Mobility Environments X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit This is to announce a new version of the LIVSIX Open Source IPv6 stack for mobility environments available at: http://www.enrl.motlabs.com/livsix This stack is written entirely from scratch and does not include any code from any other widely available IPv6/Mobile IPv6 stack. Since the last announcement February 2002, the stack undergone signficant changes and received many new features. It has detailed step-by-step instructions on how to set up IPv6 addresses, IPv6 mobility, routing and moving networks. It has complete or partial implementations the following protocols: -IPv6 RFC 2460 and RFC 2461 -Neighbour Discovery -Multicast Listener Discovery -Mobile IPv6 (partial: DHAAD, MPD, BU/BAck/BErr/Breq but no RR no IPsec). -supports moving networks, in an approximately NEMO Base Protocol way. -TCPv6, UDPv6. -it does static routing. Application support: -offers a BSD socket interface to the IPv6 applications. -ping6 -ssh -6 -konqueror -vic -telnet, ftp -nslookup It runs on: -Linux kernel 2.4 and 2.6 series (2.4 ok, 2.6 early ok, 2.6 latest compile ok but no execution) -Zaurus PDA and ColdFire board. It runs over the following l2 interfaces: -Ethernet -WLAN 802.11b -serial sl0 and ppp0 -bluetooth It runs on ha.enrl.motlabs.com. It has been interoperatedly tested with a certain version of MIPL HA. The local goals with this stack development are geared more towards portability and less towards protocol feature support. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Oct 4 17:57:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01008 for ; Mon, 4 Oct 2004 17:57:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEazJ-0000q7-3P for mip6-web-archive@ietf.org; Mon, 04 Oct 2004 18:07:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEanu-0003dY-Kx; Mon, 04 Oct 2004 17:55:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEakW-0002CJ-Q4 for mip6@megatron.ietf.org; Mon, 04 Oct 2004 17:52:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00394 for ; Mon, 4 Oct 2004 17:52:01 -0400 (EDT) Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEatg-00088D-Ls for mip6@ietf.org; Mon, 04 Oct 2004 18:01:33 -0400 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i94LpWlS019313 for ; Mon, 4 Oct 2004 16:51:33 -0500 (CDT) Message-ID: <4161C5E4.A9515344@alcatel.com> Date: Mon, 04 Oct 2004 16:51:32 -0500 From: Tim Ozugur X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mip6@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Content-Transfer-Encoding: 7bit Subject: [Mip6] BroadNets 2004: Early Registration extended to Oct. 10, 2004 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Content-Transfer-Encoding: 7bit (Apologies if you are receiving this message more than once) ----------------------------------------------------------------------- CALL FOR PARTICIPATION BroadNets 2004 First International Conference on Broadband Networking Technically Co-Sponsored by IEEE Communications Society In-Cooperation with ACM SIGMOBILE Co-sponsored by: CreateNet, Inc. ICST National Science Foundation (Student Travel Awards) Philips, Inc. (Bronze Level Sponsor; Student Best Paper Awards) Hilton San Jose and Towers San Jose, California, USA October 25 - 29, 2004 http://www.broadnets.org Early Registration Deadline: Oct. 10, 2004 Discounted Hotel Reservation Deadline: Oct. 4, 2004 ----------------------------------------------------------------------- BroadNets 2004 is a new conference focusing on broadband networking and covers the entire gamut of next generation networks with ultra-high bandwidth available all the way from access networks (xDSL, Cable, EPON, Broadband Wireless, multi-Gigabit uplinks), to regional and metropolitan networks to wide-area core networks. Keynote speakers include: * Vinton Cerf, Senior Vice President of Technology Strategy for MCI * Dr. Lawrence G. Roberts, CEO of Anagran and Founder and Vice Chairman of Caspian Networks The conference will consist of two symposia, panels, six tutorials and seven workshops: * Broadband Optical Symposium includes 32 papers covering topics such as optical burst and packet switching, IP over optical networks, survivability, routing and wavelength assignment, traffic and wavelength grooming, switching and routing, and optical network design and resource allocation. * Broadband Wireless Symposium includes 38 papers covering topics such as 802.11 networks, UWB and 802.15 based networks, performance analysis, wireless multimedia, resource management, multimedia transport, contention and media access, routing in ad hoc networks, and sensor networks. * TUTORIALS (on Oct 25 and Oct 29): - Broadband Metro and Access Networks (Full-day), Dr. Raj Jain - Optical Mesh Survivability (Half-day), Dr. Suresh Subramaniam and Dr. Srinivasan Ramasubramanian - Advancements in Metro Optical Network Architecture and Technologies (Half-day) Dr. Loukas Paraschis - Wireless Broadband: Services, Networks, and Management (Full-day), Dr. Mani Subramanian - Multimedia Transmission over Spectrum Agile Radio Wireless Networks (Half-day) Dr. Mihaela van der Schaar - A Practical Perspective on the Role of Optical Layer Protection (Half-day) Dr. Ori Gerstel WORKSHOPS co-located with BroadNets 2004: - Broadband Wireless Multimedia (BroadWim) - Broadband Advanced Sensor Networks (BaseNets) - Broadband Wireless Services and Applications (BroadWise) - Networks for Grid Applications (GridNets) - Optical Burst Switching (OBS) - Provisioning and Transport for Hybrid Networks (PathNets) - Traffic Grooming Workshops will be held on Monday, October 25 and Friday, October 29. For the advance program of BroadNets 2004, as well as registration and travel information, please visit: http://www.broadnets.org. CONFERENCE ORGANIZING COMMITTEE ------------------------------- BroadNets Conference General Chair: Dr. Raj Jain, Nayna Networks/Ohio State University, raj@nayna.com _________________________________ Broadband Optical Networking Symposium Co-Chairs: Dr. Ori Gerstel, Cisco Systems, ogerstel@cisco.com Dr. Jason Jue, University of Texas at Dallas, jjue@utdallas.edu Technical Program Co-Chairs: Dr. Galen Sasaki, University of Hawaii, sasaki@spectra.eng.hawaii.edu Dr. Suresh Subramaniam, George Washington University, suresh@gwu.edu __________________________________ Broadband Wireless Networking Symposium Chair: Dr. Zhensheng Zhang, San Diego Research Center, zzhang@ieee.org Technical Program Co-Chairs: Dr. Parameswaran Ramanathan, University of Wisconsin-Madison, parmesh@ece.wisc.edu Dr. Thomas Hou, Virginia Tech, thou@vt.edu _____________________________ Panels Co-Chairs: Dr. Byrav Ramamurthy, University of Nebraska - Lincoln, byrav@cse.unl.edu Dr. Loukas Paraschis, Cisco Systems, loukas@cisco.com Dr. Mohammed Atiquzzaman, University of Oklahoma, atiq@ou.edu Tutorials Co-Chairs: Dr. Hakki Candan Cankaya, Alcatel USA, hakki.cankaya@alcatel.com Dr. Surendar Chandra, Univ of Notre Dame, surendar@cse.nd.edu Workshops Chair: Dr. Nasir Ghani, Tennessee Tech University, nghani@ieee.org Dr. Rajeev Shorey, National University of Singapore and IBM Research India, rajeev@comp.nus.edu.sg Exhibits and Sponsorships Chairs: Dr. Samrat Ganguly, NEC Labs, samrat@nec-labs.com Dr. Javier Aracil, Universidad Publica de Navarra, Spain, javier.aracil@unavarra.es Publicity Co-Chairs: Dr. Tim Ozugur, Alcatel USA, tim.ozugur@alcatel.com Dr. Gaoxi Xiao, Nanyang Technological Univ. Singapore, egxxiao@ntu.edu.sg Dr. Marcos Rogerio Salvador, CPqD Telecom & IT Solutions, marcosrs@cpqd.com.br Local Arrangements Chair: Dr. Subhankar Dhar, San Jose State University, dhar_s@cob.sjsu.edu Sukesh Pai, Microsoft Corp. sukeshp@microsoft.com Steering Committee Co-Chairs: Dr. Imrich Chlamtac, UT Dallas, chlamtac@utdallas.edu Dr. Krishna Sivalingam, University of Maryland, Baltimore County, krishna@umbc.edu -------------------------------------------------------------------------- _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Oct 5 09:22:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26316 for ; Tue, 5 Oct 2004 09:22:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEpQD-0003II-ME for mip6-web-archive@ietf.org; Tue, 05 Oct 2004 09:32:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEpB1-0008EE-HE; Tue, 05 Oct 2004 09:16:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEmyG-00067j-RB; Tue, 05 Oct 2004 06:55:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14138; Tue, 5 Oct 2004 06:55:01 -0400 (EDT) Received: from cs-lists.cs.colorado.edu ([128.138.243.152]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEn7X-0004ie-9N; Tue, 05 Oct 2004 07:04:39 -0400 Received: from cs-lists.cs.colorado.edu (localhost.cs.colorado.edu [127.0.0.1]) by cs-lists.cs.colorado.edu (8.12.10/8.12.6) with ESMTP id i95Ak9cU086066; Tue, 5 Oct 2004 04:49:10 -0600 (MDT) Received: from mroe.cs.colorado.edu (mroe.cs.colorado.edu [128.138.243.151]) by cs-lists.cs.colorado.edu (8.12.10/8.12.6) with ESMTP id i95Aa3cS086042 for ; Tue, 5 Oct 2004 04:36:03 -0600 (MDT) Received: from research.cs.colorado.edu (research.cs.colorado.edu [128.138.242.225]) by mroe.cs.colorado.edu (8.12.10/8.12.6) with ESMTP id i95AZvls032735 for ; Tue, 5 Oct 2004 04:36:03 -0600 (MDT) Received: from [127.0.0.1] (c-24-8-166-41.client.comcast.net [24.8.166.41]) by research.cs.colorado.edu (8.12.10/8.12.6) with ESMTP id i95AZtsm028609 for ; Tue, 5 Oct 2004 04:35:57 -0600 (MDT) Message-ID: <41627908.1050002@cs.colorado.edu> Date: Tue, 05 Oct 2004 04:35:52 -0600 Organization: University of Colorado at Boulder User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: basenets04-cfp@cs-lists.cs.colorado.edu Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Mailman-Approved-At: Tue, 05 Oct 2004 04:45:59 -0600 From: basenets04-cfp@cs-lists.cs.colorado.edu X-BeenThere: basenets04-cfp@cs-lists.cs.colorado.edu X-Mailman-Version: 2.1.4 Precedence: list List-Archive: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by cs-lists.cs.colorado.edu id i95Ak9cU086066 X-Spam-Score: 0.4 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 05 Oct 2004 09:16:22 -0400 Subject: [Mip6] BASENETS 2004 Call For Participation X-BeenThere: mip6@ietf.org List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Content-Transfer-Encoding: quoted-printable Apologies if you receive multiple copies of this call! ---------------------------------------------------------------------- CALL FOR PARTICIPATION ******************************************************** * * * 1st Workshop on Broadband Advanced Sensor Networks * * (co-located with BroadNets 04) * * San Jose, CA, October 25, 2004 * * * * BASENETS 04 * * * ******************************************************** * * * http://www.basenets.org * * * ******************************************************** BaseNets 2004 Overview The emergence and adoption of broadband wireless access standards, such as 802.16, 802.16a and 802.11a, offers exciting new possibilities for high-bandwidth data communication over the "last mile." A significant use of such high bandwidth may lie in the use of a variety of multimodal sensors for monitoring and control of diverse geographic areas. Such sensors may be used for remote video/audio surveillance and active monitoring of telemetry data in city blocks, highways, airports, hotels, campuses and a variety of other indoor and outdoor environments. This workshop is intended for the presentation and discussion of novel architectures, algorithms and applications of sensor networks based on the use of wireless broadband channels. The workshop will include sessions on different approaches to enabling broadband sensor applications, information processing, deployment and networking for broadband sensor networks, as well as a keynote talk by Professor Edward Chang from U.C. Santa Barbara. Topics will include middleware for broadband sensor networks and pervasive environments, in-network processing, deployment and calibration of broadband sensor networks, routing and congestion control. Tentative BaseNets 2004 Program * =3D invited presentation 8:00 - 8:15 Welcome Address 8:15 - 9:30 Session 1 - Enabling Applications in Broadband Sensor Networ= ks 1. *Applications and Design of Heterogeneous and/or Broadband Sensor=20 Networks Lihua Yuan, Chao Gui, Chen-Nee Chuah, and Prasant Mohapatra University of California, Davis 2. Enabling Applications in Sensor-based Pervasive Environments Nanyan Jiang, Cristina Schmidt, Vincent Matossian and Manish Parasha= r Rutgers University 3. Middleware Guidelines for Future Sensor Networks Matthew Wolenetz, Rajnish Kumar, Junsuk Shin, and Umakishore=20 Ramachandran Georgia Institute of Technology 9:30 - 9:50 Coffee Break 9:50 - 11:30 Session 2 - Information Processing in Broadband Sensor=20 Networks 1. A Distributed Filtering Architecture for Multimedia Sensors Suman Nath1, Yan Ke1, Phillip B. Gibbons2, Brad Karp2, and=20 Srinivasan Seshan1 1 Carnegie Mellon University 2 Intel Research 2. Secure and Efficient In-Network Processing for Sensor Networks Tassos Dimitriou1 and Dimitris Foteinakis2 1 Athens Information Technology 2 Intracom S.A. 3. Distributed Metric Calibration of Large Camera Networks Dhanya Devarajan and Richard J. Radke Rensselaer Polytechnic Institute 4. Sensor Tasking for Occupancy Reasoning in a Network of Cameras Danny B. Yang, Jaewon Shin, Ali Ozer Ercan, Leonidas J. Guibas Stanford University 11:30 - 1:30 Lunch Break 1:30 - 2:30 Keynote Address "Event Sensing on Distributed Video-Sensor Networks" Professor Edward Chang University of California, Santa Barbara 2:30 - 3:10 Session 3 - Deployment of Broadband Sensor Networks 1. *Low-Power Image Transmission in Wireless Sensor Networks using=20 ScatterWeb Technology Enrico K=F6ppe, Achim Liers, Hartmut Ritter, Jochen Schiller Freie Universit=E4t Berlin 2. Deploying Long-Lived and Cost-effective Hybrid Sensor Networks Wen Hu1,2, Chun Tung Chou1, Sanjay Jha1,2, and Nirupama Bulusu3 1 The University of NSW 2 National ICT Australia Limited 3 Oregon Health and Sciences University 3:10 - 3:40 Coffee Break 3:40 - 5:00 Session 4 - Networking Broadband Sensors 1. *Lifetime-Optimal Data Routing in Wireless Sensor Networks Without=20 Flow Splitting Y. Thomas1, Hou_ Yi Shi1, Jianping Pan2, and Scott F. Midkiff1 1 Virginia Tech=09 2 University of Waterloo 2. Adaptive Resource Control Scheme to Alleviate Congestion in Sensor=20 Networks Jaewon Kang, Badri Nath, Yanyong Zhang, and Shengchao Yu Rutgers University 3. Energy-Efficient Clustering Method for Data Gathering in Sensor Netwo= rks Junpei Kamimura, Naoki Wakamiya, and Masayuki Murata Osaka University Please join us in San Jose for Basenets 2004! Workshop Chairs: W. Heinzelman (U. of Rochester) B. Krishnamachari (U. of Southern California) Program Committee: N. Abu-Ghazaleh (Binghamton U.) J. Apostolopoulos (HP Labs) A. Bestavros (Boston U.) A. Campbell (Columbia U.) M. El Zarki (U. of California at Irvine) W.-C. Feng (OGI) S. Gupta (Arizona State U.) R. Han (U. of Colorado at Boulder) A. Helmy (U. of Southern California) S. Jha (U. of New South Wales) H. Karl (University Paderborn) M. Liu (U. of Michigan) B. Nath (Rutgers U.) M. Papadopouli (U. of North Carolina) A. Safwat (Queens U.) I. Stojmenovic (U. of Ottawa) U. Tureli (Stevens U.) M. van der Schaar (U. of California at Davis) P. Varshney (Syracuse U.) Publicity Chairs: R. Han (U. of Colorado at Boulder) H. Karl (Technical University Berlin) For more details, please visit http://www.basenets.org or contact basenets04-chairs@ece.rochester.edu _______________________________________________ basenets04-cfp mailing list basenets04-cfp@cs-lists.cs.colorado.edu http://cs-lists.cs.colorado.edu/mailman/listinfo/basenets04-cfp _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Oct 6 18:21:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24640 for ; Wed, 6 Oct 2004 18:21:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFKJW-0007bl-G5 for mip6-web-archive@ietf.org; Wed, 06 Oct 2004 18:31:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFK4i-0007Lz-52; Wed, 06 Oct 2004 18:15:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFJtZ-0000QP-Vj for mip6@megatron.ietf.org; Wed, 06 Oct 2004 18:04:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21600 for ; Wed, 6 Oct 2004 18:04:22 -0400 (EDT) From: Basavaraj.Patil@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFK38-0006FF-N5 for mip6@ietf.org; Wed, 06 Oct 2004 18:14:20 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i96M4Mh01097 for ; Thu, 7 Oct 2004 01:04:22 +0300 (EET DST) X-Scanned: Thu, 7 Oct 2004 01:04:11 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i96M4BYT003345 for ; Thu, 7 Oct 2004 01:04:11 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00ACWPej; Thu, 07 Oct 2004 01:04:09 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i96M48S27226 for ; Thu, 7 Oct 2004 01:04:09 +0300 (EET DST) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 6 Oct 2004 17:02:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Oct 2004 17:02:55 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF4403B1BF01@daebe007.americas.nokia.com> Thread-Topic: Consensus Call: Standardizing the auth protocol [I-D: draft-ietf-mip6-auth-protocol-00.txt] Thread-Index: AcSr8DqS6Ympo/12TUmUacaxgh/VgA== To: X-OriginalArrivalTime: 06 Oct 2004 22:02:56.0154 (UTC) FILETIME=[3C1227A0:01C4ABF0] X-Spam-Score: 0.3 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable Subject: [Mip6] Consensus Call: Standardizing the auth protocol [I-D: draft-ietf-mip6-auth-protocol-00.txt] X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable This is a consensus call to the WG on the issue of standardizing the authentication-data-suboption mechanism for performing a binding between = the MN and HA. The issue has been discussed on the WG mailing list over the last few weeks. The I-D (draft-patil-mip6-whyauthdataoption-00.txt) has captured some of the arguments, but there are several others that have been made on the list as well. A summary of the discussion was sent out earlier and is captured in : http://www1.ietf.org/mail-archive/web/mip6/current/msg01690.html The proposal here (in brief) is to standardize a mechanism specified in I-D draft-ietf-mip6-auth-protocol-00.txt for performing MIP6 registration with a home agent. RFC3775 specifies the use of IPsec to secure the binding update/ACK messages between the MN and HA. The auth-protocol mechanism relies on the use of an authentication-data-suboption and does not require the MN-HA to establish an IPsec SA. =20 (For the discussion that has ensued so far, please refer to the MIP6 ML archives) The question to the WG is: 1. Should we standardize the authentication protocol specified in I-D draft-ietf-mip6-auth-protocol-00.txt as an alternative (to the IPSec mechanism specified in RFC3775/6) means to securing the BUs and BAcks between the MN and HA. Note that this solution is an additional mechanism for doing registration with an HA and does not deprecate the currently specified solution.=20 Yes [ ] No [ ] The consensus call will close on October 12th, 2004. -Chairs _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Oct 6 18:41:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26386 for ; Wed, 6 Oct 2004 18:41:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFKdP-0000bX-8F for mip6-web-archive@ietf.org; Wed, 06 Oct 2004 18:51:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFKS3-0007lX-LA; Wed, 06 Oct 2004 18:40:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFKRB-0007Wp-Nc for mip6@megatron.ietf.org; Wed, 06 Oct 2004 18:39:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26291 for ; Wed, 6 Oct 2004 18:39:05 -0400 (EDT) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFKaa-0000QM-3p for mip6@ietf.org; Wed, 06 Oct 2004 18:49:03 -0400 Message-ID: <028201c4abf5$602aa040$656115ac@dcml.docomolabsusa.com> From: "James Kempf" To: , References: <697DAA22C5004B4596E033803A7CEF4403B1BF01@daebe007.americas.nokia.com> Subject: Re: [Mip6] Consensus Call: Standardizing the auth protocol [I-D:draft-ietf-mip6-auth-protocol-00.txt] Date: Wed, 6 Oct 2004 15:39:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Lacking any Security Directorate review opinion on this, I must regrettably vote NO. I would, however, support pursuing the draft as an informational RFC for 3GPP2 use only. jak ----- Original Message ----- From: To: Sent: Wednesday, October 06, 2004 3:02 PM Subject: [Mip6] Consensus Call: Standardizing the auth protocol [I-D:draft-ietf-mip6-auth-protocol-00.txt] This is a consensus call to the WG on the issue of standardizing the authentication-data-suboption mechanism for performing a binding between the MN and HA. The issue has been discussed on the WG mailing list over the last few weeks. The I-D (draft-patil-mip6-whyauthdataoption-00.txt) has captured some of the arguments, but there are several others that have been made on the list as well. A summary of the discussion was sent out earlier and is captured in : http://www1.ietf.org/mail-archive/web/mip6/current/msg01690.html The proposal here (in brief) is to standardize a mechanism specified in I-D draft-ietf-mip6-auth-protocol-00.txt for performing MIP6 registration with a home agent. RFC3775 specifies the use of IPsec to secure the binding update/ACK messages between the MN and HA. The auth-protocol mechanism relies on the use of an authentication-data-suboption and does not require the MN-HA to establish an IPsec SA. (For the discussion that has ensued so far, please refer to the MIP6 ML archives) The question to the WG is: 1. Should we standardize the authentication protocol specified in I-D draft-ietf-mip6-auth-protocol-00.txt as an alternative (to the IPSec mechanism specified in RFC3775/6) means to securing the BUs and BAcks between the MN and HA. Note that this solution is an additional mechanism for doing registration with an HA and does not deprecate the currently specified solution. Yes [ ] No [ ] The consensus call will close on October 12th, 2004. -Chairs _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Oct 6 18:52:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26866 for ; Wed, 6 Oct 2004 18:52:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFKnP-0001B6-Kf for mip6-web-archive@ietf.org; Wed, 06 Oct 2004 19:02:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFKYf-0001TF-OV; Wed, 06 Oct 2004 18:46:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFKY4-0001Hp-D1 for mip6@megatron.ietf.org; Wed, 06 Oct 2004 18:46:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26621 for ; Wed, 6 Oct 2004 18:46:13 -0400 (EDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFKhd-0000oN-LA for mip6@ietf.org; Wed, 06 Oct 2004 18:56:11 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i96MkDil025382; Wed, 6 Oct 2004 16:46:13 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i96MkBJQ011522; Thu, 7 Oct 2004 00:46:12 +0200 (MEST) Message-ID: <416475DD.2000605@sun.com> Date: Wed, 06 Oct 2004 15:46:53 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com Subject: Re: [Mip6] Consensus Call: Standardizing the auth protocol [I-D: draft-ietf-mip6-auth-protocol-00.txt] References: <697DAA22C5004B4596E033803A7CEF4403B1BF01@daebe007.americas.nokia.com> In-Reply-To: <697DAA22C5004B4596E033803A7CEF4403B1BF01@daebe007.americas.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit I don't know if you wanted the mailing list to be cc'ed. But here it goes: > 1. Should we standardize the authentication protocol specified in I-D > draft-ietf-mip6-auth-protocol-00.txt as an alternative (to the > IPSec mechanism specified in RFC3775/6) means to securing the BUs > and BAcks between the MN and HA. Note that this solution is an > additional mechanism for doing registration with an HA and does not > deprecate the currently specified solution. > > Yes [ ] > No [XXX] Erik _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Oct 6 19:23:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28734 for ; Wed, 6 Oct 2004 19:23:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFLHK-00031D-GC for mip6-web-archive@ietf.org; Wed, 06 Oct 2004 19:33:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFL6k-00016v-Qr; Wed, 06 Oct 2004 19:22:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFKxA-0007Xm-HV for mip6@megatron.ietf.org; Wed, 06 Oct 2004 19:12:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28074 for ; Wed, 6 Oct 2004 19:12:09 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFL6k-0002Px-0D for mip6@ietf.org; Wed, 06 Oct 2004 19:22:07 -0400 Received: from heliopolis.sfbay.sun.com ([152.70.20.39]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i96NC635016390; Wed, 6 Oct 2004 16:12:06 -0700 (PDT) Received: from [129.146.73.230] (d-mpk16-73-230.SFBay.Sun.COM [129.146.73.230]) by heliopolis.sfbay.sun.com (8.11.6+Sun/8.11.6/ENSMAIL,v2.1p1) with ESMTP id i96NC5V08955; Wed, 6 Oct 2004 16:12:05 -0700 (PDT) Message-ID: <41647BA5.2050602@sun.com> Date: Wed, 06 Oct 2004 16:11:33 -0700 From: gabriel montenegro User-Agent: Mozilla Thunderbird 0.8 (Macintosh/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf Subject: Re: [Mip6] Consensus Call: Standardizing the auth protocol [I-D:draft-ietf-mip6-auth-protocol-00.txt] References: <697DAA22C5004B4596E033803A7CEF4403B1BF01@daebe007.americas.nokia.com> <028201c4abf5$602aa040$656115ac@dcml.docomolabsusa.com> In-Reply-To: <028201c4abf5$602aa040$656115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, Basavaraj.Patil@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit James Kempf wrote: > Lacking any Security Directorate review opinion on this, I must regrettably > vote NO. I would, however, support pursuing the draft as an informational > RFC for 3GPP2 use only. Agree. I know in the past the security ADs have been quite adamant about using IPsec. As to how to obtain the SA for use by IPsec, well, my feeling is that they have been much more flexible. Vote: NO. And the suggestion to pursue as non-standards track seems fine. -gabriel _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Oct 7 04:52:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24311 for ; Thu, 7 Oct 2004 04:52:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFU9y-0004KI-FW for mip6-web-archive@ietf.org; Thu, 07 Oct 2004 05:02:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFTwn-0002xP-Ea; Thu, 07 Oct 2004 04:48:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFTrP-0001TW-O7 for mip6@megatron.ietf.org; Thu, 07 Oct 2004 04:42:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23774 for ; Thu, 7 Oct 2004 04:42:48 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFU14-0003k6-DW for mip6@ietf.org; Thu, 07 Oct 2004 04:52:51 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i978g6H17285; Thu, 7 Oct 2004 10:42:06 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i978g5Sj028403; Thu, 7 Oct 2004 10:42:06 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200410070842.i978g5Sj028403@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Basavaraj.Patil@nokia.com Subject: Re: [Mip6] Consensus Call: Standardizing the auth protocol [I-D: draft-ietf-mip6-auth-protocol-00.txt] In-reply-to: Your message of Wed, 06 Oct 2004 17:02:55 CDT. <697DAA22C5004B4596E033803A7CEF4403B1BF01@daebe007.americas.nokia.com> Date: Thu, 07 Oct 2004 10:42:05 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab In your previous mail you wrote: The question to the WG is: 1. Should we standardize the authentication protocol specified in I-D draft-ietf-mip6-auth-protocol-00.txt as an alternative (to the IPSec mechanism specified in RFC3775/6) means to securing the BUs and BAcks between the MN and HA. Note that this solution is an additional mechanism for doing registration with an HA and does not deprecate the currently specified solution. Yes [ ] No [X] Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Oct 7 10:05:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17499 for ; Thu, 7 Oct 2004 10:05:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFZ3J-0006vq-3s for mip6-web-archive@ietf.org; Thu, 07 Oct 2004 10:15:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFYp4-0000s3-E5; Thu, 07 Oct 2004 10:00:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFYZU-0006Hf-Vg for mip6@megatron.ietf.org; Thu, 07 Oct 2004 09:44:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16155 for ; Thu, 7 Oct 2004 09:44:38 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFYjB-0005Vp-Ol for mip6@ietf.org; Thu, 07 Oct 2004 09:54:43 -0400 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i97DXJ016001; Thu, 7 Oct 2004 09:33:19 -0400 (EDT) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Oct 2004 09:33:19 -0400 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E601F88FBC@zrc2hxm2.corp.nortel.com> From: "Mohamed Khalil" To: "'Basavaraj.Patil@nokia.com'" , mip6@ietf.org Subject: RE: [Mip6] Consensus Call: Standardizing the auth protocol [I-D:d raft-ietf-mip6-auth-protocol-00.txt] Date: Thu, 7 Oct 2004 09:33:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.5 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1287352396==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 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. --===============1287352396== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4AC72.26A5AE46" 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_01C4AC72.26A5AE46 Content-Type: text/plain -----Original Message----- From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On Behalf Of Basavaraj.Patil@nokia.com Sent: Wednesday, October 06, 2004 5:03 PM To: mip6@ietf.org Subject: [Mip6] Consensus Call: Standardizing the auth protocol [I-D:draft-ietf-mip6-auth-protocol-00.txt] This is a consensus call to the WG on the issue of standardizing the authentication-data-suboption mechanism for performing a binding between the MN and HA. The issue has been discussed on the WG mailing list over the last few weeks. The I-D (draft-patil-mip6-whyauthdataoption-00.txt) has captured some of the arguments, but there are several others that have been made on the list as well. A summary of the discussion was sent out earlier and is captured in : http://www1.ietf.org/mail-archive/web/mip6/current/msg01690.html The proposal here (in brief) is to standardize a mechanism specified in I-D draft-ietf-mip6-auth-protocol-00.txt for performing MIP6 registration with a home agent. RFC3775 specifies the use of IPsec to secure the binding update/ACK messages between the MN and HA. The auth-protocol mechanism relies on the use of an authentication-data-suboption and does not require the MN-HA to establish an IPsec SA. (For the discussion that has ensued so far, please refer to the MIP6 ML archives) The question to the WG is: 1. Should we standardize the authentication protocol specified in I-D draft-ietf-mip6-auth-protocol-00.txt as an alternative (to the IPSec mechanism specified in RFC3775/6) means to securing the BUs and BAcks between the MN and HA. Note that this solution is an additional mechanism for doing registration with an HA and does not deprecate the currently specified solution. Yes [y] No [ ] The consensus call will close on October 12th, 2004. -Chairs _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 ------_=_NextPart_001_01C4AC72.26A5AE46 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Mip6] Consensus Call: Standardizing the auth protocol = [I-D:draft-ietf-mip6-auth-protocol-00.txt]

-----Original Message-----
From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] = On Behalf Of Basavaraj.Patil@nokia.com
Sent: Wednesday, October 06, 2004 5:03 PM
To: mip6@ietf.org
Subject: [Mip6] Consensus Call: Standardizing the = auth protocol [I-D:draft-ietf-mip6-auth-protocol-00.txt]



This is a consensus call to the WG on the issue of = standardizing the authentication-data-suboption mechanism for = performing a binding between the MN and HA. The issue has been = discussed on the WG mailing list over the last few weeks. The = I-D

(draft-patil-mip6-whyauthdataoption-00.txt) has = captured some of the arguments, but there are several others that have = been made on the list as well. A summary of the discussion was sent out = earlier and is captured in : http://www1.ietf.org/mail-archive/web/mip6/current/msg= 01690.html

The proposal here (in brief) is to standardize a = mechanism specified in I-D draft-ietf-mip6-auth-protocol-00.txt for = performing MIP6 registration with a home agent. RFC3775 specifies the = use of IPsec to secure the binding update/ACK messages between the MN = and HA. The auth-protocol mechanism relies on the use of an = authentication-data-suboption and does not require the MN-HA to = establish an IPsec SA. 

(For the discussion that has ensued so far, please = refer to the MIP6 ML archives)

The question to the WG is:

1. Should we standardize the authentication protocol = specified in I-D
   draft-ietf-mip6-auth-protocol-00.txt as = an alternative (to the
   IPSec mechanism specified in RFC3775/6) = means to securing the BUs
   and BAcks between the MN and HA. Note = that this solution is an
   additional mechanism for doing = registration with an HA and does not
   deprecate the currently specified = solution.

   Yes       = [y]
   No        = [ ]


The consensus call will close on October 12th, = 2004.

-Chairs

_______________________________________________
Mip6 mailing list
Mip6@ietf.org
https://www1.ietf.org/mailman/listinfo/mip6=

------_=_NextPart_001_01C4AC72.26A5AE46-- --===============1287352396== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1287352396==-- From mip6-bounces@ietf.org Thu Oct 7 11:43:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28074 for ; Thu, 7 Oct 2004 11:43:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFaaB-0004gS-R5 for mip6-web-archive@ietf.org; Thu, 07 Oct 2004 11:53:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFaMR-0003tD-3Q; Thu, 07 Oct 2004 11:39:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFa3K-0008Hl-UR for mip6@megatron.ietf.org; Thu, 07 Oct 2004 11:19:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26211 for ; Thu, 7 Oct 2004 11:19:32 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFaD4-0003Wj-2v for mip6@ietf.org; Thu, 07 Oct 2004 11:29:38 -0400 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i97FIxu12075; Thu, 7 Oct 2004 11:18:59 -0400 (EDT) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Oct 2004 11:18:59 -0400 Message-ID: <591B780D9676844E8A704B5B013FFE92032F194F@zrc2hxm1.corp.nortel.com> From: "Kuntal Chowdhury" To: Basavaraj.Patil@nokia.com, mip6@ietf.org Subject: RE: [Mip6] Consensus Call: Standardizing the auth protocol [I-D:d raft-ietf-mip6-auth-protocol-00.txt] Date: Thu, 7 Oct 2004 11:18:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a I vote YES. -Kuntal >-----Original Message----- >From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On >Behalf Of Basavaraj.Patil@nokia.com >Sent: Wednesday, October 06, 2004 5:03 PM >To: mip6@ietf.org >Subject: [Mip6] Consensus Call: Standardizing the auth >protocol [I-D:draft-ietf-mip6-auth-protocol-00.txt] > > > >This is a consensus call to the WG on the issue of >standardizing the authentication-data-suboption mechanism for >performing a binding between the MN and HA. The issue has been >discussed on the WG mailing list over the last few weeks. The I-D >(draft-patil-mip6-whyauthdataoption-00.txt) has captured some >of the arguments, but there are several others that have been >made on the list as well. A summary of the discussion was sent >out earlier and is captured in : >http://www1.ietf.org/mail-archive/web/mip6/current/msg01690.htm l The proposal here (in brief) is to standardize a mechanism specified in I-D draft-ietf-mip6-auth-protocol-00.txt for performing MIP6 registration with a home agent. RFC3775 specifies the use of IPsec to secure the binding update/ACK messages between the MN and HA. The auth-protocol mechanism relies on the use of an authentication-data-suboption and does not require the MN-HA to establish an IPsec SA. (For the discussion that has ensued so far, please refer to the MIP6 ML archives) The question to the WG is: 1. Should we standardize the authentication protocol specified in I-D draft-ietf-mip6-auth-protocol-00.txt as an alternative (to the IPSec mechanism specified in RFC3775/6) means to securing the BUs and BAcks between the MN and HA. Note that this solution is an additional mechanism for doing registration with an HA and does not deprecate the currently specified solution. Yes [ ] No [ ] The consensus call will close on October 12th, 2004. -Chairs _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Oct 7 12:56:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04376 for ; Thu, 7 Oct 2004 12:56:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFbiw-0001D7-3X for mip6-web-archive@ietf.org; Thu, 07 Oct 2004 13:06:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFbQX-0006Xq-Ks; Thu, 07 Oct 2004 12:47:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFbOg-00063K-P5 for mip6@megatron.ietf.org; Thu, 07 Oct 2004 12:45:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03549 for ; Thu, 7 Oct 2004 12:45:39 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFbYP-0000Qc-Gd for mip6@ietf.org; Thu, 07 Oct 2004 12:55:46 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 07 Oct 2004 09:53:02 -0700 X-BrightmailFiltered: true Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i97Gj6EG016612; Thu, 7 Oct 2004 09:45:07 -0700 (PDT) Received: from cisco.com (dhcp-128-107-163-176.cisco.com [128.107.163.176]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id AXU66711; Thu, 7 Oct 2004 09:47:37 -0700 (PDT) Message-ID: <41657291.7010503@cisco.com> Date: Thu, 07 Oct 2004 09:45:05 -0700 From: Alpesh User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com Subject: Re: [Mip6] Consensus Call: Standardizing the auth protocol [I-D: draft-ietf-mip6-auth-protocol-00.txt] References: <697DAA22C5004B4596E033803A7CEF4403B1BF01@daebe007.americas.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit My vote is YES for the draft. -a Basavaraj.Patil@nokia.com wrote: >This is a consensus call to the WG on the issue of standardizing the >authentication-data-suboption mechanism for performing a binding between the >MN and HA. The issue has been discussed on the WG mailing list over >the last few weeks. The I-D >(draft-patil-mip6-whyauthdataoption-00.txt) has captured some of the >arguments, but there are several others that have been made on the >list as well. A summary of the discussion was sent out earlier and is >captured in : >http://www1.ietf.org/mail-archive/web/mip6/current/msg01690.html > >The proposal here (in brief) is to standardize a mechanism specified >in I-D draft-ietf-mip6-auth-protocol-00.txt for performing MIP6 >registration with a home agent. RFC3775 specifies the use of IPsec to >secure the binding update/ACK messages between the MN and HA. The >auth-protocol mechanism relies on the use of an >authentication-data-suboption and does not require the MN-HA to >establish an IPsec SA. >(For the discussion that has ensued so far, please refer to the MIP6 >ML archives) > >The question to the WG is: > >1. Should we standardize the authentication protocol specified in I-D > draft-ietf-mip6-auth-protocol-00.txt as an alternative (to the > IPSec mechanism specified in RFC3775/6) means to securing the BUs > and BAcks between the MN and HA. Note that this solution is an > additional mechanism for doing registration with an HA and does not > deprecate the currently specified solution. > > Yes [ ] > No [ ] > > >The consensus call will close on October 12th, 2004. > >-Chairs > >_______________________________________________ >Mip6 mailing list >Mip6@ietf.org >https://www1.ietf.org/mailman/listinfo/mip6 > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Oct 7 13:10:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05706 for ; Thu, 7 Oct 2004 13:10:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFbwB-00027L-Sy for mip6-web-archive@ietf.org; Thu, 07 Oct 2004 13:20:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFbjL-0002jA-4g; Thu, 07 Oct 2004 13:07:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFbdd-0001Ul-Dh for mip6@megatron.ietf.org; Thu, 07 Oct 2004 13:01:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04974 for ; Thu, 7 Oct 2004 13:01:06 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFbnM-0001Vb-Cs for mip6@ietf.org; Thu, 07 Oct 2004 13:11:13 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 07 Oct 2004 19:11:53 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i97H0PVG014217; Thu, 7 Oct 2004 19:00:33 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 7 Oct 2004 19:00:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Consensus Call: Standardizing the auth protocol [I-D:draft-ietf-mip6-auth-protocol-00.txt] Date: Thu, 7 Oct 2004 19:00:21 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC2BFC19@xmb-ams-337.emea.cisco.com> Thread-Topic: [Mip6] Consensus Call: Standardizing the auth protocol [I-D:draft-ietf-mip6-auth-protocol-00.txt] Thread-Index: AcSr8DqS6Ympo/12TUmUacaxgh/VgAAnuH5A From: "Pascal Thubert \(pthubert\)" To: , X-OriginalArrivalTime: 07 Oct 2004 17:00:26.0464 (UTC) FILETIME=[246CFE00:01C4AC8F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: quoted-printable I vote YES > -----Original Message----- > From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On Behalf Of > Basavaraj.Patil@nokia.com > Sent: jeudi 7 octobre 2004 00:03 > To: mip6@ietf.org > Subject: [Mip6] Consensus Call: Standardizing the auth protocol [I-D:draft-ietf-mip6-auth- > protocol-00.txt] >=20 >=20 > This is a consensus call to the WG on the issue of standardizing the > authentication-data-suboption mechanism for performing a binding between the > MN and HA. The issue has been discussed on the WG mailing list over > the last few weeks. The I-D > (draft-patil-mip6-whyauthdataoption-00.txt) has captured some of the > arguments, but there are several others that have been made on the > list as well. A summary of the discussion was sent out earlier and is > captured in : > http://www1.ietf.org/mail-archive/web/mip6/current/msg01690.html >=20 > The proposal here (in brief) is to standardize a mechanism specified > in I-D draft-ietf-mip6-auth-protocol-00.txt for performing MIP6 > registration with a home agent. RFC3775 specifies the use of IPsec to > secure the binding update/ACK messages between the MN and HA. The > auth-protocol mechanism relies on the use of an > authentication-data-suboption and does not require the MN-HA to > establish an IPsec SA. > (For the discussion that has ensued so far, please refer to the MIP6 > ML archives) >=20 > The question to the WG is: >=20 > 1. Should we standardize the authentication protocol specified in I-D > draft-ietf-mip6-auth-protocol-00.txt as an alternative (to the > IPSec mechanism specified in RFC3775/6) means to securing the BUs > and BAcks between the MN and HA. Note that this solution is an > additional mechanism for doing registration with an HA and does not > deprecate the currently specified solution. >=20 > Yes [ ] > No [ ] >=20 >=20 > The consensus call will close on October 12th, 2004. >=20 > -Chairs >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Oct 7 14:39:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10166 for ; Thu, 7 Oct 2004 14:39:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFdL3-00011P-5h for mip6-web-archive@ietf.org; Thu, 07 Oct 2004 14:50:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFd0F-0002X3-Cm; Thu, 07 Oct 2004 14:28:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFctO-0001DZ-6o for mip6@megatron.ietf.org; Thu, 07 Oct 2004 14:21:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08961 for ; Thu, 7 Oct 2004 14:21:24 -0400 (EDT) Received: from mail-res.bigfish.com ([63.161.60.61] helo=mail2-res-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFcQ0-0003uw-6y for mip6@ietf.org; Thu, 07 Oct 2004 13:51:08 -0400 Received: from mail2-res.bigfish.com (localhost.localdomain [127.0.0.1]) by mail2-res-R.bigfish.com (Postfix) with ESMTP id 7885B43779E; Thu, 7 Oct 2004 17:40:17 +0000 (UCT) X-BigFish: VC Received: by mail2-res.bigfish.com (MessageSwitch) id 1097170817476980_22297; Thu, 7 Oct 2004 17:40:17 +0000 (UCT) Received: from smtpgw6.it.sprintspectrum.com (smtpgw6.sprintspectrum.com [207.40.188.14]) by mail2-res.bigfish.com (Postfix) with ESMTP id 45C4E437713; Thu, 7 Oct 2004 17:40:17 +0000 (UCT) Received: from mailhost.sprintspectrum.com (smtpgw8.it.sprintspectrum.com [207.40.65.56]) by smtpgw6.it.sprintspectrum.com (8.12.11.Beta0/8.12.8) with ESMTP id i97HeBZj023004; Thu, 7 Oct 2004 12:40:11 -0500 (CDT) Received: from PDAWG02A.corp.sprint.com (PDAWG02A.corp.sprint.com [10.184.134.80]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i97HeB019164; Thu, 7 Oct 2004 12:40:11 -0500 (CDT) Received: from pkdwb01c.ad.sprint.com ([10.185.12.21]) by PDAWG02A.corp.sprint.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 7 Oct 2004 12:39:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Consensus Call: Standardizing the auth protocol [I-D:draft-ietf-mip6-auth-protocol-00.txt] Date: Thu, 7 Oct 2004 12:39:58 -0500 Message-ID: <070C23AE468F5D49885DEFE432ED4B761F2C71@PKDWB01C.ad.sprint.com> Thread-Topic: [Mip6] Consensus Call: Standardizing the auth protocol [I-D:draft-ietf-mip6-auth-protocol-00.txt] Thread-Index: AcSr8DqS6Ympo/12TUmUacaxgh/VgAAo/qWg From: "Hirschman, Brent B [NTK]" To: X-OriginalArrivalTime: 07 Oct 2004 17:39:59.0407 (UTC) FILETIME=[AACF5BF0:01C4AC94] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: quoted-printable I support standardization of this draft!! The question to the WG is: 1. Should we standardize the authentication protocol specified in I-D draft-ietf-mip6-auth-protocol-00.txt as an alternative (to the IPSec mechanism specified in RFC3775/6) means to securing the BUs and BAcks between the MN and HA. Note that this solution is an additional mechanism for doing registration with an HA and does not deprecate the currently specified solution.=20 Yes [XXX ] No [ ] Brent Hirschman Principal Member of Technical Staff Industry Standards KSOPHD0504-5D178 6220 Sprint Parkway, Overland Park, KS 66251 Voice 913-794-4271 FAX 913-794-0420 PCS 913-593-6221 Brent.Hirschman@mail.sprint.com _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Oct 7 14:57:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11131 for ; Thu, 7 Oct 2004 14:57:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFdc3-0002Bp-0N for mip6-web-archive@ietf.org; Thu, 07 Oct 2004 15:07:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFdDg-0006CC-A5; Thu, 07 Oct 2004 14:42:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFBcK-000445-Vh for mip6@megatron.ietf.org; Wed, 06 Oct 2004 09:14:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22250 for ; Wed, 6 Oct 2004 09:14:02 -0400 (EDT) Received: from neon.tcs.hut.fi ([130.233.215.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFBlp-000112-Jy for mip6@ietf.org; Wed, 06 Oct 2004 09:23:54 -0400 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id DDDEB8001BC; Wed, 6 Oct 2004 16:13:31 +0300 (EEST) Date: Wed, 6 Oct 2004 16:13:31 +0300 (EEST) From: Ville Nuorvala To: samita.chakrabarti@sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-Mailman-Approved-At: Thu, 07 Oct 2004 14:42:24 -0400 Cc: mip6@ietf.org Subject: [Mip6] Comment on draft-ietf-mip6-mipext-advapi-03.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Hi Samita, this is just a minor issue, but looking at struct ip6_opt_home_address and struct ip6_rthdr2, I notice notice the home address field is defined as a uint8_t array in the first one and a struct in6_addr in the latter one. Why not also define ip6oha_addr as an in6_addr? Regards, Ville -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Oct 7 14:57:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11199 for ; Thu, 7 Oct 2004 14:57:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFdcN-0002D4-Qd for mip6-web-archive@ietf.org; Thu, 07 Oct 2004 15:08:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFdDh-0006CL-Og; Thu, 07 Oct 2004 14:42:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFc4v-0006c4-VB for mip6@megatron.ietf.org; Thu, 07 Oct 2004 13:29:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07026 for ; Thu, 7 Oct 2004 13:29:18 -0400 (EDT) Received: from ns.starentnetworks.com ([12.38.223.195] helo=starentnetworks.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CFcEg-0003CM-3f for mip6@ietf.org; Thu, 07 Oct 2004 13:39:26 -0400 Received: (qmail 12268 invoked from network); 7 Oct 2004 17:17:19 -0000 Received: from ames.starentnetworks.com (12.33.235.15) by mail.starentnetworks.com with SMTP; 7 Oct 2004 17:17:19 -0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 7 Oct 2004 13:28:08 -0400 Message-ID: <8A16DAD84432534FBFC19FD92B50512FE77875@ames.starentnetworks.com> Thread-Topic: draft-ietf-mip6-auth-protocol-00.txt Thread-Index: AcSskwMGn6MOLmeLSqGNQ2YlqENDzw== From: "Puthiyandyil, Sanil" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-Mailman-Approved-At: Thu, 07 Oct 2004 14:42:25 -0400 Cc: mip6@ietf.org Subject: [Mip6] draft-ietf-mip6-auth-protocol-00.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0942880896==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 This is a multi-part message in MIME format. --===============0942880896== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4AC93.03502692" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4AC93.03502692 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I vote YES for draft-ietf-mip6-auth-protocol-00.txt =20 Sanil Puthiyandyil, Starent Networks 978-851-1134 ------_=_NextPart_001_01C4AC93.03502692 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I vote YES for=20 draft-ietf-mip6-auth-protocol-00.txt
 
Sanil=20 Puthiyandyil,
Starent=20 Networks
978-851-1134
------_=_NextPart_001_01C4AC93.03502692-- --===============0942880896== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0942880896==-- From mip6-bounces@ietf.org Thu Oct 7 14:58:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11229 for ; Thu, 7 Oct 2004 14:58:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFdcf-0002DR-Km for mip6-web-archive@ietf.org; Thu, 07 Oct 2004 15:08:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFdDk-0006CT-8u; Thu, 07 Oct 2004 14:42:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFcsl-00017j-0o for mip6@megatron.ietf.org; Thu, 07 Oct 2004 14:20:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08395 for ; Thu, 7 Oct 2004 14:20:46 -0400 (EDT) Received: from mail-kan.bigfish.com ([63.161.60.29] helo=mail27-R-kan.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFcke-0005dT-7y for mip6@ietf.org; Thu, 07 Oct 2004 14:12:31 -0400 Received: from mail27-kan.bigfish.com (localhost.localdomain [127.0.0.1]) by mail27-R-kan.bigfish.com (Postfix) with ESMTP id B89BF6DF44; Thu, 7 Oct 2004 18:01:38 +0000 (UCT) X-BigFish: VC Received: by mail27-kan (MessageSwitch) id 1097172070241929_18053; Thu, 7 Oct 2004 18:01:10 +0000 (UCT) Received: from smtpgw5.sprintspectrum.com (smtpgw5.sprintspectrum.com [207.40.188.13]) by mail27-kan.bigfish.com (Postfix) with ESMTP id 21C8F6E136; Thu, 7 Oct 2004 18:01:10 +0000 (UCT) Received: from mailhost.sprintspectrum.com (smtpgw7.it.sprintspectrum.com [207.40.65.55]) by smtpgw5.sprintspectrum.com (8.12.10/8.12.8) with ESMTP id i97I13aY018449; Thu, 7 Oct 2004 13:01:03 -0500 (CDT) Received: from PDAWG01A.corp.sprint.com (PDAWG01A.corp.sprint.com [10.184.134.78]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i97I13C15229; Thu, 7 Oct 2004 13:01:03 -0500 (CDT) Received: from pkdwb04c.ad.sprint.com ([10.185.12.36]) by PDAWG01A.corp.sprint.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 7 Oct 2004 13:01:03 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Consensus Call: Standardizing the auth protocol [I-D:draft-ietf-mip6-auth-protocol-00.txt] Date: Thu, 7 Oct 2004 13:00:54 -0500 Message-ID: <59BFA9886BBACC439D7875FEA85C9AB7062929F4@PKDWB04C.ad.sprint.com> Thread-Topic: [Mip6] Consensus Call: Standardizing the auth protocol [I-D:draft-ietf-mip6-auth-protocol-00.txt] Thread-Index: AcSskll/9W7TW+1SToyhyTDVwGR9cQABTVgg From: "Lipford, Mark A [NTK]" To: "Alpesh" , X-OriginalArrivalTime: 07 Oct 2004 18:01:03.0006 (UTC) FILETIME=[9BF943E0:01C4AC97] X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 07 Oct 2004 14:42:25 -0400 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: quoted-printable I agree, a YES for me too. Mark A. Lipford=20 Manager, Sprint Industry Standards=20 6220 Sprint Parkway (Eisenhower C)=20 Mailstop: KSOPHD0504-5D128=20 Overland Park, KS 66251-6118=20 (913) 794-3764 (office)=20 (913) 794-0420 (fax)=20 (913) 579-2319 (mobile)=20 Mark.A.Lipford@mail.sprint.com=20 -----Original Message----- From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On Behalf Of Alpesh Sent: Thursday, October 07, 2004 11:45 AM To: Basavaraj.Patil@nokia.com Cc: mip6@ietf.org Subject: Re: [Mip6] Consensus Call: Standardizing the auth protocol [I-D:draft-ietf-mip6-auth-protocol-00.txt] My vote is YES for the draft. -a Basavaraj.Patil@nokia.com wrote: >This is a consensus call to the WG on the issue of standardizing the >authentication-data-suboption mechanism for performing a binding between the >MN and HA. The issue has been discussed on the WG mailing list over >the last few weeks. The I-D >(draft-patil-mip6-whyauthdataoption-00.txt) has captured some of the >arguments, but there are several others that have been made on the >list as well. A summary of the discussion was sent out earlier and is >captured in : >http://www1.ietf.org/mail-archive/web/mip6/current/msg01690.html > >The proposal here (in brief) is to standardize a mechanism specified >in I-D draft-ietf-mip6-auth-protocol-00.txt for performing MIP6 >registration with a home agent. RFC3775 specifies the use of IPsec to >secure the binding update/ACK messages between the MN and HA. The >auth-protocol mechanism relies on the use of an >authentication-data-suboption and does not require the MN-HA to >establish an IPsec SA. =20 >(For the discussion that has ensued so far, please refer to the MIP6 >ML archives) > >The question to the WG is: > >1. Should we standardize the authentication protocol specified in I-D > draft-ietf-mip6-auth-protocol-00.txt as an alternative (to the > IPSec mechanism specified in RFC3775/6) means to securing the BUs > and BAcks between the MN and HA. Note that this solution is an > additional mechanism for doing registration with an HA and does not > deprecate the currently specified solution.=20 > > Yes [ ] > No [ ] > > >The consensus call will close on October 12th, 2004. > >-Chairs > >_______________________________________________ >Mip6 mailing list >Mip6@ietf.org >https://www1.ietf.org/mailman/listinfo/mip6 > > =20 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Oct 7 14:58:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11254 for ; Thu, 7 Oct 2004 14:58:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFdct-0002Dq-V8 for mip6-web-archive@ietf.org; Thu, 07 Oct 2004 15:08:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFdDk-0006Ca-RU; Thu, 07 Oct 2004 14:42:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFct2-00019i-0T for mip6@megatron.ietf.org; Thu, 07 Oct 2004 14:21:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08625 for ; Thu, 7 Oct 2004 14:21:01 -0400 (EDT) Received: from ns.starentnetworks.com ([12.38.223.195] helo=starentnetworks.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CFcax-0004y4-Hc for mip6@ietf.org; Thu, 07 Oct 2004 14:02:28 -0400 Received: (qmail 5601 invoked from network); 7 Oct 2004 17:40:06 -0000 Received: from ames.starentnetworks.com (12.33.235.15) by mail.starentnetworks.com with SMTP; 7 Oct 2004 17:40:06 -0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Consensus Call: Standardizing the auth protocol [I-D:draft-ietf-mip6-auth-protocol-00.txt] Date: Thu, 7 Oct 2004 13:50:56 -0400 Message-ID: <8A16DAD84432534FBFC19FD92B50512F0D3049@ames.starentnetworks.com> Thread-Topic: RE: [Mip6] Consensus Call: Standardizing the auth protocol [I-D:draft-ietf-mip6-auth-protocol-00.txt] Thread-Index: AcSsljJCPexuDnVqSB6Zv2Uocmv22w== From: "Navali, Jay" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 07 Oct 2004 14:42:25 -0400 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable Hi, I vote YES to standardize the draft-ietf-mip6-auth-protocol-00.txt. Thanks, Jay Navali Starent Networks >-----Original Message----- >From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On=20 >Behalf Of Basavaraj.Patil@nokia.com >Sent: Wednesday, October 06, 2004 5:03 PM >To: mip6@ietf.org >Subject: [Mip6] Consensus Call: Standardizing the auth=20 >protocol [I-D:draft-ietf-mip6-auth-protocol-00.txt] > > > >This is a consensus call to the WG on the issue of=20 >standardizing the authentication-data-suboption mechanism for=20 >performing a binding between the MN and HA. The issue has been=20 >discussed on the WG mailing list over the last few weeks. The I-D >(draft-patil-mip6-whyauthdataoption-00.txt) has captured some=20 >of the arguments, but there are several others that have been=20 >made on the list as well. A summary of the discussion was sent=20 >out earlier and is captured in :=20 >http://www1.ietf.org/mail-archive/web/mip6/current/msg01690.htm l The proposal here (in brief) is to standardize a mechanism specified in = I-D draft-ietf-mip6-auth-protocol-00.txt for performing MIP6 registration = with a home agent. RFC3775 specifies the use of IPsec to secure the binding update/ACK messages between the MN and HA. The auth-protocol mechanism relies on the use of an authentication-data-suboption and does not = require the MN-HA to establish an IPsec SA. =20 (For the discussion that has ensued so far, please refer to the MIP6 ML archives) The question to the WG is: 1. Should we standardize the authentication protocol specified in I-D draft-ietf-mip6-auth-protocol-00.txt as an alternative (to the IPSec mechanism specified in RFC3775/6) means to securing the BUs and BAcks between the MN and HA. Note that this solution is an additional mechanism for doing registration with an HA and does not deprecate the currently specified solution.=20 Yes [ ] No [ ] The consensus call will close on October 12th, 2004. -Chairs _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Oct 7 15:16:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13587 for ; Thu, 7 Oct 2004 15:16:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFdty-0003YW-3F for mip6-web-archive@ietf.org; Thu, 07 Oct 2004 15:26:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFdXx-0006fU-NO; Thu, 07 Oct 2004 15:03:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFdUx-0003dT-6K for mip6@megatron.ietf.org; Thu, 07 Oct 2004 15:00:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11479 for ; Thu, 7 Oct 2004 15:00:17 -0400 (EDT) Received: from email.seas.smu.edu ([129.119.113.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFdeh-0002Qe-2b for mip6@ietf.org; Thu, 07 Oct 2004 15:10:24 -0400 Received: from sic300dpc1 (sic-300d-pc1.seas.smu.edu [129.119.101.37]) by email.engr.smu.edu (Postfix) with ESMTP id 411F426B76; Thu, 7 Oct 2004 14:00:11 -0500 (CDT) From: "Jahanzeb Faizan" To: , Subject: RE: [Mip6] Consensus Call: Standardizing the auth protocol[I-D:draft-ietf-mip6-auth-protocol-00.txt] Date: Thu, 7 Oct 2004 14:00:11 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcSr8DqS6Ympo/12TUmUacaxgh/VgAAnuH5AAAQn+LA= In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC2BFC19@xmb-ams-337.emea.cisco.com> Message-Id: <20041007190011.411F426B76@email.engr.smu.edu> X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit I vote YES. Jahanzeb Faizan > -----Original Message----- > From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On Behalf Of > Basavaraj.Patil@nokia.com > Sent: jeudi 7 octobre 2004 00:03 > To: mip6@ietf.org > Subject: [Mip6] Consensus Call: Standardizing the auth protocol [I-D:draft-ietf-mip6-auth- > protocol-00.txt] > > > This is a consensus call to the WG on the issue of standardizing the > authentication-data-suboption mechanism for performing a binding between the > MN and HA. The issue has been discussed on the WG mailing list over > the last few weeks. The I-D > (draft-patil-mip6-whyauthdataoption-00.txt) has captured some of the > arguments, but there are several others that have been made on the > list as well. A summary of the discussion was sent out earlier and is > captured in : > http://www1.ietf.org/mail-archive/web/mip6/current/msg01690.html > > The proposal here (in brief) is to standardize a mechanism specified > in I-D draft-ietf-mip6-auth-protocol-00.txt for performing MIP6 > registration with a home agent. RFC3775 specifies the use of IPsec to > secure the binding update/ACK messages between the MN and HA. The > auth-protocol mechanism relies on the use of an > authentication-data-suboption and does not require the MN-HA to > establish an IPsec SA. > (For the discussion that has ensued so far, please refer to the MIP6 > ML archives) > > The question to the WG is: > > 1. Should we standardize the authentication protocol specified in I-D > draft-ietf-mip6-auth-protocol-00.txt as an alternative (to the > IPSec mechanism specified in RFC3775/6) means to securing the BUs > and BAcks between the MN and HA. Note that this solution is an > additional mechanism for doing registration with an HA and does not > deprecate the currently specified solution. > > Yes [ ] > No [ ] > > > The consensus call will close on October 12th, 2004. > > -Chairs > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Oct 7 15:29:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15361 for ; Thu, 7 Oct 2004 15:29:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFe6V-0004D8-FQ for mip6-web-archive@ietf.org; Thu, 07 Oct 2004 15:39:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFdlr-000785-84; Thu, 07 Oct 2004 15:17:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFdZI-0007sA-El for mip6@megatron.ietf.org; Thu, 07 Oct 2004 15:04:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11752 for ; Thu, 7 Oct 2004 15:04:46 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFdj0-0002dc-Fy for mip6@ietf.org; Thu, 07 Oct 2004 15:14:53 -0400 Received: from jurassic.eng.sun.com ([129.146.87.31]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i97J4h35005942; Thu, 7 Oct 2004 12:04:43 -0700 (PDT) Received: from shubho (shubho.SFBay.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.13.1+Sun/8.13.1) with SMTP id i97J4gGW178539; Thu, 7 Oct 2004 12:04:42 -0700 (PDT) Message-Id: <200410071904.i97J4gGW178539@jurassic.eng.sun.com> Date: Thu, 7 Oct 2004 12:05:40 -0700 (PDT) From: Samita Chakrabarti To: vnuorval@rhea.tcs.hut.fi MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: RTL3aZb0tY1xj4+AkHu8cQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_53 SunOS 5.10 sun4u sparc X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: mip6@ietf.org Subject: [Mip6] Re: Comment on draft-ietf-mip6-mipext-advapi-03.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Samita Chakrabarti List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Hi Ville, Thanks for reviewing the API draft. > > this is just a minor issue, but looking at struct ip6_opt_home_address and > struct ip6_rthdr2, I notice notice the home address field is defined as a > uint8_t array in the first one and a struct in6_addr in the latter one. > Why not also define ip6oha_addr as an in6_addr? > I think it was brought up before at last Cthon meeting. Originally the home-address was defined as 16 uint8 quantity because that would be easy to copy byte by byte in the destination option without any alignment. In ip6_rthdr2, home-address always starts from the 4n byte boundary so in6_addr was used as in6_addr might be system dependent. Example (rfc2553): struct in6_addr { union { uint8_t _S6_u8[16]; uint32_t _S6_u32[4]; uint64_t _S6_u64[2]; } _S6_un; }; However, in RFC3775, the alignment requirement for home-address option is 8n+6 - hence it requires home-address to start from a 4byte boundary as well in the home-address option. At the time of last discussion, we decided to keep the way it is, i.e. uint8 ip6oha_addr[16]; -Samita _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Oct 7 21:07:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22254 for ; Thu, 7 Oct 2004 21:07:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFjNh-0003Fh-5n for mip6-web-archive@ietf.org; Thu, 07 Oct 2004 21:17:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFjCB-0003wU-09; Thu, 07 Oct 2004 21:05:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFjBU-0003lu-MG for mip6@megatron.ietf.org; Thu, 07 Oct 2004 21:04:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21958 for ; Thu, 7 Oct 2004 21:04:34 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFjLI-00033L-NE for mip6@ietf.org; Thu, 07 Oct 2004 21:14:45 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i980aYZ03220; Thu, 7 Oct 2004 17:36:34 -0700 X-mProtect: <200410080036> Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdQnzZUF; Thu, 07 Oct 2004 17:36:33 PDT Message-ID: <4165E7D2.A1A37B3A@iprg.nokia.com> Date: Thu, 07 Oct 2004 18:05:22 -0700 From: "Charles E.Perkins" 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: Basavaraj.Patil@nokia.com Subject: Re: [Mip6] Consensus Call: Standardizing the auth protocol [I-D:draft-ietf-mip6-auth-protocol-00.txt] References: <697DAA22C5004B4596E033803A7CEF4403B1BF01@daebe007.americas.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Hello Basavaraj, I vote YES to have such an authentication mechanism. I am interpreting this NOT as last call on the specific draft, but as a way to determine whether such a feature is needed. Regards, Charlie P. Basavaraj.Patil@nokia.com wrote: > > This is a consensus call to the WG on the issue of standardizing the > authentication-data-suboption mechanism for performing a binding between the > MN and HA. The issue has been discussed on the WG mailing list over > the last few weeks. The I-D > (draft-patil-mip6-whyauthdataoption-00.txt) has captured some of the > arguments, but there are several others that have been made on the > list as well. A summary of the discussion was sent out earlier and is > captured in : > http://www1.ietf.org/mail-archive/web/mip6/current/msg01690.html > > The proposal here (in brief) is to standardize a mechanism specified > in I-D draft-ietf-mip6-auth-protocol-00.txt for performing MIP6 > registration with a home agent. RFC3775 specifies the use of IPsec to > secure the binding update/ACK messages between the MN and HA. The > auth-protocol mechanism relies on the use of an > authentication-data-suboption and does not require the MN-HA to > establish an IPsec SA. > (For the discussion that has ensued so far, please refer to the MIP6 > ML archives) > > The question to the WG is: > > 1. Should we standardize the authentication protocol specified in I-D > draft-ietf-mip6-auth-protocol-00.txt as an alternative (to the > IPSec mechanism specified in RFC3775/6) means to securing the BUs > and BAcks between the MN and HA. Note that this solution is an > additional mechanism for doing registration with an HA and does not > deprecate the currently specified solution. > > Yes [ ] > No [ ] > > The consensus call will close on October 12th, 2004. > > -Chairs > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Oct 8 01:22:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08779 for ; Fri, 8 Oct 2004 01:22:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFnMr-0006K0-Uh for mip6-web-archive@ietf.org; Fri, 08 Oct 2004 01:32:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFnBV-0002Yw-2w; Fri, 08 Oct 2004 01:20:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFnAl-0002Pb-Ld for mip6@megatron.ietf.org; Fri, 08 Oct 2004 01:20:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08604 for ; Fri, 8 Oct 2004 01:20:07 -0400 (EDT) Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFnKc-0006Gr-CT for mip6@ietf.org; Fri, 08 Oct 2004 01:30:18 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 8 Oct 2004 01:19:32 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Consensus Call: Standardizing the auth protocol [I-D:draft-ietf-mip6-auth-protocol-00.txt] Date: Fri, 8 Oct 2004 01:19:34 -0400 Message-ID: Thread-Topic: Consensus Call: Standardizing the auth protocol [I-D:draft-ietf-mip6-auth-protocol-00.txt] Thread-Index: AcSr8DqS6Ympo/12TUmUacaxgh/VgABBhJjw From: "Soliman, Hesham" To: , X-OriginalArrivalTime: 08 Oct 2004 05:19:32.0345 (UTC) FILETIME=[64A16E90:01C4ACF6] X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: quoted-printable X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: quoted-printable I haven't seen an argument that changes my stand on this issue yet, so I'll have to go with NO. Hesham > -----Original Message----- > From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org]On=20 > Behalf Of > Basavaraj.Patil@nokia.com > Sent: Wednesday, October 06, 2004 6:03 PM > To: mip6@ietf.org > Subject: [Mip6] Consensus Call: Standardizing the auth protocol > [I-D:draft-ietf-mip6-auth-protocol-00.txt] >=20 >=20 >=20 > This is a consensus call to the WG on the issue of standardizing the > authentication-data-suboption mechanism for performing a=20 > binding between the > MN and HA. The issue has been discussed on the WG mailing list over > the last few weeks. The I-D > (draft-patil-mip6-whyauthdataoption-00.txt) has captured some of the > arguments, but there are several others that have been made on the > list as well. A summary of the discussion was sent out earlier and is > captured in : > http://www1.ietf.org/mail-archive/web/mip6/current/msg01690.html >=20 > The proposal here (in brief) is to standardize a mechanism specified > in I-D draft-ietf-mip6-auth-protocol-00.txt for performing MIP6 > registration with a home agent. RFC3775 specifies the use of IPsec to > secure the binding update/ACK messages between the MN and HA. The > auth-protocol mechanism relies on the use of an > authentication-data-suboption and does not require the MN-HA to > establish an IPsec SA. =20 > (For the discussion that has ensued so far, please refer to the MIP6 > ML archives) >=20 > The question to the WG is: >=20 > 1. Should we standardize the authentication protocol specified in I-D > draft-ietf-mip6-auth-protocol-00.txt as an alternative (to the > IPSec mechanism specified in RFC3775/6) means to securing the BUs > and BAcks between the MN and HA. Note that this solution is an > additional mechanism for doing registration with an HA=20 > and does not > deprecate the currently specified solution.=20 >=20 > Yes [ ] > No [ ] >=20 >=20 > The consensus call will close on October 12th, 2004. >=20 > -Chairs >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review or distribution by others is = strictly prohibited. If you are not the intended recipient please contact the = sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Oct 8 03:02:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29043 for ; Fri, 8 Oct 2004 03:02:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFovY-000837-6K for mip6-web-archive@ietf.org; Fri, 08 Oct 2004 03:12:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFoe7-0003fy-Ri; Fri, 08 Oct 2004 02:54:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFodE-0003UH-2g for mip6@megatron.ietf.org; Fri, 08 Oct 2004 02:53:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28715 for ; Fri, 8 Oct 2004 02:53:34 -0400 (EDT) From: juha.wiljakka@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFon4-0007uw-H6 for mip6@ietf.org; Fri, 08 Oct 2004 03:03:47 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i986rVW15594 for ; Fri, 8 Oct 2004 09:53:32 +0300 (EET DST) X-Scanned: Fri, 8 Oct 2004 09:52:31 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i986qVim012475 for ; Fri, 8 Oct 2004 09:52:31 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00r0Dvvq; Fri, 08 Oct 2004 09:52:29 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i986qMY03249 for ; Fri, 8 Oct 2004 09:52:23 +0300 (EET DST) Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 8 Oct 2004 09:52:17 +0300 Received: from esebe054.NOE.Nokia.com ([172.21.143.44]) by esebe005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 8 Oct 2004 09:52:16 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Consensus Call: Standardizing the auth protocol [I-D:draft-ietf-mip6-auth-protocol-00.txt] Date: Fri, 8 Oct 2004 09:52:16 +0300 Message-ID: <4255703385E781428653E1DEE230980D51B58E@esebe054.ntc.nokia.com> Thread-Topic: Consensus Call: Standardizing the auth protocol [I-D:draft-ietf-mip6-auth-protocol-00.txt] Thread-Index: AcSr8DqS6Ympo/12TUmUacaxgh/VgABErRYQ To: X-OriginalArrivalTime: 08 Oct 2004 06:52:16.0398 (UTC) FILETIME=[59108AE0:01C4AD03] X-Spam-Score: 0.3 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable Hi, My vote is: 1. Should we standardize the authentication protocol specified in I-D draft-ietf-mip6-auth-protocol-00.txt as an alternative (to the IPSec mechanism specified in RFC3775/6) means to securing the BUs and BAcks between the MN and HA. Note that this solution is an additional mechanism for doing registration with an HA and does not deprecate the currently specified solution.=20 Yes [X] No [ ] BR, Juha Wiljakka =20 -----Original Message----- From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org]On Behalf Of ext Basavaraj.Patil@nokia.com This is a consensus call to the WG on the issue of standardizing the authentication-data-suboption mechanism for performing a binding between = the MN and HA. The issue has been discussed on the WG mailing list over the last few weeks. The I-D (draft-patil-mip6-whyauthdataoption-00.txt) has captured some of the arguments, but there are several others that have been made on the list as well. A summary of the discussion was sent out earlier and is captured in : http://www1.ietf.org/mail-archive/web/mip6/current/msg01690.html The proposal here (in brief) is to standardize a mechanism specified in I-D draft-ietf-mip6-auth-protocol-00.txt for performing MIP6 registration with a home agent. RFC3775 specifies the use of IPsec to secure the binding update/ACK messages between the MN and HA. The auth-protocol mechanism relies on the use of an authentication-data-suboption and does not require the MN-HA to establish an IPsec SA. =20 (For the discussion that has ensued so far, please refer to the MIP6 ML archives) The question to the WG is: 1. Should we standardize the authentication protocol specified in I-D draft-ietf-mip6-auth-protocol-00.txt as an alternative (to the IPSec mechanism specified in RFC3775/6) means to securing the BUs and BAcks between the MN and HA. Note that this solution is an additional mechanism for doing registration with an HA and does not deprecate the currently specified solution.=20 Yes [ ] No [ ] The consensus call will close on October 12th, 2004. -Chairs _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Oct 8 07:25:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15425 for ; Fri, 8 Oct 2004 07:25:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFt2L-0004Ib-94 for mip6-web-archive@ietf.org; Fri, 08 Oct 2004 07:35:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFsp3-0007kS-67; Fri, 08 Oct 2004 07:22:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFslf-0007EW-14 for mip6@megatron.ietf.org; Fri, 08 Oct 2004 07:18:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15079 for ; Fri, 8 Oct 2004 07:18:32 -0400 (EDT) Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFsvY-0004Av-Lc for mip6@ietf.org; Fri, 08 Oct 2004 07:28:49 -0400 Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id E80BC89860; Fri, 8 Oct 2004 14:18:31 +0300 (EEST) Message-ID: <41667739.2020003@kolumbus.fi> Date: Fri, 08 Oct 2004 14:17:13 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com Subject: Re: [Mip6] Consensus Call: Standardizing the auth protocol [I-D: draft-ietf-mip6-auth-protocol-00.txt] References: <697DAA22C5004B4596E033803A7CEF4403B1BF01@daebe007.americas.nokia.com> In-Reply-To: <697DAA22C5004B4596E033803A7CEF4403B1BF01@daebe007.americas.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit YES, primarily on the grounds of benefits for AAA integration, dynamic addressing, etc (not to mention requirements from people who intend to use our protocols). I have some nits on the current document contents, but I presume those issues can be worked out. --Jari Basavaraj.Patil@nokia.com wrote: > 1. Should we standardize the authentication protocol specified in I-D > draft-ietf-mip6-auth-protocol-00.txt as an alternative (to the > IPSec mechanism specified in RFC3775/6) means to securing the BUs > and BAcks between the MN and HA. Note that this solution is an > additional mechanism for doing registration with an HA and does not > deprecate the currently specified solution. > > Yes [ ] > No [ ] _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Oct 8 07:57:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17293 for ; Fri, 8 Oct 2004 07:57:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFtXf-0004y8-4z for mip6-web-archive@ietf.org; Fri, 08 Oct 2004 08:08:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFtLw-00045U-Ee; Fri, 08 Oct 2004 07:56:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFtGR-00034J-PX for mip6@megatron.ietf.org; Fri, 08 Oct 2004 07:50:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16620 for ; Fri, 8 Oct 2004 07:50:22 -0400 (EDT) Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFtQJ-0004ex-K2 for mip6@ietf.org; Fri, 08 Oct 2004 08:00:38 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id i98BoIOo032724 for ; Fri, 8 Oct 2004 13:50:18 +0200 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id i98BoHfU024255 for ; Fri, 8 Oct 2004 13:50:17 +0200 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id <4BVRTCCA>; Fri, 8 Oct 2004 13:50:17 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04686835@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: mip6@ietf.org Subject: RE: [Mip6] Consensus Call: Standardizing the auth protocol [I-D: draft-ietf-mip6-auth-protocol-00.txt] Date: Fri, 8 Oct 2004 13:50:16 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 YES, BUT more flexibility with regard to the supported authentication credentials has to be included into > 1. Should we standardize the authentication protocol specified in I-D > draft-ietf-mip6-auth-protocol-00.txt as an alternative (to the > IPSec mechanism specified in RFC3775/6) means to securing the BUs > and BAcks between the MN and HA. Note that this solution is an > additional mechanism for doing registration with an HA and does not > deprecate the currently specified solution. > > Yes [ ] > No [ ] _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Oct 8 13:41:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14473 for ; Fri, 8 Oct 2004 13:41:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFyu1-000447-3Y for mip6-web-archive@ietf.org; Fri, 08 Oct 2004 13:51:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFycE-00050s-Tu; Fri, 08 Oct 2004 13:33:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFyXj-00043R-Ez for mip6@megatron.ietf.org; Fri, 08 Oct 2004 13:28:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13315 for ; Fri, 8 Oct 2004 13:28:34 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFyhf-0003kv-53 for mip6@ietf.org; Fri, 08 Oct 2004 13:38:54 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i98H0Su00499; Fri, 8 Oct 2004 10:00:28 -0700 X-mProtect: <200410081700> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (10.241.88.113, claiming to be "[10.241.88.113]") by darkstar.iprg.nokia.com smtpdvY1Axd; Fri, 08 Oct 2004 10:00:27 PDT Message-ID: <4166CE0B.8080204@iprg.nokia.com> Date: Fri, 08 Oct 2004 10:27:39 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com Subject: Re: [Mip6] Consensus Call: Standardizing the auth protocol [I-D: draft-ietf-mip6-auth-protocol-00.txt] References: <697DAA22C5004B4596E033803A7CEF4403B1BF01@daebe007.americas.nokia.com> In-Reply-To: <697DAA22C5004B4596E033803A7CEF4403B1BF01@daebe007.americas.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Yes to the concept of using a mobility option to authenticate the BU. but not the current drafts. Vijay Basavaraj.Patil@nokia.com wrote: > This is a consensus call to the WG on the issue of standardizing the > authentication-data-suboption mechanism for performing a binding between the > MN and HA. The issue has been discussed on the WG mailing list over > the last few weeks. The I-D > (draft-patil-mip6-whyauthdataoption-00.txt) has captured some of the > arguments, but there are several others that have been made on the > list as well. A summary of the discussion was sent out earlier and is > captured in : > http://www1.ietf.org/mail-archive/web/mip6/current/msg01690.html > > The proposal here (in brief) is to standardize a mechanism specified > in I-D draft-ietf-mip6-auth-protocol-00.txt for performing MIP6 > registration with a home agent. RFC3775 specifies the use of IPsec to > secure the binding update/ACK messages between the MN and HA. The > auth-protocol mechanism relies on the use of an > authentication-data-suboption and does not require the MN-HA to > establish an IPsec SA. > (For the discussion that has ensued so far, please refer to the MIP6 > ML archives) > > The question to the WG is: > > 1. Should we standardize the authentication protocol specified in I-D > draft-ietf-mip6-auth-protocol-00.txt as an alternative (to the > IPSec mechanism specified in RFC3775/6) means to securing the BUs > and BAcks between the MN and HA. Note that this solution is an > additional mechanism for doing registration with an HA and does not > deprecate the currently specified solution. > > Yes [ ] > No [ ] > > > The consensus call will close on October 12th, 2004. > > -Chairs > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat Oct 9 06:12:41 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00779 for ; Sat, 9 Oct 2004 06:12:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGENZ-0002fp-Dy for mip6-web-archive@ietf.org; Sat, 09 Oct 2004 06:23:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGEBq-0007Ce-FR; Sat, 09 Oct 2004 06:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGEAp-0006nz-Vo for mip6@megatron.ietf.org; Sat, 09 Oct 2004 06:10:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00654 for ; Sat, 9 Oct 2004 06:09:57 -0400 (EDT) Received: from bundit.graduate.kmitl.ac.th ([161.246.39.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGEJG-0002aZ-HJ for mip6@ietf.org; Sat, 09 Oct 2004 06:20:26 -0400 Received: from graduate.kmitl.ac.th ([161.246.39.95]) by bundit.graduate.kmitl.ac.th (8.12.8/8.12.5) with ESMTP id i999x6hf010048; Sat, 9 Oct 2004 16:59:07 +0700 Message-ID: <4167B7E2.2000901@graduate.kmitl.ac.th> Date: Sat, 09 Oct 2004 17:05:22 +0700 From: Warodom Werapun User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030401 X-Accept-Language: th, en-us, en MIME-Version: 1.0 To: mip6@ietf.org X-Enigmail-Version: 0.75.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=TIS-620; format=flowed Content-Transfer-Encoding: 7bit X-Graduate-MailScanner-Information: Please contact the ISP for more information X-Graduate-MailScanner: Found to be clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Content-Transfer-Encoding: 7bit Cc: Francis.Dupont@enst-bretagne.fr, kre@munnari.OZ.AU, mipl@mobile-ipv6.org Subject: [Mip6] design protocol to create Kbu X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Content-Transfer-Encoding: 7bit I designed a protocol to create Kbu by modified Kerberos concept using pre-secret key share to authenticated itself from HA for using in local organization. Home agent acts as Kerberos server to generate Kbu. I'd like to ask, are there somethings wrong with my design? If my designed is OK, I will go to next work. I'm newbie in IP protocol designer. Could you please give me some advices. :) *_Mobile Node Home Agent(As KDC) Correspondent Node_* | REQ (68 bytes) | | |------------------------->| | | | | | RepMN (64 bytes) | RepCN (64 bytes) | |<-------------------------|------------------------->| | | | Binding Update (BU) | |---------------------------------------------------->| | | | Binding Acknowledgement (BA) (if sent) | |<----------------------------------------------------| REQ 0 8 16 24 32 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------------- |Version| Traffic Class | Flow Label | IPv6 Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RFC 1883 | Payload Length |Next Header=KR | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + IPv6 Hrd = 40 bytes | | + Source Address = Mobile node Home Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address = Home Agent + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------- | Nonce | Algorithm | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Correspondent node Address = correspondent node + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Signature = prf(KMN,HoA|CoA|CN|Nonce) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rep to MN 0 8 16 24 32 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------------- |Version| Traffic Class | Flow Label | IPv6 Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RFC 1883 | Payload Length |Next Header=KR | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + IPv6 Hrd = 40 bytes | | + Source Address = Home Agent + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address = Care of address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------- | Nonce | Algorithm | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + + | ( KBU (96 bit) , prf(KMN,HoA|CoA|Nonce))KMN | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rep to CN 0 8 16 24 32 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------------- |Version| Traffic Class | Flow Label | IPv6 Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RFC 1883 | Payload Length |Next Header=KR | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + IPv6 Hrd = 40 bytes | | + Source Address = Mobile Node Home Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address = Correspondent node + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------- | Nonce | Algorithm | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + + | ( KBU(96 bits), prf(KMN,HA|CN|Nonce))KCN | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ t(handoff) = t(move-detect) + t(getCoA) + t(BU) t(BU) = tReq + tRep tRep = tRepMN if (tRepMN > tRepCN) tRepCN if (tRepCN > tRepMN) Thank you for sugguestion, -- Warodom Werapun PGP: http://plex.coe.psu.ac.th/myPGP.txt _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat Oct 9 16:28:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07568 for ; Sat, 9 Oct 2004 16:28:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGNzQ-0005Cm-CM for mip6-web-archive@ietf.org; Sat, 09 Oct 2004 16:38:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGNgJ-0001yW-Cf; Sat, 09 Oct 2004 16:19:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGNUw-0004JM-Hu for mip6@megatron.ietf.org; Sat, 09 Oct 2004 16:07:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06564 for ; Sat, 9 Oct 2004 16:07:20 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGNf7-0004sx-00 for mip6@ietf.org; Sat, 09 Oct 2004 16:17:54 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 09 Oct 2004 13:12:24 -0700 Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i99K6fk2009373; Sat, 9 Oct 2004 13:06:41 -0700 (PDT) Received: from gdommety-w2k04.cisco.com (che-vpn-cluster-1-114.cisco.com [10.86.240.114]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AEZ12825; Sat, 9 Oct 2004 13:06:41 -0700 (PDT) Message-Id: <4.3.2.7.2.20041009130622.02fa3b48@mira-sjc5-d.cisco.com> X-Sender: gdommety@mira-sjc5-d.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 09 Oct 2004 13:06:35 -0700 To: Basavaraj.Patil@nokia.com From: Gopal Dommety Subject: Re: [Mip6] Consensus Call: Standardizing the auth protocol [I-D: draft-ietf-mip6-auth-protocol-00.txt] In-Reply-To: <697DAA22C5004B4596E033803A7CEF4403B1BF01@daebe007.americas .nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 I vote for YES At 02:02 PM 10/6/2004 -0500, Basavaraj.Patil@nokia.com wrote: >This is a consensus call to the WG on the issue of standardizing the >authentication-data-suboption mechanism for performing a binding between the >MN and HA. The issue has been discussed on the WG mailing list over >the last few weeks. The I-D >(draft-patil-mip6-whyauthdataoption-00.txt) has captured some of the >arguments, but there are several others that have been made on the >list as well. A summary of the discussion was sent out earlier and is >captured in : >http://www1.ietf.org/mail-archive/web/mip6/current/msg01690.html > >The proposal here (in brief) is to standardize a mechanism specified >in I-D draft-ietf-mip6-auth-protocol-00.txt for performing MIP6 >registration with a home agent. RFC3775 specifies the use of IPsec to >secure the binding update/ACK messages between the MN and HA. The >auth-protocol mechanism relies on the use of an >authentication-data-suboption and does not require the MN-HA to >establish an IPsec SA. >(For the discussion that has ensued so far, please refer to the MIP6 >ML archives) > >The question to the WG is: > >1. Should we standardize the authentication protocol specified in I-D > draft-ietf-mip6-auth-protocol-00.txt as an alternative (to the > IPSec mechanism specified in RFC3775/6) means to securing the BUs > and BAcks between the MN and HA. Note that this solution is an > additional mechanism for doing registration with an HA and does not > deprecate the currently specified solution. > > Yes [ ] > No [ ] > > >The consensus call will close on October 12th, 2004. > >-Chairs > >_______________________________________________ >Mip6 mailing list >Mip6@ietf.org >https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Oct 11 08:47:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03047 for ; Mon, 11 Oct 2004 08:47:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGzl7-0007JE-GF for mip6-web-archive@ietf.org; Mon, 11 Oct 2004 08:58:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGzZ2-0002fy-Hq; Mon, 11 Oct 2004 08:46:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGzVg-00022k-IY for mip6@megatron.ietf.org; Mon, 11 Oct 2004 08:42:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02376 for ; Mon, 11 Oct 2004 08:42:39 -0400 (EDT) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGzgD-0007D8-Ny for mip6@ietf.org; Mon, 11 Oct 2004 08:53:34 -0400 Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 11 Oct 2004 14:40:44 +0200 Received: from PXPELLAFOL ([10.193.161.74]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.0); Mon, 11 Oct 2004 14:40:44 +0200 From: "Jean-Michel COMBES" To: Subject: RE : [Mip6] Consensus Call: Standardizing the auth protocol [I-D:draft-ietf-mip6-auth-protocol-00.txt] Date: Mon, 11 Oct 2004 14:40:44 +0200 Organization: France Telecom R&D Message-ID: <018c01c4af8f$869a9bc0$4aa1c10a@rd.francetelecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: <697DAA22C5004B4596E033803A7CEF4403B1BF01@daebe007.americas.nokia.com> Importance: Normal X-OriginalArrivalTime: 11 Oct 2004 12:40:45.0078 (UTC) FILETIME=[86D92B60:01C4AF8F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: quoted-printable X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: quoted-printable Hi, As I am afraid of the consequences to have 2 different solutions to = solve the same problem (management from the operator and the client point of = view, cost to implement them), I prefer to vote : Yes [ ] No [X] Regards. JMC. France Telecom - R&D Division - MAPS/NSS =20 Jean-Michel COMBES, Internet/Intranet Security E-Mail: jeanmichel.combes@francetelecom.com Phone: +33 (0)1 45 29 45 94 Fax: +33 (0)1 45 29 65 19 Mobile: +33 (0)6 07 29 30 16=20 > -----Original Message----- > From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On=20 > Behalf Of Basavaraj.Patil@nokia.com > Sent: Thursday, October 07, 2004 12:03 AM > To: mip6@ietf.org > Subject: [Mip6] Consensus Call: Standardizing the auth=20 > protocol [I-D:draft-ietf-mip6-auth-protocol-00.txt] >=20 >=20 >=20 > This is a consensus call to the WG on the issue of standardizing the > authentication-data-suboption mechanism for performing a=20 > binding between the > MN and HA. The issue has been discussed on the WG mailing list over > the last few weeks. The I-D > (draft-patil-mip6-whyauthdataoption-00.txt) has captured some of the > arguments, but there are several others that have been made on the > list as well. A summary of the discussion was sent out earlier and is > captured in : > http://www1.ietf.org/mail-archive/web/mip6/current/msg01690.html >=20 > The proposal here (in brief) is to standardize a mechanism specified > in I-D draft-ietf-mip6-auth-protocol-00.txt for performing MIP6 > registration with a home agent. RFC3775 specifies the use of IPsec to > secure the binding update/ACK messages between the MN and HA. The > auth-protocol mechanism relies on the use of an > authentication-data-suboption and does not require the MN-HA to > establish an IPsec SA. =20 > (For the discussion that has ensued so far, please refer to the MIP6 > ML archives) >=20 > The question to the WG is: >=20 > 1. Should we standardize the authentication protocol specified in I-D > draft-ietf-mip6-auth-protocol-00.txt as an alternative (to the > IPSec mechanism specified in RFC3775/6) means to securing the BUs > and BAcks between the MN and HA. Note that this solution is an > additional mechanism for doing registration with an HA and does not > deprecate the currently specified solution.=20 >=20 > Yes [ ] > No [ ] >=20 >=20 > The consensus call will close on October 12th, 2004. >=20 > -Chairs >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Oct 11 11:03:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12637 for ; Mon, 11 Oct 2004 11:03:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH1sN-00015g-6z for mip6-web-archive@ietf.org; Mon, 11 Oct 2004 11:14:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH1gQ-0007je-F9; Mon, 11 Oct 2004 11:01:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFdEI-0006OF-Au for mip6@megatron.ietf.org; Thu, 07 Oct 2004 14:43:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10450 for ; Thu, 7 Oct 2004 14:43:04 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFdO3-0001EI-7b for mip6@ietf.org; Thu, 07 Oct 2004 14:53:11 -0400 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i97IgUl21887; Thu, 7 Oct 2004 14:42:30 -0400 (EDT) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Oct 2004 14:41:43 -0400 Message-ID: From: "Haseeb Akhtar" To: "'mip6@ietf.org'" Subject: Re:[Mip6] Consensus Call: Standardizing the auth protocol [I-D:dr aft-ietf-mip6-auth-protocol-00.txt] Date: Thu, 7 Oct 2004 14:41:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.6 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac X-Mailman-Approved-At: Mon, 11 Oct 2004 11:01:53 -0400 Cc: "'Basavaraj.Patil@nokia.com'" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1292480768==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 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. --===============1292480768== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4AC9D.42E9EC08" 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_01C4AC9D.42E9EC08 Content-Type: text/plain Yes to this one. ----- Original Message ----- From: To: Sent: Wednesday, October 06, 2004 3:02 PM Subject: [Mip6] Consensus Call: Standardizing the auth protocol [I-D:draft-ietf-mip6-auth-protocol-00.txt] This is a consensus call to the WG on the issue of standardizing the authentication-data-suboption mechanism for performing a binding between the MN and HA. The issue has been discussed on the WG mailing list over the last few weeks. The I-D (draft-patil-mip6-whyauthdataoption-00.txt) has captured some of the arguments, but there are several others that have been made on the list as well. A summary of the discussion was sent out earlier and is captured in : http://www1.ietf.org/mail-archive/web/mip6/current/msg01690.html The proposal here (in brief) is to standardize a mechanism specified in I-D draft-ietf-mip6-auth-protocol-00.txt for performing MIP6 registration with a home agent. RFC3775 specifies the use of IPsec to secure the binding update/ACK messages between the MN and HA. The auth-protocol mechanism relies on the use of an authentication-data-suboption and does not require the MN-HA to establish an IPsec SA. (For the discussion that has ensued so far, please refer to the MIP6 ML archives) The question to the WG is: 1. Should we standardize the authentication protocol specified in I-D draft-ietf-mip6-auth-protocol-00.txt as an alternative (to the IPSec mechanism specified in RFC3775/6) means to securing the BUs and BAcks between the MN and HA. Note that this solution is an additional mechanism for doing registration with an HA and does not deprecate the currently specified solution. Yes [ ] No [ ] The consensus call will close on October 12th, 2004. -Chairs ------_=_NextPart_001_01C4AC9D.42E9EC08 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Re:[Mip6] Consensus Call: Standardizing the auth protocol = [I-D:draft-ietf-mip6-auth-protocol-00.txt]

Yes to this one.

----- Original Message ----- =
From: = <Basavaraj.Patil@nokia.com>
To: = <mip6@ietf.org>
Sent: Wednesday, October 06, = 2004 3:02 PM
Subject: [Mip6] Consensus Call: = Standardizing the auth protocol = [I-D:draft-ietf-mip6-auth-protocol-00.txt]

This is a consensus call to the = WG on the issue of standardizing the authentication-data-suboption = mechanism for performing a binding between the MN and HA. The issue has = been discussed on the WG mailing list over the last few weeks. The = I-D

(draft-patil-mip6-whyauthdataoption-00.txt) has captured some of = the arguments, but there are several others that have been made on the = list as well. A summary of the discussion was sent out earlier and is = captured in : http://www1.ietf.org/mail-archive/web/mip6/current/msg01690.html

The proposal here (in brief) is = to standardize a mechanism specified in I-D = draft-ietf-mip6-auth-protocol-00.txt for performing MIP6 registration = with a home agent. RFC3775 specifies the use of IPsec to secure the = binding update/ACK messages between the MN and HA. The auth-protocol = mechanism relies on the use of an authentication-data-suboption and = does not require the MN-HA to establish an IPsec SA. (For the = discussion that has ensued so far, please refer to the MIP6 ML = archives)

The question to the WG = is:

1. Should we standardize the = authentication protocol specified in I-D
   = draft-ietf-mip6-auth-protocol-00.txt as an alternative (to the
   IPSec mechanism = specified in RFC3775/6) means to securing the BUs
   and BAcks between = the MN and HA. Note that this solution is an
   additional = mechanism for doing registration with an HA and does not
   deprecate the = currently specified solution.

   = Yes      [ ]
   = No      [ ]


The consensus call will close on = October 12th, 2004.

-Chairs


------_=_NextPart_001_01C4AC9D.42E9EC08-- --===============1292480768== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1292480768==-- From mip6-bounces@ietf.org Mon Oct 11 11:05:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12821 for ; Mon, 11 Oct 2004 11:05:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH1uq-00018U-6x for mip6-web-archive@ietf.org; Mon, 11 Oct 2004 11:16:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH1gR-0007kJ-8T; Mon, 11 Oct 2004 11:01:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFdPP-00008m-Rl for mip6@megatron.ietf.org; Thu, 07 Oct 2004 14:54:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10968 for ; Thu, 7 Oct 2004 14:54:33 -0400 (EDT) Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFdZ9-0001zj-PM for mip6@ietf.org; Thu, 07 Oct 2004 15:04:41 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i97Is01i001719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 7 Oct 2004 11:54:01 -0700 (PDT) Received: from MAHENDRA.qualcomm.com (mahendra.qualcomm.com [129.46.75.74]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i97IrwqV026330 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Thu, 7 Oct 2004 11:53:58 -0700 (PDT) Message-Id: <6.0.0.22.2.20041007115212.059aaec8@qcmail1.qualcomm.com> X-Sender: mahendra@qcmail1.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Thu, 07 Oct 2004 11:53:57 -0700 To: mip6@ietf.org From: AC Mahendran Subject: RE: [Mip6] Consensus Call: Standardizing the auth protocol [I-D: draft-ietf-mip6-auth-protocol-00.txt] Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 X-Mailman-Approved-At: Mon, 11 Oct 2004 11:01:53 -0400 Cc: Basavaraj.Patil@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 I vote YES. -AC >From: Basavaraj.Patil@nokia.com >X-Scanned: Thu, 7 Oct 2004 01:04:11 +0300 Nokia Message Protector V1.3.31 > 2004060815 - RELEASE >Date: Wed, 6 Oct 2004 17:02:55 -0500 >Thread-Topic: Consensus Call: Standardizing the auth protocol [I-D: > draft-ietf-mip6-auth-protocol-00.txt] >Thread-Index: AcSr8DqS6Ympo/12TUmUacaxgh/VgA== >To: >X-OriginalArrivalTime: 06 Oct 2004 22:02:56.0154 (UTC) > FILETIME=[3C1227A0:01C4ABF0] >X-Spam-Score: 0.3 (/) >X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 >Subject: [Mip6] Consensus Call: Standardizing the auth protocol [I-D: > draft-ietf-mip6-auth-protocol-00.txt] >X-BeenThere: mip6@ietf.org >X-Mailman-Version: 2.1.5 >List-Id: mip6.ietf.org >List-Unsubscribe: , > >List-Post: >List-Help: >List-Subscribe: , > >Sender: mip6-bounces@ietf.org >X-PMX-Version: 4.6.0.97784, Antispam-Core: 4.6.0.97340, Antispam-Data: >2004.10.6.2 > > >This is a consensus call to the WG on the issue of standardizing the >authentication-data-suboption mechanism for performing a binding between the >MN and HA. The issue has been discussed on the WG mailing list over >the last few weeks. The I-D >(draft-patil-mip6-whyauthdataoption-00.txt) has captured some of the >arguments, but there are several others that have been made on the >list as well. A summary of the discussion was sent out earlier and is >captured in : >http://www1.ietf.org/mail-archive/web/mip6/current/msg01690.html > >The proposal here (in brief) is to standardize a mechanism specified >in I-D draft-ietf-mip6-auth-protocol-00.txt for performing MIP6 >registration with a home agent. RFC3775 specifies the use of IPsec to >secure the binding update/ACK messages between the MN and HA. The >auth-protocol mechanism relies on the use of an >authentication-data-suboption and does not require the MN-HA to >establish an IPsec SA. >(For the discussion that has ensued so far, please refer to the MIP6 >ML archives) > >The question to the WG is: > >1. Should we standardize the authentication protocol specified in I-D > draft-ietf-mip6-auth-protocol-00.txt as an alternative (to the > IPSec mechanism specified in RFC3775/6) means to securing the BUs > and BAcks between the MN and HA. Note that this solution is an > additional mechanism for doing registration with an HA and does not > deprecate the currently specified solution. > > Yes [ ] > No [ ] > > >The consensus call will close on October 12th, 2004. > >-Chairs > >_______________________________________________ >Mip6 mailing list >Mip6@ietf.org >https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Oct 11 11:07:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12945 for ; Mon, 11 Oct 2004 11:07:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH1wq-0001An-LY for mip6-web-archive@ietf.org; Mon, 11 Oct 2004 11:18:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH1gR-0007l4-TB; Mon, 11 Oct 2004 11:01:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFzTZ-00047N-SJ for mip6@megatron.ietf.org; Fri, 08 Oct 2004 14:28:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18727 for ; Fri, 8 Oct 2004 14:28:22 -0400 (EDT) Received: from bws10.bridgewatersystems.com ([216.113.7.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFzdX-0005C9-Mp for mip6@ietf.org; Fri, 08 Oct 2004 14:38:42 -0400 Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2657.72) id <43V10HRX>; Fri, 8 Oct 2004 14:27:50 -0400 Message-ID: From: Avi Lior To: "'Basavaraj.Patil@nokia.com'" Date: Fri, 8 Oct 2004 14:27:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-Mailman-Approved-At: Mon, 11 Oct 2004 11:01:53 -0400 Cc: "'mip6@ietf.org'" Subject: [Mip6] Consensus Call on draft-ietf-mip6-auth-protocol-00.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 The question to the WG is: 1. Should we standardize the authentication protocol specified in I-D draft-ietf-mip6-auth-protocol-00.txt as an alternative (to the IPSec mechanism specified in RFC3775/6) means to securing the BUs and BAcks between the MN and HA. Note that this solution is an additional mechanism for doing registration with an HA and does not deprecate the currently specified solution. Yes [X] No [ ] ----------------------------- Avi Lior Bridgewater Systems Corp. Phone: 613.591.9104 x 6417 Cell : 613.297.2177 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Oct 11 11:09:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12993 for ; Mon, 11 Oct 2004 11:09:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH1xs-0001BT-OP for mip6-web-archive@ietf.org; Mon, 11 Oct 2004 11:19:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH1gS-0007lP-Ip; Mon, 11 Oct 2004 11:01:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGrz1-0001xt-6B for mip6@megatron.ietf.org; Mon, 11 Oct 2004 00:40:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13437 for ; Mon, 11 Oct 2004 00:40:23 -0400 (EDT) From: Mika.Joutsenvirta@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGs9Q-0006jK-TL for mip6@ietf.org; Mon, 11 Oct 2004 00:51:16 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9B4dTF21964 for ; Mon, 11 Oct 2004 07:39:29 +0300 (EET DST) X-Scanned: Mon, 11 Oct 2004 07:39:13 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i9B4dD2o008933 for ; Mon, 11 Oct 2004 07:39:13 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 001MrSgb; Mon, 11 Oct 2004 07:39:12 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9B4dCa26781 for ; Mon, 11 Oct 2004 07:39:12 +0300 (EET DST) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 11 Oct 2004 07:39:12 +0300 Received: from trebe051.NOE.Nokia.com ([172.22.124.60]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 11 Oct 2004 07:39:12 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Consensus Call: Standardizing the auth protocol [I-D:draft-ietf-mip6-auth-protocol-00.txt] Date: Mon, 11 Oct 2004 07:39:10 +0300 Message-ID: <8AA62C0ABD31B544993F7592D8852806145A0A@trebe051.ntc.nokia.com> Thread-Topic: Consensus Call: Standardizing the auth protocol [I-D:draft-ietf-mip6-auth-protocol-00.txt] Thread-Index: AcSr8DqS6Ympo/12TUmUacaxgh/VgADW8QwQ To: X-OriginalArrivalTime: 11 Oct 2004 04:39:12.0502 (UTC) FILETIME=[4187F160:01C4AF4C] X-Spam-Score: 0.3 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 11 Oct 2004 11:01:53 -0400 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: quoted-printable 1. Should we standardize the authentication protocol specified in I-D draft-ietf-mip6-auth-protocol-00.txt as an alternative (to the IPSec mechanism specified in RFC3775/6) means to securing the BUs and BAcks between the MN and HA. Note that this solution is an additional mechanism for doing registration with an HA and does not deprecate the currently specified solution.=20 Yes [X] No [ ] Mika > -----Original Message----- > From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org]On Behalf Of > ext Basavaraj.Patil@nokia.com > Sent: 07 October, 2004 01:03 > To: mip6@ietf.org > Subject: [Mip6] Consensus Call: Standardizing the auth protocol > [I-D:draft-ietf-mip6-auth-protocol-00.txt] >=20 >=20 >=20 > This is a consensus call to the WG on the issue of standardizing the > authentication-data-suboption mechanism for performing a=20 > binding between the > MN and HA. The issue has been discussed on the WG mailing list over > the last few weeks. The I-D > (draft-patil-mip6-whyauthdataoption-00.txt) has captured some of the > arguments, but there are several others that have been made on the > list as well. A summary of the discussion was sent out earlier and is > captured in : > http://www1.ietf.org/mail-archive/web/mip6/current/msg01690.html >=20 > The proposal here (in brief) is to standardize a mechanism specified > in I-D draft-ietf-mip6-auth-protocol-00.txt for performing MIP6 > registration with a home agent. RFC3775 specifies the use of IPsec to > secure the binding update/ACK messages between the MN and HA. The > auth-protocol mechanism relies on the use of an > authentication-data-suboption and does not require the MN-HA to > establish an IPsec SA. =20 > (For the discussion that has ensued so far, please refer to the MIP6 > ML archives) >=20 > The question to the WG is: >=20 > 1. Should we standardize the authentication protocol specified in I-D > draft-ietf-mip6-auth-protocol-00.txt as an alternative (to the > IPSec mechanism specified in RFC3775/6) means to securing the BUs > and BAcks between the MN and HA. Note that this solution is an > additional mechanism for doing registration with an HA and does not > deprecate the currently specified solution.=20 >=20 > Yes [ ] > No [ ] >=20 >=20 > The consensus call will close on October 12th, 2004. >=20 > -Chairs >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Oct 11 11:22:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14189 for ; Mon, 11 Oct 2004 11:22:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH2B1-0001QH-7R for mip6-web-archive@ietf.org; Mon, 11 Oct 2004 11:33:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH1xx-0002MR-1w; Mon, 11 Oct 2004 11:20:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH1x1-0002CK-Cu for mip6@megatron.ietf.org; Mon, 11 Oct 2004 11:19:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13969 for ; Mon, 11 Oct 2004 11:19:00 -0400 (EDT) From: Franck.Le@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH27Y-0001MQ-MY for mip6@ietf.org; Mon, 11 Oct 2004 11:29:58 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9BFIxh21795 for ; Mon, 11 Oct 2004 18:18:59 +0300 (EET DST) X-Scanned: Mon, 11 Oct 2004 18:18:52 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i9BFIqJF002356 for ; Mon, 11 Oct 2004 18:18:52 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00BEF2WI; Mon, 11 Oct 2004 18:18:52 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9BFIia09865 for ; Mon, 11 Oct 2004 18:18:45 +0300 (EET DST) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 11 Oct 2004 10:18:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Consensus Call: Standardizing the auth protocol [I-D:draft-ietf-mip6-auth-protocol-00.txt] Date: Mon, 11 Oct 2004 10:18:21 -0500 Message-ID: <57A26D272F67A743952F6B4371B8F81103F2984E@daebe007.americas.nokia.com> Thread-Topic: [Mip6] Consensus Call: Standardizing the auth protocol [I-D:draft-ietf-mip6-auth-protocol-00.txt] Thread-Index: AcSvpHo5ePJbzp4GTeO9LzCjQZzcLwAAOZvA To: X-OriginalArrivalTime: 11 Oct 2004 15:18:22.0276 (UTC) FILETIME=[8BC71040:01C4AFA5] X-Spam-Score: 0.3 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable Cc: Basavaraj.Patil@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable I vote YES, Franck ----- Original Message -----=20 From: =20 To: =20 Sent: Wednesday, October 06, 2004 3:02 PM=20 Subject: [Mip6] Consensus Call: Standardizing the auth protocol = [I-D:draft-ietf-mip6-auth-protocol-00.txt]=20 This is a consensus call to the WG on the issue of standardizing the = authentication-data-suboption mechanism for performing a binding between = the MN and HA. The issue has been discussed on the WG mailing list over = the last few weeks. The I-D (draft-patil-mip6-whyauthdataoption-00.txt) has captured some of the = arguments, but there are several others that have been made on the list = as well. A summary of the discussion was sent out earlier and is = captured in : = http://www1.ietf.org/mail-archive/web/mip6/current/msg01690.html The proposal here (in brief) is to standardize a mechanism specified in = I-D draft-ietf-mip6-auth-protocol-00.txt for performing MIP6 = registration with a home agent. RFC3775 specifies the use of IPsec to = secure the binding update/ACK messages between the MN and HA. The = auth-protocol mechanism relies on the use of an = authentication-data-suboption and does not require the MN-HA to = establish an IPsec SA. (For the discussion that has ensued so far, = please refer to the MIP6 ML archives) The question to the WG is:=20 1. Should we standardize the authentication protocol specified in I-D=20 draft-ietf-mip6-auth-protocol-00.txt as an alternative (to the=20 IPSec mechanism specified in RFC3775/6) means to securing the BUs=20 and BAcks between the MN and HA. Note that this solution is an=20 additional mechanism for doing registration with an HA and does not=20 deprecate the currently specified solution.=20 Yes [ ]=20 No [ ]=20 The consensus call will close on October 12th, 2004.=20 -Chairs=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Oct 11 13:58:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27737 for ; Mon, 11 Oct 2004 13:58:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH4bh-0004xX-0d for mip6-web-archive@ietf.org; Mon, 11 Oct 2004 14:09:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH4LN-0001Ng-1X; Mon, 11 Oct 2004 13:52:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH4Ib-0000t2-5F for mip6@megatron.ietf.org; Mon, 11 Oct 2004 13:49:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26839 for ; Mon, 11 Oct 2004 13:49:27 -0400 (EDT) Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH4TA-0004jE-UD for mip6@ietf.org; Mon, 11 Oct 2004 14:00:25 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i9BHmt57028206 for ; Mon, 11 Oct 2004 10:48:55 -0700 (PDT) Received: from WLAU.qualcomm.com (wlau.qualcomm.com [129.46.74.167]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i9BHmrDY005593 for ; Mon, 11 Oct 2004 10:48:53 -0700 (PDT) Message-Id: <6.0.0.22.2.20041011104743.020d4d00@qcmail1.qualcomm.com> X-Sender: wlau@qcmail1.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Mon, 11 Oct 2004 10:48:52 -0700 To: From: Wing Cheong Lau Subject: Re: [Mip6] Consensus Call: Standardizing the auth protocol [I-D: draft-ietf-mip6-auth-protocol-00.txt] In-Reply-To: <697DAA22C5004B4596E033803A7CEF4403B1BF01@daebe007.americas .nokia.com> References: <697DAA22C5004B4596E033803A7CEF4403B1BF01@daebe007.americas.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 > >The question to the WG is: > >1. Should we standardize the authentication protocol specified in I-D > draft-ietf-mip6-auth-protocol-00.txt as an alternative (to the > IPSec mechanism specified in RFC3775/6) means to securing the BUs > and BAcks between the MN and HA. Note that this solution is an > additional mechanism for doing registration with an HA and does not > deprecate the currently specified solution. I vote YES. Regards, Wing Lau _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Oct 11 20:03:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12083 for ; Mon, 11 Oct 2004 20:03:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHAJ7-0008Tf-Js for mip6-web-archive@ietf.org; Mon, 11 Oct 2004 20:14:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH9z5-0002id-Ou; Mon, 11 Oct 2004 19:53:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH9sd-0000ff-JL for mip6@megatron.ietf.org; Mon, 11 Oct 2004 19:47:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11290 for ; Mon, 11 Oct 2004 19:46:59 -0400 (EDT) Received: from zcamail03.zca.compaq.com ([161.114.32.103]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHA3B-0008Ea-Jx for mip6@ietf.org; Mon, 11 Oct 2004 19:58:02 -0400 Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by zcamail03.zca.compaq.com (Postfix) with ESMTP id 610EDA5CE for ; Mon, 11 Oct 2004 16:46:23 -0700 (PDT) Received: from kitche.zk3.dec.com (kitche2.zk3.dec.com [16.140.160.162]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id CE0BE2B1; Mon, 11 Oct 2004 18:46:22 -0500 (CDT) Received: from [127.0.0.1] by kitche.zk3.dec.com (8.9.3/1.1.27.5/27Oct00-1235PM) id TAA0001246521; Mon, 11 Oct 2004 19:46:21 -0400 (EDT) Message-ID: <416B1B2B.2070509@hp.com> Date: Mon, 11 Oct 2004 19:45:47 -0400 From: Brian Haley Organization: Linux and Open Source Lab User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com Subject: Re: [Mip6] Consensus Call: Standardizing the auth protocol [I-D: draft-ietf-mip6-auth-protocol-00.txt] References: <697DAA22C5004B4596E033803A7CEF4403B1BF01@daebe007.americas.nokia.com> In-Reply-To: <697DAA22C5004B4596E033803A7CEF4403B1BF01@daebe007.americas.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit I vote NO. -Brian Basavaraj.Patil@nokia.com wrote: > This is a consensus call to the WG on the issue of standardizing the > authentication-data-suboption mechanism for performing a binding between the > MN and HA. The issue has been discussed on the WG mailing list over > the last few weeks. The I-D > (draft-patil-mip6-whyauthdataoption-00.txt) has captured some of the > arguments, but there are several others that have been made on the > list as well. A summary of the discussion was sent out earlier and is > captured in : > http://www1.ietf.org/mail-archive/web/mip6/current/msg01690.html > > The proposal here (in brief) is to standardize a mechanism specified > in I-D draft-ietf-mip6-auth-protocol-00.txt for performing MIP6 > registration with a home agent. RFC3775 specifies the use of IPsec to > secure the binding update/ACK messages between the MN and HA. The > auth-protocol mechanism relies on the use of an > authentication-data-suboption and does not require the MN-HA to > establish an IPsec SA. > (For the discussion that has ensued so far, please refer to the MIP6 > ML archives) > > The question to the WG is: > > 1. Should we standardize the authentication protocol specified in I-D > draft-ietf-mip6-auth-protocol-00.txt as an alternative (to the > IPSec mechanism specified in RFC3775/6) means to securing the BUs > and BAcks between the MN and HA. Note that this solution is an > additional mechanism for doing registration with an HA and does not > deprecate the currently specified solution. > > Yes [ ] > No [ ] > > > The consensus call will close on October 12th, 2004. > > -Chairs > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Oct 12 01:04:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02024 for ; Tue, 12 Oct 2004 01:04:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHF0o-00053b-JO for mip6-web-archive@ietf.org; Tue, 12 Oct 2004 01:15:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHEbg-0001TH-QD; Tue, 12 Oct 2004 00:49:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHEYb-0000Up-I9 for mip6@megatron.ietf.org; Tue, 12 Oct 2004 00:46:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00745 for ; Tue, 12 Oct 2004 00:46:38 -0400 (EDT) From: Markku.Ala-Vannesluoma@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHEjF-0004ld-VM for mip6@ietf.org; Tue, 12 Oct 2004 00:57:43 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9C4kbh18726 for ; Tue, 12 Oct 2004 07:46:37 +0300 (EET DST) X-Scanned: Tue, 12 Oct 2004 07:46:21 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i9C4kLU3019472 for ; Tue, 12 Oct 2004 07:46:21 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00QKcuk0; Tue, 12 Oct 2004 07:46:19 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9C4kIa02832 for ; Tue, 12 Oct 2004 07:46:18 +0300 (EET DST) Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 12 Oct 2004 07:46:18 +0300 Received: from trebe051.NOE.Nokia.com ([172.22.124.60]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 12 Oct 2004 07:46:17 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Consensus Call: Standardizing the auth protocol [I-D:draft-ietf-mip6-auth-protocol-00.txt] Date: Tue, 12 Oct 2004 07:46:18 +0300 Message-ID: Thread-Topic: Consensus Call: Standardizing the auth protocol [I-D:draft-ietf-mip6-auth-protocol-00.txt] Thread-Index: AcSr8DqS6Ympo/12TUmUacaxgh/VgADYOC4g To: X-OriginalArrivalTime: 12 Oct 2004 04:46:17.0875 (UTC) FILETIME=[697C7630:01C4B016] X-Spam-Score: 0.3 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable I vote YES. BR, Markku Ala-Vannesluoma Nokia > The question to the WG is: >=20 > 1. Should we standardize the authentication protocol specified in I-D > draft-ietf-mip6-auth-protocol-00.txt as an alternative (to the > IPSec mechanism specified in RFC3775/6) means to securing the BUs > and BAcks between the MN and HA. Note that this solution is an > additional mechanism for doing registration with an HA and does not > deprecate the currently specified solution.=20 >=20 > Yes [ ] > No [ ] >=20 >=20 > The consensus call will close on October 12th, 2004. >=20 > -Chairs >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Oct 12 01:45:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05354 for ; Tue, 12 Oct 2004 01:45:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHFeJ-0005ld-Gi for mip6-web-archive@ietf.org; Tue, 12 Oct 2004 01:56:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHFO1-0000Le-GE; Tue, 12 Oct 2004 01:39:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHFIU-0006m4-UB for mip6@megatron.ietf.org; Tue, 12 Oct 2004 01:34:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04259 for ; Tue, 12 Oct 2004 01:34:06 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHFT9-0005Wp-Hn for mip6@ietf.org; Tue, 12 Oct 2004 01:45:09 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i9C5XUR28680 for ; Tue, 12 Oct 2004 08:33:30 +0300 Date: Tue, 12 Oct 2004 08:33:30 +0300 (EEST) From: Pekka Savola To: mip6@ietf.org Subject: Re: [Mip6] Consensus Call: Standardizing the auth protocol [I-D: draft-ietf-mip6-auth-protocol-00.txt] In-Reply-To: <697DAA22C5004B4596E033803A7CEF4403B1BF01@daebe007.americas.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d On Wed, 6 Oct 2004 Basavaraj.Patil@nokia.com wrote: > The question to the WG is: > > 1. Should we standardize the authentication protocol specified in I-D > draft-ietf-mip6-auth-protocol-00.txt as an alternative (to the > IPSec mechanism specified in RFC3775/6) means to securing the BUs > and BAcks between the MN and HA. Note that this solution is an > additional mechanism for doing registration with an HA and does not > deprecate the currently specified solution. > > Yes [ ] > No [X] Btw. what's the deal with current influx of people voicing their opinions in the concensus call who have never before written a single message to the list? Looks like room packing to me. Luckily enough, the IETF procedures allow the chairs to take these kind of issues into consideration. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Oct 12 02:39:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22454 for ; Tue, 12 Oct 2004 02:39:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHGUU-0006YN-9U for mip6-web-archive@ietf.org; Tue, 12 Oct 2004 02:50:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHGGA-0003ad-1I; Tue, 12 Oct 2004 02:35:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHG95-0000rK-LM for mip6@megatron.ietf.org; Tue, 12 Oct 2004 02:28:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21946 for ; Tue, 12 Oct 2004 02:28:26 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHGJk-0006PG-UT for mip6@ietf.org; Tue, 12 Oct 2004 02:39:30 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i9C60nn21739; Mon, 11 Oct 2004 23:00:49 -0700 X-mProtect: <200410120600> Nokia Silicon Valley Messaging Protection Received: from danira-pool049137.americas.nokia.com (10.241.49.137, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd7nME1z; Mon, 11 Oct 2004 23:00:47 PDT Message-ID: <416B7953.8030804@iprg.nokia.com> Date: Mon, 11 Oct 2004 23:27:31 -0700 From: "Charles E. Perkins" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola Subject: Re: [Mip6] Consensus Call: Standardizing the auth protocol [I-D: draft-ietf-mip6-auth-protocol-00.txt] References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Hello Pekka, Perhaps you were referring to my vote. Is it enough that I followed every e-mail to the list? Or would it matter if I thought that this was much closer to the spirit of the protocol compared to the brute force fit into the current IPsec gerrymandering? I didn't see any evidence of the room-packing you suggest. I know that no one told me how to vote. However, I would agree with you that the chairs probably know how to handle the situation. Regards, Charlie P. Pekka Savola wrote: >On Wed, 6 Oct 2004 Basavaraj.Patil@nokia.com wrote: > > >>The question to the WG is: >> >>1. Should we standardize the authentication protocol specified in I-D >> draft-ietf-mip6-auth-protocol-00.txt as an alternative (to the >> IPSec mechanism specified in RFC3775/6) means to securing the BUs >> and BAcks between the MN and HA. Note that this solution is an >> additional mechanism for doing registration with an HA and does not >> deprecate the currently specified solution. >> >> Yes [ ] >> No [X] >> >> > >Btw. what's the deal with current influx of people voicing their >opinions in the concensus call who have never before written a single >message to the list? Looks like room packing to me. Luckily enough, >the IETF procedures allow the chairs to take these kind of issues into >consideration. > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Oct 12 03:08:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23934 for ; Tue, 12 Oct 2004 03:08:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHGwE-0006xH-5Q for mip6-web-archive@ietf.org; Tue, 12 Oct 2004 03:19:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHGb6-0001lT-G7; Tue, 12 Oct 2004 02:57:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHGX6-0000VT-64 for mip6@megatron.ietf.org; Tue, 12 Oct 2004 02:53:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23140 for ; Tue, 12 Oct 2004 02:53:14 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHGhl-0006kT-FX for mip6@ietf.org; Tue, 12 Oct 2004 03:04:19 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i9C6qdk30430; Tue, 12 Oct 2004 09:52:39 +0300 Date: Tue, 12 Oct 2004 09:52:39 +0300 (EEST) From: Pekka Savola To: "Charles E. Perkins" Subject: Re: [Mip6] Consensus Call: Standardizing the auth protocol [I-D: draft-ietf-mip6-auth-protocol-00.txt] In-Reply-To: <416B7953.8030804@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a This is already off-topic, and I won't follow up on this thread further, but I think you deserve an explicit reply.. On Mon, 11 Oct 2004, Charles E. Perkins wrote: > Perhaps you were referring to my vote. Is it enough that > I followed every e-mail to the list? [...] I certainly wasn't referring to you, Charlie. :-) It was just a general observation I had from looking at who have responded, and comparing it to 1 year's backlog of email from the list :-). I'm not saying that one shouldn't voice an opinion when asked but.. it kind of makes one wonder never the less... -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Oct 12 03:53:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25822 for ; Tue, 12 Oct 2004 03:53:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHHdp-0007kD-G7 for mip6-web-archive@ietf.org; Tue, 12 Oct 2004 04:04:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHHOj-0000mI-7k; Tue, 12 Oct 2004 03:48:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHHKB-0007th-CY for mip6@megatron.ietf.org; Tue, 12 Oct 2004 03:43:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25313 for ; Tue, 12 Oct 2004 03:43:57 -0400 (EDT) Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHHUr-0007Se-Uw for mip6@ietf.org; Tue, 12 Oct 2004 03:55:02 -0400 Received: from az33exr04.mot.com (pobox4.mot.com [10.64.251.243]) by motgate3.mot.com (8.12.11/Motgate3) with ESMTP id i9C7kWWn020108; Tue, 12 Oct 2004 00:46:32 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id i9C5hYmm014197; Tue, 12 Oct 2004 00:43:34 -0500 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id F0AA188CF7C; Tue, 12 Oct 2004 09:43:53 +0200 (CEST) Message-ID: <416B8B34.7060700@motorola.com> Date: Tue, 12 Oct 2004 09:43:48 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com Subject: Re: [Mip6] Consensus Call: Standardizing the auth protocol [I-D:draft-ietf-mip6-auth-protocol-00.txt] References: <8A16DAD84432534FBFC19FD92B50512F0D3049@ames.starentnetworks.com> In-Reply-To: <8A16DAD84432534FBFC19FD92B50512F0D3049@ames.starentnetworks.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1831620564==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1831620564== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2B1D8BE2AAD9E852002074D1" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2B1D8BE2AAD9E852002074D1 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I vote NO. The Motivation section is light. DHAAD is still insecure. Alex > The proposal here (in brief) is to standardize a mechanism specified in I-D > draft-ietf-mip6-auth-protocol-00.txt for performing MIP6 registration with a > home agent. RFC3775 specifies the use of IPsec to secure the binding > update/ACK messages between the MN and HA. The auth-protocol mechanism > relies on the use of an authentication-data-suboption and does not require > the MN-HA to establish an IPsec SA. > (For the discussion that has ensued so far, please refer to the MIP6 ML > archives) > > The question to the WG is: > > 1. Should we standardize the authentication protocol specified in I-D > draft-ietf-mip6-auth-protocol-00.txt as an alternative (to the > IPSec mechanism specified in RFC3775/6) means to securing the BUs > and BAcks between the MN and HA. Note that this solution is an > additional mechanism for doing registration with an HA and does not > deprecate the currently specified solution. > > Yes [ ] > No [ ] > > > The consensus call will close on October 12th, 2004. > > -Chairs --------------enig2B1D8BE2AAD9E852002074D1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBa4s5MmC0w56zj54RAskkAKC5hQ6MFU6KB/Lx1koCSSi2iH5csgCgsKV5 5FNQjRAkKfEsPrmMfdFGygQ= =pMxg -----END PGP SIGNATURE----- --------------enig2B1D8BE2AAD9E852002074D1-- --===============1831620564== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1831620564==-- From mip6-bounces@ietf.org Tue Oct 12 09:07:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17979 for ; Tue, 12 Oct 2004 09:07:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHMXq-0004nI-UT for mip6-web-archive@ietf.org; Tue, 12 Oct 2004 09:18:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHMFw-0008Cd-Nj; Tue, 12 Oct 2004 08:59:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH6C9-0001Jn-OW for mip6@megatron.ietf.org; Mon, 11 Oct 2004 15:50:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09973 for ; Mon, 11 Oct 2004 15:50:55 -0400 (EDT) Received: from mail-red.bigfish.com ([216.148.222.61] helo=mail29-red-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH6Mk-0007lm-Ln for Mip6@ietf.org; Mon, 11 Oct 2004 16:01:55 -0400 Received: from mail29-red.bigfish.com (localhost.localdomain [127.0.0.1]) by mail29-red-R.bigfish.com (Postfix) with ESMTP id D5686395586 for ; Mon, 11 Oct 2004 19:50:34 +0000 (UCT) X-BigFish: VC Received: by mail29-red.bigfish.com (MessageSwitch) id 1097524231539283_24326; Mon, 11 Oct 2004 19:50:31 +0000 (UCT) Received: from smtpgw5.sprintspectrum.com (smtpgw5.sprintspectrum.com [207.40.188.13]) by mail29-red.bigfish.com (Postfix) with ESMTP id 20315393F0C for ; Mon, 11 Oct 2004 19:50:31 +0000 (UCT) Received: from mailhost.sprintspectrum.com (smtpgw7.it.sprintspectrum.com [207.40.65.55]) by smtpgw5.sprintspectrum.com (8.12.10/8.12.8) with ESMTP id i9BJoUaY002673 for ; Mon, 11 Oct 2004 14:50:30 -0500 (CDT) Received: from PKDWG01A.ad.sprint.com (PKDWG01A.corp.sprint.com [10.185.12.78]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9BJoPx02912 for ; Mon, 11 Oct 2004 14:50:30 -0500 (CDT) Received: from pkdwb02c.ad.sprint.com ([10.185.12.26]) by PKDWG01A.ad.sprint.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 11 Oct 2004 14:50:13 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Consensus Call: Standardizing the auth protocol [I-D:draft-ietf-mip6-auth-protocol-00.txt] Date: Mon, 11 Oct 2004 14:50:13 -0500 Message-ID: <2E8819C3F495D147B3F2FC41EF231CE40D424567@PKDWB02C.ad.sprint.com> Thread-Topic: [Mip6] Consensus Call: Standardizing the auth protocol [I-D:draft-ietf-mip6-auth-protocol-00.txt] thread-index: AcSshsijcUmpmTg8SmW2kXCJmrnRkwACzQzgAM4e5EA= From: "Manning, Serge M [NTK]" To: X-OriginalArrivalTime: 11 Oct 2004 19:50:13.0453 (UTC) FILETIME=[85FF27D0:01C4AFCB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 12 Oct 2004 08:59:54 -0400 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable >-----Original Message----- >From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On=20 >Subject: [Mip6] Consensus Call: Standardizing the auth=20 >protocol [I-D:draft-ietf-mip6-auth-protocol-00.txt] The question to the WG is: 1. Should we standardize the authentication protocol specified in I-D draft-ietf-mip6-auth-protocol-00.txt as an alternative (to the IPSec mechanism specified in RFC3775/6) means to securing the BUs and BAcks between the MN and HA. Note that this solution is an additional mechanism for doing registration with an HA and does not deprecate the currently specified solution.=20 Yes [X] No [ ] [Serge] I vote Yes. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Oct 12 09:07:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18010 for ; Tue, 12 Oct 2004 09:07:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHMYQ-0004o6-UP for mip6-web-archive@ietf.org; Tue, 12 Oct 2004 09:19:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHMFx-0008Ci-6w; Tue, 12 Oct 2004 08:59:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH8oj-0004H8-07 for mip6@megatron.ietf.org; Mon, 11 Oct 2004 18:38:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06512 for ; Mon, 11 Oct 2004 18:38:53 -0400 (EDT) Received: from mail1.wpi.edu ([130.215.36.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH8zI-0006tv-6c for mip6@ietf.org; Mon, 11 Oct 2004 18:49:55 -0400 Received: from mcafee.wpi.edu (mcafee.WPI.EDU [130.215.36.86]) by mail1.WPI.EDU (8.13.1/8.13.1) with SMTP id i9BMcqpc007482; Mon, 11 Oct 2004 18:38:52 -0400 Received: from smtp.WPI.EDU(130.215.36.186) by mcafee.wpi.edu via csmap id 1b62c9e6_1bd6_11d9_887d_00304811e63a_20280; Mon, 11 Oct 2004 18:37:18 -0400 (EDT) Received: from vespa.wpi.edu (vespa.WPI.EDU [130.215.17.72]) by smtp.WPI.EDU (8.13.1/8.13.1) with ESMTP id i9BMb87r014809; Mon, 11 Oct 2004 18:37:08 -0400 Received: from wjlou1 (wjlou1.ece.WPI.EDU [130.215.16.157]) by vespa.wpi.edu (8.12.11/8.12.11) with ESMTP id i9BMb8XE002252; Mon, 11 Oct 2004 18:37:08 -0400 From: "Wenjing Lou" To: Date: Mon, 11 Oct 2004 18:36:56 -0400 Message-ID: <003701c4afe2$d08763a0$9d10d782@wjlou1> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 12 Oct 2004 08:59:54 -0400 Subject: [Mip6] CFP: MSAN 2005 - First International Conference on Multimedia Services Access Networks X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Content-Transfer-Encoding: quoted-printable +--------------------------------------------------------------------+ Please accept our apologies for multiple copies +--------------------------------------------------------------------+ CALL FOR PAPERS - MSAN 2005 First International Conference on Multimedia Services Access Networks Technically co-sponsored by IEEE Communications Society June 13-15, 2005, Orlando, Florida, USA =20 http://msan.org ** SCOPE ** Access networks (the =91last-=92 or =91first-=92 mile according to = provider=92s or customer=92s perspective) represent one of the most important parts in telecommunication systems, being responsible for the high-quality, reliable and secure delivery of services to end users. They also encompass some of the most demanding networking problems, such as the coexistence of a large variety of technologies based on both wired and wireless solutions, the need of optimal integration with the core network in terms of bandwidth and availability mismatch, the provision of an acceptable quality of service in very different application scenarios and traffic conditions. Perhaps, the most important challenge is that the design of access networks =96 from the analysis of requirements to the implementation and operation of the system =96 can only be successful if it is based on an integrated approach, taking into account the needs of different user groups, the technical constraints posed by different application technologies, as well as the related business and societal aspects. Within this framework, MSAN=9205 is intended to provide a unique international forum to explore the new research frontiers in the field of current and next generation multimedia service access networks. Original unpublished contributions are solicited that can improve the knowledge and practice in the integrated design of efficient access technologies and the relevant provision of advanced multimedia applications. ** TOPICS OF INTEREST ** Topics of interest are organized in three tracks addressing respectively: access network technologies (with particular emphasis on network design methodologies, protocols, analysis of performance and quality of service); multimedia service delivery (mainly focusing on the integration/adaptation between multimedia data processing and transmission techniques and access networks characteristics); implementation, operation and performance (providing an opportunity to present innovative applications and testbeds for the above technologies, as well as new approaches to testing and performance evaluation). Topics of interest include but are not limited to: Track 1: Access technologies and networks in MSANs (technologies and protocols) - Wire-based access (PON, FTTx, xDSL) - Wireless fixed access solutions (802.11x and 802.16 networks) - Mobile and nomadic access (3G and beyond, WiFi, etc.) - Other emerging technologies (power lines, CATV, DOCSIS, FSO) - Integration/migration among different technologies=20 (heterogeneous nets, seamless handover) - Integration with core network - Handling bandwidth and availability mismatch between optical and wireless Track 2: Delivery of multimedia services - Technologies for multimedia-multimodal services=20 - Streaming over IP (VoIP, packet video, rate control, error control) - Scheduling and allocation of network resources (bandwidth=20 allocation, power management, etc.) - Quality of service (at network and application level) - Terminals and devices - Security issues Track 3: MSAN implementation, operation and performance - Testbeds and laboratory experiments - Performance evaluation and measurements - Interoperability of last mile solutions - Case studies of novel networking solutions and services implemented - Application techniques, tools and experiences (e.g., health,=20 tourism, e-government, entertainment) - Specific operation and management issues - Planning and design methodology and tools ** CHAIRS ** General Co-Chairs: Aggelos K. Katsaggelos Northwestern University, USA Csaba A. Szabo BUTE, Budapest, Hungary Technical Program Co-Chairs: Francesco G.B. De Natale Univ. of Trento, Italy Nelson L.S. Fonseca Univ. of Campinas, Brasil Steering Committee Chair: Imrich Chlamtac Create-Net, Italy Local Chair: Ladislau L B=F6l=F6ni Univ. Central Florida, USA Local Vice-Chair: Damla Turgut Univ. Central Florida, USA Workshops Chair: Iacopo Carreras Create-Net, Italy Tutorials & Panels Chair: Viktoria Fodor KTH, Stockolm, Sweden Demo and Exhibit Chair: Scott A. Valcourt Univ. New Hampshire, USA Sponsorship Chair: Jing Deng Univ. New Orleans, LA, USA Publications Chair: Luigi Atzori University of Cagliari, Italy Publicity Co-Chairs: Wenjing Lou Worcester Polytechnic Institute, USA Rolland Vida BUTE, Budapest, Hungary Financial Officer: Karen Decker ICST, USA ** Technical Program Committee ** K. Aizawa, Univ. Tokyo, JPN J. Apostolopoulos, HP Labs, USA M. Barni, Univ. Siena, ITA S. Bregni, Polytechnic Milan, ITA Y. Cai, Iowa State Univ., USA R. Civanlar, Koc Univ., TUR R. Cohen, Technion, ISR E. Delp, Purdue Univ., USA T. Ebrahimi, EPFL, SUI P. Frossard, EPFL, SUI B. Gandhi, Motorola, USA B. Gavish, South. Methodist Univ., USA A. Gelman, Panasonic Research, USA A. Gumaste, Fujitsu Labs., USA N. Jayant, GeorgiaTech, USA M.G. Kang, Yonsei Univ., KOR G. Kramer, Teknovus, USA M. Krunz, Univ. Arizona, USA R. Lagendijk, Delft Univ., NED G. Lemos, Natalnet, BRA T. Miki, NTT DoCoMo, JPN J. Modestino, Univ. Miami, USA A. Pakstas, London Metrop. Univ, GBR T. Pappas, Northwestern Univ., USA G. Pau, UCLA, USA F. Pereira, IST, POR D. Pitt, Univ. Santa Clara, USA C. Regazzoni, Univ. Genova, ITA M. Reisslein, Arizona State Univ., USA J. Roberts, France Telecom R&D, FRA I. Rubin, UCLA, USA Gy. Sallai, BUTE, HUN M.R. Salvador, CPqD Telecom, BRA T. Sikora, Technical Univ. Berlin, GER L.F. Soares, PUC-Rio, BRA W. Tavanapong, Iowa State Univ., USA M. Tekalp, Univ. Rochester, USA D. Tran, Univ. Dayton, USA H. Wang, Qualcomm, USA S. Wright, BellSouth, USA Y. Wang, Polytechnic Univ., USA H. Yu, Panasonic Research, USA Y.-Q. Zhang, Microsoft, USA ** SUBMISSION ** Prospective authors are invited to submit a full paper of no more than five (5) pages including figures and references. Submissions will be accepted only by EDAS electronic submission system, accessible through the conference website. The conference proceedings will be published by IEEE. ** IMPORTANT DATES ** Full papers due (to be received by): February 4, 2005 Notification of acceptance: March 31, 2005 Submission of camera-ready papers: April 30, 2005 ** FURTHER INFORMATION ** For further information, please go to our website: http://msan.org _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Oct 12 09:08:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18052 for ; Tue, 12 Oct 2004 09:08:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHMZO-0004ov-Fd for mip6-web-archive@ietf.org; Tue, 12 Oct 2004 09:20:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHMFx-0008DM-NE; Tue, 12 Oct 2004 08:59:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHAFD-00006t-CQ for mip6@megatron.ietf.org; Mon, 11 Oct 2004 20:10:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12449 for ; Mon, 11 Oct 2004 20:10:20 -0400 (EDT) Received: from palrel12.hp.com ([156.153.255.237]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHAPp-00008E-O4 for mip6@ietf.org; Mon, 11 Oct 2004 20:21:22 -0400 Received: from strtio1.cup.hp.com (strtio1.cup.hp.com [15.13.129.245]) by palrel12.hp.com (Postfix) with ESMTP id 50600400462; Mon, 11 Oct 2004 17:10:17 -0700 (PDT) Received: (from jlau@localhost) by strtio1.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) id RAA10397; Mon, 11 Oct 2004 17:07:41 -0700 (PDT) Date: Mon, 11 Oct 2004 17:07:41 -0700 (PDT) From: Joe Lau Message-Id: <200410120007.RAA10397@strtio1.cup.hp.com> To: Brian.Haley@hp.com Subject: Re: [Mip6] Consensus Call: Standardizing the auth protocol [I-D: draft-ietf-mip6-auth-protocol-00.txt] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 12 Oct 2004 08:59:54 -0400 Cc: mip6@ietf.org, Basavaraj.Patil@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit > The question to the WG is: > > 1. Should we standardize the authentication protocol specified in I-D > draft-ietf-mip6-auth-protocol-00.txt as an alternative (to the > IPSec mechanism specified in RFC3775/6) means to securing the BUs > and BAcks between the MN and HA. Note that this solution is an > additional mechanism for doing registration with an HA and does not > deprecate the currently specified solution. > > Yes [ ] > No [X] - no need to standardize another MIP6 authentication protocol Joe Lau _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Oct 12 09:28:41 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19238 for ; Tue, 12 Oct 2004 09:28:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHMsW-00057m-Ma for mip6-web-archive@ietf.org; Tue, 12 Oct 2004 09:39:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHMaA-0005fz-0Q; Tue, 12 Oct 2004 09:20:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHMSn-0003dm-Vh for mip6@megatron.ietf.org; Tue, 12 Oct 2004 09:13:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18260 for ; Tue, 12 Oct 2004 09:13:12 -0400 (EDT) Received: from ip-10-194-65-202.rev.dyxnet.com ([202.65.194.10] helo=hitachi.cn) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CHMdV-0004ry-QJ for Mip6@ietf.org; Tue, 12 Oct 2004 09:24:20 -0400 Received: (qmail 4861 invoked by uid 104); 12 Oct 2004 13:12:28 -0000 Received: from hdeng@hitachi.cn by hitachihk1 with network-box scanner-1.10 (received+scanned in 5.11655 secs); 12 Oct 2004 13:12:28 -0000 X-Scanned-By-hitachihk1: Virus scan performed by network-box (www.network-box.com) X-Scanned-By-hitachihk1: Scanner file id is hitachihk110975867435114814 X-Scanned-By-hitachihk1: No known viruses found in message (received+scanned in 5.11655 secs) X-Scanned-By-hitachihk1: Spam-Check-Result: No, hits=-88.5 required=7.0 tests=AWL, USER_IN_WHITELIST autolearn=no version=2.63 X-Spam-Status: No Received: from unknown (HELO europa.hitachi.cn) (202.0.122.180) by ip-11-194-65-202.rev.dyxnet.com with SMTP; 12 Oct 2004 13:12:23 -0000 Received: from HCBJDC2.hitachi-china.com ([170.95.81.2]) by europa.hitachi.cn with Microsoft SMTPSVC(5.0.2195.5329); Tue, 12 Oct 2004 21:09:24 +0800 Subject: RE: [Mip6] Consensus Call: Standardizing the auth protocol[I-D:draft-ietf-mip6-auth-protocol-00.txt] MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Date: Tue, 12 Oct 2004 21:09:22 +0800 Message-ID: <834B54D356AA8F46B9B233DD88BEAA381E94E5@hcbjdc2> Thread-Topic: [Mip6] Consensus Call: Standardizing the auth protocol[I-D:draft-ietf-mip6-auth-protocol-00.txt] Thread-Index: AcSshsijcUmpmTg8SmW2kXCJmrnRkwACzQzgAM4e5EAAJIvkUA== From: "DENG, HUI -HCHIBJ" To: "Manning, Serge M [NTK]" , X-OriginalArrivalTime: 12 Oct 2004 13:09:24.0518 (UTC) FILETIME=[B220A460:01C4B05C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable Hi, Manning, May I have one question? what kind of service and application does sprint provide based on = authentication option in your deployed mobile ipv4 network? -Hui -----Original Message----- From: Manning, Serge M [NTK] [mailto:Serge.M.Manning@mail.sprint.com]=20 Sent: 2004?10?12? 3:50 To: Mip6@ietf.org Subject: RE: [Mip6] Consensus Call: Standardizing the auth = protocol[I-D:draft-ietf-mip6-auth-protocol-00.txt] >-----Original Message----- >From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On >Subject: [Mip6] Consensus Call: Standardizing the auth=20 >protocol [I-D:draft-ietf-mip6-auth-protocol-00.txt] The question to the WG is: 1. Should we standardize the authentication protocol specified in I-D draft-ietf-mip6-auth-protocol-00.txt as an alternative (to the IPSec mechanism specified in RFC3775/6) means to securing the BUs and BAcks between the MN and HA. Note that this solution is an additional mechanism for doing registration with an HA and does not deprecate the currently specified solution.=20 Yes [X] No [ ] [Serge] I vote Yes. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Oct 12 10:22:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23132 for ; Tue, 12 Oct 2004 10:22:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHNis-0006KD-Q2 for mip6-web-archive@ietf.org; Tue, 12 Oct 2004 10:33:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHMym-0004Lp-SR; Tue, 12 Oct 2004 09:46:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHMoi-0000is-Gw for mip6@megatron.ietf.org; Tue, 12 Oct 2004 09:35:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19965 for ; Tue, 12 Oct 2004 09:35:51 -0400 (EDT) From: Basavaraj.Patil@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHMzR-0005Il-Q8 for mip6@ietf.org; Tue, 12 Oct 2004 09:46:59 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9CDZeh03133; Tue, 12 Oct 2004 16:35:40 +0300 (EET DST) X-Scanned: Tue, 12 Oct 2004 16:34:54 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i9CDYsLG001984; Tue, 12 Oct 2004 16:34:54 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00KuzAg8; Tue, 12 Oct 2004 16:34:51 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9CDYna06555; Tue, 12 Oct 2004 16:34:50 +0300 (EET DST) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 12 Oct 2004 08:34:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: FW: [Mip6] Consensus Call: Standardizing the auth protocol [I-D:draft-ietf-mip6-auth-protocol-00.txt] Date: Tue, 12 Oct 2004 08:34:34 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF4403B1BF47@daebe007.americas.nokia.com> Thread-Topic: [Mip6] Consensus Call: Standardizing the auth protocol [I-D:draft-ietf-mip6-auth-protocol-00.txt] Thread-Index: AcSskll/9W7TW+1SToyhyTDVwGR9cQABTVggAPIhv6A= To: X-OriginalArrivalTime: 12 Oct 2004 13:34:34.0591 (UTC) FILETIME=[36337EF0:01C4B060] X-Spam-Score: 0.3 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: quoted-printable Cc: Mark.A.Lipford@mail.sprint.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: quoted-printable Forwarding this email from Mark (by request) since his original email does not seem to have made it to the list. -BPa > -----Original Message----- > From: ext Lipford, Mark A [NTK]=20 > [mailto:Mark.A.Lipford@mail.sprint.com] > Sent: Thursday, October 07, 2004 1:01 PM > To: Alpesh; Patil Basavaraj (Nokia-NET/Dallas) > Cc: mip6@ietf.org > Subject: RE: [Mip6] Consensus Call: Standardizing the auth protocol > [I-D:draft-ietf-mip6-auth-protocol-00.txt] >=20 >=20 > I agree, a YES for me too. >=20 > Mark A. Lipford=20 > Manager, Sprint Industry Standards=20 > 6220 Sprint Parkway (Eisenhower C)=20 > Mailstop: KSOPHD0504-5D128=20 > Overland Park, KS 66251-6118=20 >=20 > (913) 794-3764 (office)=20 > (913) 794-0420 (fax)=20 > (913) 579-2319 (mobile)=20 > Mark.A.Lipford@mail.sprint.com=20 >=20 >=20 > -----Original Message----- > From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On=20 > Behalf Of > Alpesh > Sent: Thursday, October 07, 2004 11:45 AM > To: Basavaraj.Patil@nokia.com > Cc: mip6@ietf.org > Subject: Re: [Mip6] Consensus Call: Standardizing the auth protocol > [I-D:draft-ietf-mip6-auth-protocol-00.txt] >=20 > My vote is YES for the draft. >=20 > -a >=20 > Basavaraj.Patil@nokia.com wrote: >=20 > >This is a consensus call to the WG on the issue of standardizing the > >authentication-data-suboption mechanism for performing a binding > between the > >MN and HA. The issue has been discussed on the WG mailing list over > >the last few weeks. The I-D > >(draft-patil-mip6-whyauthdataoption-00.txt) has captured some of the > >arguments, but there are several others that have been made on the > >list as well. A summary of the discussion was sent out earlier and is > >captured in : > >http://www1.ietf.org/mail-archive/web/mip6/current/msg01690.html > > > >The proposal here (in brief) is to standardize a mechanism specified > >in I-D draft-ietf-mip6-auth-protocol-00.txt for performing MIP6 > >registration with a home agent. RFC3775 specifies the use of IPsec to > >secure the binding update/ACK messages between the MN and HA. The > >auth-protocol mechanism relies on the use of an > >authentication-data-suboption and does not require the MN-HA to > >establish an IPsec SA. =20 > >(For the discussion that has ensued so far, please refer to the MIP6 > >ML archives) > > > >The question to the WG is: > > > >1. Should we standardize the authentication protocol specified in I-D > > draft-ietf-mip6-auth-protocol-00.txt as an alternative (to the > > IPSec mechanism specified in RFC3775/6) means to securing the BUs > > and BAcks between the MN and HA. Note that this solution is an > > additional mechanism for doing registration with an HA=20 > and does not > > deprecate the currently specified solution.=20 > > > > Yes [ ] > > No [ ] > > > > > >The consensus call will close on October 12th, 2004. > > > >-Chairs > > > >_______________________________________________ > >Mip6 mailing list > >Mip6@ietf.org > >https://www1.ietf.org/mailman/listinfo/mip6 > > > > =20 > > >=20 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Oct 12 10:41:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25511 for ; Tue, 12 Oct 2004 10:41:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHO0s-0006gF-CV for mip6-web-archive@ietf.org; Tue, 12 Oct 2004 10:52:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHNj8-0002Rd-8A; Tue, 12 Oct 2004 10:34:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHNWZ-0006iP-RV for mip6@megatron.ietf.org; Tue, 12 Oct 2004 10:21:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22541 for ; Tue, 12 Oct 2004 10:21:09 -0400 (EDT) Received: from ip-10-194-65-202.rev.dyxnet.com ([202.65.194.10] helo=hitachi.cn) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CHNe9-00060s-B4 for Mip6@ietf.org; Tue, 12 Oct 2004 10:29:03 -0400 Received: (qmail 6274 invoked by uid 104); 12 Oct 2004 14:10:40 -0000 Received: from hdeng@hitachi.cn by hitachihk1 with network-box scanner-1.10 (received+scanned in 5.557808 secs); 12 Oct 2004 14:10:40 -0000 X-Scanned-By-hitachihk1: Virus scan performed by network-box (www.network-box.com) X-Scanned-By-hitachihk1: Scanner file id is hitachihk110975902355116243 X-Scanned-By-hitachihk1: No known viruses found in message (received+scanned in 5.557808 secs) X-Scanned-By-hitachihk1: Spam-Check-Result: No, hits=-88.8 required=7.0 tests=AWL, USER_IN_WHITELIST autolearn=no version=2.63 X-Spam-Status: No Received: from unknown (HELO europa.hitachi.cn) (202.0.122.180) by ip-11-194-65-202.rev.dyxnet.com with SMTP; 12 Oct 2004 14:10:34 -0000 Received: from HCBJDC2.hitachi-china.com ([170.95.81.2]) by europa.hitachi.cn with Microsoft SMTPSVC(5.0.2195.5329); Tue, 12 Oct 2004 22:09:48 +0800 Subject: RE: [Mip6] Consensus Call: Standardizing the auth protocol[I-D:draft-ietf-mip6-auth-protocol-00.txt] MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Date: Tue, 12 Oct 2004 22:09:47 +0800 Message-ID: <834B54D356AA8F46B9B233DD88BEAA3804D3F6@hcbjdc2> Thread-Topic: [Mip6] Consensus Call: Standardizing the auth protocol[I-D:draft-ietf-mip6-auth-protocol-00.txt] Thread-Index: AcSshsijcUmpmTg8SmW2kXCJmrnRkwACzQzgAM4e5EAAJIvkUAAAv/cQAABdw4AAAHPHUAAASP5Q From: "DENG, HUI -HCHIBJ" To: "Manning, Serge M [NTK]" , X-OriginalArrivalTime: 12 Oct 2004 14:09:48.0893 (UTC) FILETIME=[226C60D0:01C4B065] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: quoted-printable X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: quoted-printable Sorry I have so many questions. but anyway, if not confidential, can you tell me how many subscribers = are using this service now? -----Original Message----- From: Manning, Serge M [NTK] [mailto:Serge.M.Manning@mail.sprint.com]=20 Sent: 2004?10?12? 21:57 To: DENG, HUI -HCHIBJ; Mip6@ietf.org Subject: RE: [Mip6] Consensus Call: Standardizing the auth = protocol[I-D:draft-ietf-mip6-auth-protocol-00.txt] We really use Mobile IP service as it provides handoffs as the user = moves across radio networks. During an entire session, MIP is used to = maintain connectivity and keep the same IP address. --Serge -----Original Message----- From: DENG, HUI -HCHIBJ [mailto:hdeng@hitachi.cn]=20 Sent: Tuesday, October 12, 2004 8:45 AM To: Manning, Serge M [NTK]; Mip6@ietf.org Subject: RE: [Mip6] Consensus Call: Standardizing the auth = protocol[I-D:draft-ietf-mip6-auth-protocol-00.txt] In the case of packet data internet service over cellular and Sprint specific service for mobile phones, do you really use Mobile IPv4 service? or just use basic simple IPv4 address to transmit data? -Hui -----Original Message----- From: Manning, Serge M [NTK] [mailto:Serge.M.Manning@mail.sprint.com]=20 Sent: 2004?10?12? 21:33 To: DENG, HUI -HCHIBJ; Mip6@ietf.org Subject: RE: [Mip6] Consensus Call: Standardizing the auth = protocol[I-D:draft-ietf-mip6-auth-protocol-00.txt] We provide the basic packet data Internet service over cellular (similar = to GPRS) as well as Sprint specific services to mobile handsets (similar = to iMode types of service). --Serge -----Original Message----- From: DENG, HUI -HCHIBJ [mailto:hdeng@hitachi.cn]=20 Sent: Tuesday, October 12, 2004 8:09 AM To: Manning, Serge M [NTK]; Mip6@ietf.org Subject: RE: [Mip6] Consensus Call: Standardizing the auth = protocol[I-D:draft-ietf-mip6-auth-protocol-00.txt] Hi, Manning, May I have one question? what kind of service and application does sprint provide based on = authentication option in your deployed mobile ipv4 network? -Hui -----Original Message----- From: Manning, Serge M [NTK] [mailto:Serge.M.Manning@mail.sprint.com]=20 Sent: 2004?10?12? 3:50 To: Mip6@ietf.org Subject: RE: [Mip6] Consensus Call: Standardizing the auth = protocol[I-D:draft-ietf-mip6-auth-protocol-00.txt] >-----Original Message----- >From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On >Subject: [Mip6] Consensus Call: Standardizing the auth protocol=20 >[I-D:draft-ietf-mip6-auth-protocol-00.txt] The question to the WG is: 1. Should we standardize the authentication protocol specified in I-D draft-ietf-mip6-auth-protocol-00.txt as an alternative (to the IPSec mechanism specified in RFC3775/6) means to securing the BUs and BAcks between the MN and HA. Note that this solution is an additional mechanism for doing registration with an HA and does not deprecate the currently specified solution.=20 Yes [X] No [ ] [Serge] I vote Yes. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Oct 12 10:46:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26037 for ; Tue, 12 Oct 2004 10:46:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHO64-0006mY-8b for mip6-web-archive@ietf.org; Tue, 12 Oct 2004 10:57:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHNjC-0002Wu-OI; Tue, 12 Oct 2004 10:34:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHNWq-0006my-0g for mip6@megatron.ietf.org; Tue, 12 Oct 2004 10:21:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22720 for ; Tue, 12 Oct 2004 10:21:23 -0400 (EDT) Received: from ip-10-194-65-202.rev.dyxnet.com ([202.65.194.10] helo=hitachi.cn) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CHNaa-0005qn-9W for Mip6@ietf.org; Tue, 12 Oct 2004 10:25:42 -0400 Received: (qmail 31367 invoked by uid 104); 12 Oct 2004 13:46:56 -0000 Received: from hdeng@hitachi.cn by hitachihk1 with network-box scanner-1.10 (received+scanned in 7.85917 secs); 12 Oct 2004 13:46:56 -0000 X-Scanned-By-hitachihk1: Virus scan performed by network-box (www.network-box.com) X-Scanned-By-hitachihk1: Scanner file id is hitachihk1109758880851131325 X-Scanned-By-hitachihk1: No known viruses found in message (received+scanned in 7.85917 secs) X-Scanned-By-hitachihk1: Spam-Check-Result: No, hits=-88.6 required=7.0 tests=AWL, USER_IN_WHITELIST autolearn=no version=2.63 X-Spam-Status: No Received: from unknown (HELO europa.hitachi.cn) (202.0.122.180) by ip-11-194-65-202.rev.dyxnet.com with SMTP; 12 Oct 2004 13:46:48 -0000 Received: from HCBJDC2.hitachi-china.com ([170.95.81.2]) by europa.hitachi.cn with Microsoft SMTPSVC(5.0.2195.5329); Tue, 12 Oct 2004 21:45:52 +0800 Subject: RE: [Mip6] Consensus Call: Standardizing the auth protocol[I-D:draft-ietf-mip6-auth-protocol-00.txt] MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Date: Tue, 12 Oct 2004 21:45:17 +0800 Message-ID: <834B54D356AA8F46B9B233DD88BEAA3804D3F5@hcbjdc2> Thread-Topic: [Mip6] Consensus Call: Standardizing the auth protocol[I-D:draft-ietf-mip6-auth-protocol-00.txt] Thread-Index: AcSshsijcUmpmTg8SmW2kXCJmrnRkwACzQzgAM4e5EAAJIvkUAAAv/cQAABdw4A= From: "DENG, HUI -HCHIBJ" To: "Manning, Serge M [NTK]" , X-OriginalArrivalTime: 12 Oct 2004 13:45:52.0643 (UTC) FILETIME=[CA5A0530:01C4B061] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: quoted-printable In the case of packet data internet service over cellular and Sprint specific service for mobile phones, do you really use Mobile IPv4 service? or just use basic simple IPv4 address to transmit data? -Hui -----Original Message----- From: Manning, Serge M [NTK] [mailto:Serge.M.Manning@mail.sprint.com]=20 Sent: 2004?10?12? 21:33 To: DENG, HUI -HCHIBJ; Mip6@ietf.org Subject: RE: [Mip6] Consensus Call: Standardizing the auth = protocol[I-D:draft-ietf-mip6-auth-protocol-00.txt] We provide the basic packet data Internet service over cellular (similar = to GPRS) as well as Sprint specific services to mobile handsets (similar = to iMode types of service). --Serge -----Original Message----- From: DENG, HUI -HCHIBJ [mailto:hdeng@hitachi.cn]=20 Sent: Tuesday, October 12, 2004 8:09 AM To: Manning, Serge M [NTK]; Mip6@ietf.org Subject: RE: [Mip6] Consensus Call: Standardizing the auth = protocol[I-D:draft-ietf-mip6-auth-protocol-00.txt] Hi, Manning, May I have one question? what kind of service and application does sprint provide based on = authentication option in your deployed mobile ipv4 network? -Hui -----Original Message----- From: Manning, Serge M [NTK] [mailto:Serge.M.Manning@mail.sprint.com]=20 Sent: 2004?10?12? 3:50 To: Mip6@ietf.org Subject: RE: [Mip6] Consensus Call: Standardizing the auth = protocol[I-D:draft-ietf-mip6-auth-protocol-00.txt] >-----Original Message----- >From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On >Subject: [Mip6] Consensus Call: Standardizing the auth >protocol [I-D:draft-ietf-mip6-auth-protocol-00.txt] The question to the WG is: 1. Should we standardize the authentication protocol specified in I-D draft-ietf-mip6-auth-protocol-00.txt as an alternative (to the IPSec mechanism specified in RFC3775/6) means to securing the BUs and BAcks between the MN and HA. Note that this solution is an additional mechanism for doing registration with an HA and does not deprecate the currently specified solution.=20 Yes [X] No [ ] [Serge] I vote Yes. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Oct 12 12:04:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03653 for ; Tue, 12 Oct 2004 12:04:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHP7w-0008H2-Tu for mip6-web-archive@ietf.org; Tue, 12 Oct 2004 12:03:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHOmW-0004Uh-4D; Tue, 12 Oct 2004 11:41:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHOfA-00030O-Tk for mip6@megatron.ietf.org; Tue, 12 Oct 2004 11:34:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01548 for ; Tue, 12 Oct 2004 11:34:06 -0400 (EDT) Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHOpv-0007qt-Re for mip6@ietf.org; Tue, 12 Oct 2004 11:45:16 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i9CFXsbv002936; Wed, 13 Oct 2004 00:33:54 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i9CFXsON013676; Wed, 13 Oct 2004 00:33:54 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id AAA13675 ; Wed, 13 Oct 2004 00:33:54 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id AAA12399; Wed, 13 Oct 2004 00:33:54 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id i9CFXrrf024052; Wed, 13 Oct 2004 00:33:53 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i9CFXrXU006194; Wed, 13 Oct 2004 00:33:53 +0900 (JST) Received: from steelhead ([172.30.24.114]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0I5H007ZP9WECA@tsbpo1.po.toshiba.co.jp>; Wed, 13 Oct 2004 00:33:52 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1CHC5V-00052R-00; Mon, 11 Oct 2004 19:08:29 -0700 Date: Mon, 11 Oct 2004 22:08:29 -0400 From: Yoshihiro Ohba Subject: Re: [Mip6] Consensus Call: Standardizing the auth protocol [I-D: draft-ietf-mip6-auth-protocol-00.txt] In-reply-to: <697DAA22C5004B4596E033803A7CEF4403B1BF01@daebe007.americas.nokia.com> To: Basavaraj.Patil@nokia.com Message-id: <20041012020829.GT1488@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i References: <697DAA22C5004B4596E033803A7CEF4403B1BF01@daebe007.americas.nokia.com> X-Spam-Score: 0.4 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 On Wed, Oct 06, 2004 at 05:02:55PM -0500, Basavaraj.Patil@nokia.com wrote: > > The question to the WG is: > > 1. Should we standardize the authentication protocol specified in I-D > draft-ietf-mip6-auth-protocol-00.txt as an alternative (to the > IPSec mechanism specified in RFC3775/6) means to securing the BUs > and BAcks between the MN and HA. Note that this solution is an > additional mechanism for doing registration with an HA and does not > deprecate the currently specified solution. > > Yes [ ] > No [X] Note that while I did not express my opinion on the mailing list, I expressed my opinion in terms of re-keying in the last MIP6 WG meeting. Yoshihiro Ohba > > > The consensus call will close on October 12th, 2004. > > -Chairs > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Oct 12 13:25:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11005 for ; Tue, 12 Oct 2004 13:25:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHQZI-0002jF-Vy for mip6-web-archive@ietf.org; Tue, 12 Oct 2004 13:36:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHQD6-0003IO-GF; Tue, 12 Oct 2004 13:13:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHQ44-0000tB-6W for mip6@megatron.ietf.org; Tue, 12 Oct 2004 13:03:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09057 for ; Tue, 12 Oct 2004 13:03:53 -0400 (EDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHQEq-0002GD-JX for mip6@ietf.org; Tue, 12 Oct 2004 13:15:05 -0400 Received: from jurassic.eng.sun.com ([129.146.87.130]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i9CH3sui007709; Tue, 12 Oct 2004 11:03:54 -0600 (MDT) Received: from shubho (shubho.SFBay.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.13.1+Sun/8.13.1) with SMTP id i9CH3r84748830; Tue, 12 Oct 2004 10:03:54 -0700 (PDT) Message-Id: <200410121703.i9CH3r84748830@jurassic.eng.sun.com> Date: Tue, 12 Oct 2004 10:04:52 -0700 (PDT) From: Samita Chakrabarti Subject: FW: [Mip6] Consensus Call: Standardizing the auth protocol [I-D:draft-ietf-mip6-auth-protocol-00.txt] To: mip6@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Ksw6QztmKeQDWd2GfK78UA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_53 SunOS 5.10 sun4u sparc X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Basavaraj.Patil@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Samita Chakrabarti List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 > > Basavaraj.Patil@nokia.com wrote: > > >This is a consensus call to the WG on the issue of standardizing the > >authentication-data-suboption mechanism for performing a binding > between the > >MN and HA. The issue has been discussed on the WG mailing list over > >the last few weeks. The I-D > >(draft-patil-mip6-whyauthdataoption-00.txt) has captured some of the > >arguments, but there are several others that have been made on the > >list as well. A summary of the discussion was sent out earlier and is > >captured in : > >http://www1.ietf.org/mail-archive/web/mip6/current/msg01690.html > > > >The proposal here (in brief) is to standardize a mechanism specified > >in I-D draft-ietf-mip6-auth-protocol-00.txt for performing MIP6 > >registration with a home agent. RFC3775 specifies the use of IPsec to > >secure the binding update/ACK messages between the MN and HA. The > >auth-protocol mechanism relies on the use of an > >authentication-data-suboption and does not require the MN-HA to > >establish an IPsec SA. > >(For the discussion that has ensued so far, please refer to the MIP6 > >ML archives) > > > >The question to the WG is: > > > >1. Should we standardize the authentication protocol specified in I-D > > draft-ietf-mip6-auth-protocol-00.txt as an alternative (to the > > IPSec mechanism specified in RFC3775/6) means to securing the BUs > > and BAcks between the MN and HA. Note that this solution is an > > additional mechanism for doing registration with an HA > and does not > > deprecate the currently specified solution. > > > > Yes [ ] > > No [ ] > > > > > >The consensus call will close on October 12th, 2004. > > > >-Chairs My vote is : No [X] to the above question. I have read *whyauthdataoption* draft and I understand that draft-ietf-mip6-auth-protocol-00.txt [ similar to MIPv4 authentication ] is easily deployable in 3GPP2 network rather than IPSec/IKE as specified in the base MIPv6 RFCs. I am not convinced that the auth-protocol draft is the solution for the issues and hence standardization. I am OK with an informational RFC or experimental one for the 3GPP2 usage. Regards, -Samita _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Oct 12 13:25:42 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11071 for ; Tue, 12 Oct 2004 13:25:42 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHQZw-0002k0-Va for mip6-web-archive@ietf.org; Tue, 12 Oct 2004 13:36:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHQD7-0003IV-1b; Tue, 12 Oct 2004 13:13:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHQ44-0000tD-HR for mip6@megatron.ietf.org; Tue, 12 Oct 2004 13:03:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09060 for ; Tue, 12 Oct 2004 13:03:54 -0400 (EDT) Received: from smtp813.mail.sc5.yahoo.com ([66.163.170.83]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CHQEq-0002GC-OZ for mip6@ietf.org; Tue, 12 Oct 2004 13:15:05 -0400 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.17.134 with login) by smtp813.mail.sc5.yahoo.com with SMTP; 12 Oct 2004 16:36:13 -0000 Message-ID: <006901c4b079$96847110$861167c0@adithya> From: "Mohan Parthasarathy" To: , References: <697DAA22C5004B4596E033803A7CEF4403B1BF01@daebe007.americas.nokia.com> Subject: Re: [Mip6] Consensus Call: Standardizing the auth protocol [I-D:draft-ietf-mip6-auth-protocol-00.txt] Date: Tue, 12 Oct 2004 09:36:13 -0700 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.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit No. I would vote for an informational draft for3gpp2. -mohan ----- Original Message ----- From: To: Sent: Wednesday, October 06, 2004 3:02 PM Subject: [Mip6] Consensus Call: Standardizing the auth protocol [I-D:draft-ietf-mip6-auth-protocol-00.txt] This is a consensus call to the WG on the issue of standardizing the authentication-data-suboption mechanism for performing a binding between the MN and HA. The issue has been discussed on the WG mailing list over the last few weeks. The I-D (draft-patil-mip6-whyauthdataoption-00.txt) has captured some of the arguments, but there are several others that have been made on the list as well. A summary of the discussion was sent out earlier and is captured in : http://www1.ietf.org/mail-archive/web/mip6/current/msg01690.html The proposal here (in brief) is to standardize a mechanism specified in I-D draft-ietf-mip6-auth-protocol-00.txt for performing MIP6 registration with a home agent. RFC3775 specifies the use of IPsec to secure the binding update/ACK messages between the MN and HA. The auth-protocol mechanism relies on the use of an authentication-data-suboption and does not require the MN-HA to establish an IPsec SA. (For the discussion that has ensued so far, please refer to the MIP6 ML archives) The question to the WG is: 1. Should we standardize the authentication protocol specified in I-D draft-ietf-mip6-auth-protocol-00.txt as an alternative (to the IPSec mechanism specified in RFC3775/6) means to securing the BUs and BAcks between the MN and HA. Note that this solution is an additional mechanism for doing registration with an HA and does not deprecate the currently specified solution. Yes [ ] No [ ] The consensus call will close on October 12th, 2004. -Chairs _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Oct 12 17:58:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19639 for ; Tue, 12 Oct 2004 17:58:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHUqS-0004ph-1Z for mip6-web-archive@ietf.org; Tue, 12 Oct 2004 18:10:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHUSp-0006SN-5s; Tue, 12 Oct 2004 17:45:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHMnL-0000eE-Jl for mip6@megatron.ietf.org; Tue, 12 Oct 2004 09:34:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19843 for ; Tue, 12 Oct 2004 09:34:26 -0400 (EDT) Received: from mail-kan.bigfish.com ([63.161.60.29] helo=mail7-kan-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHMy5-0005Fo-6D for Mip6@ietf.org; Tue, 12 Oct 2004 09:45:34 -0400 Received: from mail7-kan.bigfish.com (localhost.localdomain [127.0.0.1]) by mail7-kan-R.bigfish.com (Postfix) with ESMTP id C20D01CCE45; Tue, 12 Oct 2004 13:33:53 +0000 (UCT) X-BigFish: VC Received: by mail7-kan (MessageSwitch) id 1097588033775187_32495; Tue, 12 Oct 2004 13:33:53 +0000 (UCT) Received: from smtpgw6.it.sprintspectrum.com (smtpgw6.sprintspectrum.com [207.40.188.14]) by mail7-kan.bigfish.com (Postfix) with ESMTP id 9AAD91CCA09; Tue, 12 Oct 2004 13:33:53 +0000 (UCT) Received: from mailhost.sprintspectrum.com (smtpgw8.it.sprintspectrum.com [207.40.65.56]) by smtpgw6.it.sprintspectrum.com (8.12.11.Beta0/8.12.8) with ESMTP id i9CDXrQS018419; Tue, 12 Oct 2004 08:33:53 -0500 (CDT) Received: from PKDWG01A.ad.sprint.com (PKDWG01A.corp.sprint.com [10.185.12.78]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9CDXrm00858; Tue, 12 Oct 2004 08:33:53 -0500 (CDT) Received: from pkdwb02c.ad.sprint.com ([10.185.12.26]) by PKDWG01A.ad.sprint.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 12 Oct 2004 08:32:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Consensus Call: Standardizing the auth protocol[I-D:draft-ietf-mip6-auth-protocol-00.txt] Date: Tue, 12 Oct 2004 08:32:33 -0500 Message-ID: <2E8819C3F495D147B3F2FC41EF231CE40D424724@PKDWB02C.ad.sprint.com> Thread-Topic: [Mip6] Consensus Call: Standardizing the auth protocol[I-D:draft-ietf-mip6-auth-protocol-00.txt] thread-index: AcSshsijcUmpmTg8SmW2kXCJmrnRkwACzQzgAM4e5EAAJIvkUAAAv/cQ From: "Manning, Serge M [NTK]" To: "DENG, HUI -HCHIBJ" , X-OriginalArrivalTime: 12 Oct 2004 13:32:34.0163 (UTC) FILETIME=[EE6BA430:01C4B05F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 12 Oct 2004 17:45:45 -0400 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable We provide the basic packet data Internet service over cellular (similar to GPRS) as well as Sprint specific services to mobile handsets (similar to iMode types of service). --Serge -----Original Message----- From: DENG, HUI -HCHIBJ [mailto:hdeng@hitachi.cn]=20 Sent: Tuesday, October 12, 2004 8:09 AM To: Manning, Serge M [NTK]; Mip6@ietf.org Subject: RE: [Mip6] Consensus Call: Standardizing the auth protocol[I-D:draft-ietf-mip6-auth-protocol-00.txt] Hi, Manning, May I have one question? what kind of service and application does sprint provide based on authentication option in your deployed mobile ipv4 network? -Hui -----Original Message----- From: Manning, Serge M [NTK] [mailto:Serge.M.Manning@mail.sprint.com]=20 Sent: 2004?10?12? 3:50 To: Mip6@ietf.org Subject: RE: [Mip6] Consensus Call: Standardizing the auth protocol[I-D:draft-ietf-mip6-auth-protocol-00.txt] >-----Original Message----- >From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On >Subject: [Mip6] Consensus Call: Standardizing the auth=20 >protocol [I-D:draft-ietf-mip6-auth-protocol-00.txt] The question to the WG is: 1. Should we standardize the authentication protocol specified in I-D draft-ietf-mip6-auth-protocol-00.txt as an alternative (to the IPSec mechanism specified in RFC3775/6) means to securing the BUs and BAcks between the MN and HA. Note that this solution is an additional mechanism for doing registration with an HA and does not deprecate the currently specified solution.=20 Yes [X] No [ ] [Serge] I vote Yes. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Oct 12 17:59:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19699 for ; Tue, 12 Oct 2004 17:59:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHUqz-0004qD-Ne for mip6-web-archive@ietf.org; Tue, 12 Oct 2004 18:10:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHUSp-0006SS-Iy; Tue, 12 Oct 2004 17:45:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHNYi-0007KQ-Ak for mip6@megatron.ietf.org; Tue, 12 Oct 2004 10:23:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23229 for ; Tue, 12 Oct 2004 10:23:22 -0400 (EDT) Received: from mail-res.bigfish.com ([63.161.60.61] helo=mail55-res-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHNjP-0006KO-MW for Mip6@ietf.org; Tue, 12 Oct 2004 10:34:31 -0400 Received: from mail55-res.bigfish.com (localhost.localdomain [127.0.0.1]) by mail55-res-R.bigfish.com (Postfix) with ESMTP id A0FBA4DD756; Tue, 12 Oct 2004 13:57:50 +0000 (UCT) X-BigFish: VC Received: by mail55-res.bigfish.com (MessageSwitch) id 1097589470572463_1343; Tue, 12 Oct 2004 13:57:50 +0000 (UCT) Received: from smtpgw5.sprintspectrum.com (smtpgw5.sprintspectrum.com [207.40.188.13]) by mail55-res.bigfish.com (Postfix) with ESMTP id 6D1D04DD787; Tue, 12 Oct 2004 13:57:50 +0000 (UCT) Received: from mailhost.sprintspectrum.com (smtpgw7.it.sprintspectrum.com [207.40.65.55]) by smtpgw5.sprintspectrum.com (8.12.10/8.12.8) with ESMTP id i9CDvnaY019706; Tue, 12 Oct 2004 08:57:49 -0500 (CDT) Received: from PKDWG02A.ad.sprint.com (PKDWG02A.corp.sprint.com [10.185.12.80]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9CDvmx12125; Tue, 12 Oct 2004 08:57:48 -0500 (CDT) Received: from pkdwb02c.ad.sprint.com ([10.185.12.26]) by PKDWG02A.ad.sprint.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 12 Oct 2004 08:56:45 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Consensus Call: Standardizing the auth protocol[I-D:draft-ietf-mip6-auth-protocol-00.txt] Date: Tue, 12 Oct 2004 08:56:45 -0500 Message-ID: <2E8819C3F495D147B3F2FC41EF231CE40D42475C@PKDWB02C.ad.sprint.com> Thread-Topic: [Mip6] Consensus Call: Standardizing the auth protocol[I-D:draft-ietf-mip6-auth-protocol-00.txt] thread-index: AcSshsijcUmpmTg8SmW2kXCJmrnRkwACzQzgAM4e5EAAJIvkUAAAv/cQAABdw4AAAHPHUA== From: "Manning, Serge M [NTK]" To: "DENG, HUI -HCHIBJ" , X-OriginalArrivalTime: 12 Oct 2004 13:56:45.0937 (UTC) FILETIME=[4FBEC610:01C4B063] X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 12 Oct 2004 17:45:45 -0400 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: quoted-printable We really use Mobile IP service as it provides handoffs as the user moves across radio networks. During an entire session, MIP is used to maintain connectivity and keep the same IP address. --Serge -----Original Message----- From: DENG, HUI -HCHIBJ [mailto:hdeng@hitachi.cn]=20 Sent: Tuesday, October 12, 2004 8:45 AM To: Manning, Serge M [NTK]; Mip6@ietf.org Subject: RE: [Mip6] Consensus Call: Standardizing the auth protocol[I-D:draft-ietf-mip6-auth-protocol-00.txt] In the case of packet data internet service over cellular and Sprint specific service for mobile phones, do you really use Mobile IPv4 service? or just use basic simple IPv4 address to transmit data? -Hui -----Original Message----- From: Manning, Serge M [NTK] [mailto:Serge.M.Manning@mail.sprint.com]=20 Sent: 2004?10?12? 21:33 To: DENG, HUI -HCHIBJ; Mip6@ietf.org Subject: RE: [Mip6] Consensus Call: Standardizing the auth protocol[I-D:draft-ietf-mip6-auth-protocol-00.txt] We provide the basic packet data Internet service over cellular (similar to GPRS) as well as Sprint specific services to mobile handsets (similar to iMode types of service). --Serge -----Original Message----- From: DENG, HUI -HCHIBJ [mailto:hdeng@hitachi.cn]=20 Sent: Tuesday, October 12, 2004 8:09 AM To: Manning, Serge M [NTK]; Mip6@ietf.org Subject: RE: [Mip6] Consensus Call: Standardizing the auth protocol[I-D:draft-ietf-mip6-auth-protocol-00.txt] Hi, Manning, May I have one question? what kind of service and application does sprint provide based on authentication option in your deployed mobile ipv4 network? -Hui -----Original Message----- From: Manning, Serge M [NTK] [mailto:Serge.M.Manning@mail.sprint.com]=20 Sent: 2004?10?12? 3:50 To: Mip6@ietf.org Subject: RE: [Mip6] Consensus Call: Standardizing the auth protocol[I-D:draft-ietf-mip6-auth-protocol-00.txt] >-----Original Message----- >From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On >Subject: [Mip6] Consensus Call: Standardizing the auth >protocol [I-D:draft-ietf-mip6-auth-protocol-00.txt] The question to the WG is: 1. Should we standardize the authentication protocol specified in I-D draft-ietf-mip6-auth-protocol-00.txt as an alternative (to the IPSec mechanism specified in RFC3775/6) means to securing the BUs and BAcks between the MN and HA. Note that this solution is an additional mechanism for doing registration with an HA and does not deprecate the currently specified solution.=20 Yes [X] No [ ] [Serge] I vote Yes. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Oct 12 18:00:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19731 for ; Tue, 12 Oct 2004 18:00:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHUrR-0004qs-Dp for mip6-web-archive@ietf.org; Tue, 12 Oct 2004 18:11:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHUSp-0006SX-Ve; Tue, 12 Oct 2004 17:45:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHOhF-0003LX-PW for mip6@megatron.ietf.org; Tue, 12 Oct 2004 11:36:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01707 for ; Tue, 12 Oct 2004 11:36:16 -0400 (EDT) Received: from mail-ash.bigfish.com ([206.16.192.253] helo=mail37-ash-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHOs1-0007tL-FT for Mip6@ietf.org; Tue, 12 Oct 2004 11:47:25 -0400 Received: from mail37-ash.bigfish.com (localhost.localdomain [127.0.0.1]) by mail37-ash-R.bigfish.com (Postfix) with ESMTP id 0D14756C91D; Tue, 12 Oct 2004 15:35:44 +0000 (UCT) X-BigFish: VC Received: by mail37-ash (MessageSwitch) id 1097595343962816_8114; Tue, 12 Oct 2004 15:35:43 +0000 (UCT) Received: from smtpgw5.sprintspectrum.com (smtpgw5.sprintspectrum.com [207.40.188.13]) by mail37-ash.bigfish.com (Postfix) with ESMTP id 7459F56C8F6; Tue, 12 Oct 2004 15:35:43 +0000 (UCT) Received: from mailhost.sprintspectrum.com (smtpgw8.it.sprintspectrum.com [207.40.65.56]) by smtpgw5.sprintspectrum.com (8.12.10/8.12.8) with ESMTP id i9CFZcaY024279; Tue, 12 Oct 2004 10:35:43 -0500 (CDT) Received: from PKDWG01A.ad.sprint.com (PKDWG01A.corp.sprint.com [10.185.12.78]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9CFYCm25748; Tue, 12 Oct 2004 10:34:12 -0500 (CDT) Received: from pkdwb02c.ad.sprint.com ([10.185.12.26]) by PKDWG01A.ad.sprint.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 12 Oct 2004 10:33:51 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Consensus Call: Standardizing the auth protocol[I-D:draft-ietf-mip6-auth-protocol-00.txt] Date: Tue, 12 Oct 2004 10:33:51 -0500 Message-ID: <2E8819C3F495D147B3F2FC41EF231CE40D42485F@PKDWB02C.ad.sprint.com> Thread-Topic: [Mip6] Consensus Call: Standardizing the auth protocol[I-D:draft-ietf-mip6-auth-protocol-00.txt] thread-index: AcSshsijcUmpmTg8SmW2kXCJmrnRkwACzQzgAM4e5EAAJIvkUAAAv/cQAABdw4AAAHPHUAAASP5QAAMvOxA= From: "Manning, Serge M [NTK]" To: "DENG, HUI -HCHIBJ" , X-OriginalArrivalTime: 12 Oct 2004 15:33:51.0585 (UTC) FILETIME=[E01A1D10:01C4B070] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 12 Oct 2004 17:45:45 -0400 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: quoted-printable Sorry I cannot discuss that. --Serge -----Original Message----- From: DENG, HUI -HCHIBJ [mailto:hdeng@hitachi.cn]=20 Sent: Tuesday, October 12, 2004 9:10 AM To: Manning, Serge M [NTK]; Mip6@ietf.org Subject: RE: [Mip6] Consensus Call: Standardizing the auth protocol[I-D:draft-ietf-mip6-auth-protocol-00.txt] Sorry I have so many questions. but anyway, if not confidential, can you tell me how many subscribers are using this service now? -----Original Message----- From: Manning, Serge M [NTK] [mailto:Serge.M.Manning@mail.sprint.com]=20 Sent: 2004?10?12? 21:57 To: DENG, HUI -HCHIBJ; Mip6@ietf.org Subject: RE: [Mip6] Consensus Call: Standardizing the auth protocol[I-D:draft-ietf-mip6-auth-protocol-00.txt] We really use Mobile IP service as it provides handoffs as the user moves across radio networks. During an entire session, MIP is used to maintain connectivity and keep the same IP address. --Serge -----Original Message----- From: DENG, HUI -HCHIBJ [mailto:hdeng@hitachi.cn]=20 Sent: Tuesday, October 12, 2004 8:45 AM To: Manning, Serge M [NTK]; Mip6@ietf.org Subject: RE: [Mip6] Consensus Call: Standardizing the auth protocol[I-D:draft-ietf-mip6-auth-protocol-00.txt] In the case of packet data internet service over cellular and Sprint specific service for mobile phones, do you really use Mobile IPv4 service? or just use basic simple IPv4 address to transmit data? -Hui -----Original Message----- From: Manning, Serge M [NTK] [mailto:Serge.M.Manning@mail.sprint.com]=20 Sent: 2004?10?12? 21:33 To: DENG, HUI -HCHIBJ; Mip6@ietf.org Subject: RE: [Mip6] Consensus Call: Standardizing the auth protocol[I-D:draft-ietf-mip6-auth-protocol-00.txt] We provide the basic packet data Internet service over cellular (similar to GPRS) as well as Sprint specific services to mobile handsets (similar to iMode types of service). --Serge -----Original Message----- From: DENG, HUI -HCHIBJ [mailto:hdeng@hitachi.cn]=20 Sent: Tuesday, October 12, 2004 8:09 AM To: Manning, Serge M [NTK]; Mip6@ietf.org Subject: RE: [Mip6] Consensus Call: Standardizing the auth protocol[I-D:draft-ietf-mip6-auth-protocol-00.txt] Hi, Manning, May I have one question? what kind of service and application does sprint provide based on authentication option in your deployed mobile ipv4 network? -Hui -----Original Message----- From: Manning, Serge M [NTK] [mailto:Serge.M.Manning@mail.sprint.com]=20 Sent: 2004?10?12? 3:50 To: Mip6@ietf.org Subject: RE: [Mip6] Consensus Call: Standardizing the auth protocol[I-D:draft-ietf-mip6-auth-protocol-00.txt] >-----Original Message----- >From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On >Subject: [Mip6] Consensus Call: Standardizing the auth protocol=20 >[I-D:draft-ietf-mip6-auth-protocol-00.txt] The question to the WG is: 1. Should we standardize the authentication protocol specified in I-D draft-ietf-mip6-auth-protocol-00.txt as an alternative (to the IPSec mechanism specified in RFC3775/6) means to securing the BUs and BAcks between the MN and HA. Note that this solution is an additional mechanism for doing registration with an HA and does not deprecate the currently specified solution.=20 Yes [X] No [ ] [Serge] I vote Yes. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Oct 12 19:59:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29409 for ; Tue, 12 Oct 2004 19:59:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHWj7-00073R-OU for mip6-web-archive@ietf.org; Tue, 12 Oct 2004 20:10:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHWWu-0007Hp-B2; Tue, 12 Oct 2004 19:58:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHWVw-0006jm-08 for mip6@megatron.ietf.org; Tue, 12 Oct 2004 19:57:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29281 for ; Tue, 12 Oct 2004 19:57:07 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHWgl-00070J-D5 for mip6@ietf.org; Tue, 12 Oct 2004 20:08:20 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i9CNTaK15945; Tue, 12 Oct 2004 16:29:36 -0700 X-mProtect: <200410122329> Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90) by darkstar.iprg.nokia.com smtpdbeQ1Vb; Tue, 12 Oct 2004 16:29:34 PDT Received: from iprg.nokia.com (localhost [127.0.0.1]) by rajeev.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id QAA34634; Tue, 12 Oct 2004 16:57:51 -0700 (PDT) Message-ID: <416C6F7E.81EE95C5@iprg.nokia.com> Date: Tue, 12 Oct 2004 16:57:51 -0700 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: Basavaraj.Patil@nokia.com Subject: Re: [Mip6] Consensus Call: Standardizing the auth protocol [I-D:draft-ietf-mip6-auth-protocol-00.txt] References: <697DAA22C5004B4596E033803A7CEF4403B1BF01@daebe007.americas.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rajeev@iprg.nokia.com List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit YES, mainly because a deployed base of authentication infrastructure exists, and potential for large-scale MIP6 deployment. -Rajeev Basavaraj.Patil@nokia.com wrote: > This is a consensus call to the WG on the issue of standardizing the > authentication-data-suboption mechanism for performing a binding between the > MN and HA. The issue has been discussed on the WG mailing list over > the last few weeks. The I-D > (draft-patil-mip6-whyauthdataoption-00.txt) has captured some of the > arguments, but there are several others that have been made on the > list as well. A summary of the discussion was sent out earlier and is > captured in : > http://www1.ietf.org/mail-archive/web/mip6/current/msg01690.html > > The proposal here (in brief) is to standardize a mechanism specified > in I-D draft-ietf-mip6-auth-protocol-00.txt for performing MIP6 > registration with a home agent. RFC3775 specifies the use of IPsec to > secure the binding update/ACK messages between the MN and HA. The > auth-protocol mechanism relies on the use of an > authentication-data-suboption and does not require the MN-HA to > establish an IPsec SA. > (For the discussion that has ensued so far, please refer to the MIP6 > ML archives) > > The question to the WG is: > > 1. Should we standardize the authentication protocol specified in I-D > draft-ietf-mip6-auth-protocol-00.txt as an alternative (to the > IPSec mechanism specified in RFC3775/6) means to securing the BUs > and BAcks between the MN and HA. Note that this solution is an > additional mechanism for doing registration with an HA and does not > deprecate the currently specified solution. > > Yes [ ] > No [ ] > > The consensus call will close on October 12th, 2004. > > -Chairs > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Oct 13 03:48:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28841 for ; Wed, 13 Oct 2004 03:48:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHe2i-0006ed-E6 for mip6-web-archive@ietf.org; Wed, 13 Oct 2004 03:59:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHdqN-00082H-85; Wed, 13 Oct 2004 03:46:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHdo6-0007O9-7t for mip6@megatron.ietf.org; Wed, 13 Oct 2004 03:44:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28528 for ; Wed, 13 Oct 2004 03:44:19 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHdyx-0006Zb-8w for mip6@ietf.org; Wed, 13 Oct 2004 03:55:35 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-1.cisco.com with ESMTP; 13 Oct 2004 00:52:37 -0700 X-BrightmailFiltered: true Received: from pyegani-w2k03.cisco.com (sjc-vpn5-993.cisco.com [10.21.91.225]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i9D7hSmR008579; Wed, 13 Oct 2004 00:43:29 -0700 (PDT) Message-Id: <4.3.2.7.2.20041013003523.0440ba98@franklin.cisco.com> X-Sender: pyegani@franklin.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 13 Oct 2004 00:43:28 -0700 To: mip6@ietf.org From: Parviz Yegani Subject: [Mip6] Consensus Call: Standardizing the auth Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: pyegani@cisco.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Hi, Sorry for replying a bit late... I vote YES. That is IETF should standardize the authentication protocol specified in I-D draft-ietf-mip6-auth-protocol-00.txt as an alternative means (to the IPSec mechanism specified in respective RFCs) to securing the BUs and BAs between the MN and the HA. Rgds, Parviz > -----Original Message----- > From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On > Behalf Of Basavaraj.Patil@nokia.com > Sent: Thursday, October 07, 2004 12:03 AM > To: mip6@ietf.org > Subject: [Mip6] Consensus Call: Standardizing the auth > protocol [I-D:draft-ietf-mip6-auth-protocol-00.txt] > > > > This is a consensus call to the WG on the issue of standardizing the > authentication-data-suboption mechanism for performing a > binding between the > MN and HA. The issue has been discussed on the WG mailing list over > the last few weeks. The I-D > (draft-patil-mip6-whyauthdataoption-00.txt) has captured some of the > arguments, but there are several others that have been made on the > list as well. A summary of the discussion was sent out earlier and is > captured in : > http://www1.ietf.org/mail-archive/web/mip6/current/msg01690.html > > The proposal here (in brief) is to standardize a mechanism specified > in I-D draft-ietf-mip6-auth-protocol-00.txt for performing MIP6 > registration with a home agent. RFC3775 specifies the use of IPsec to > secure the binding update/ACK messages between the MN and HA. The > auth-protocol mechanism relies on the use of an > authentication-data-suboption and does not require the MN-HA to > establish an IPsec SA. > (For the discussion that has ensued so far, please refer to the MIP6 > ML archives) > > The question to the WG is: > > 1. Should we standardize the authentication protocol specified in I-D > draft-ietf-mip6-auth-protocol-00.txt as an alternative (to the > IPSec mechanism specified in RFC3775/6) means to securing the BUs > and BAcks between the MN and HA. Note that this solution is an > additional mechanism for doing registration with an HA and does not > deprecate the currently specified solution. > > Yes [ ] > No [ ] > > > The consensus call will close on October 12th, 2004. > > -Chairs _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Oct 13 09:04:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24234 for ; Wed, 13 Oct 2004 09:04:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHiyv-0004cQ-AF for mip6-web-archive@ietf.org; Wed, 13 Oct 2004 09:15:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHigu-0007q7-Nb; Wed, 13 Oct 2004 08:57:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHifG-0007NI-6P for mip6@megatron.ietf.org; Wed, 13 Oct 2004 08:55:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23538 for ; Wed, 13 Oct 2004 08:55:29 -0400 (EDT) From: Basavaraj.Patil@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHiq6-0004SE-PH for mip6@ietf.org; Wed, 13 Oct 2004 09:06:48 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9DCtPC10745 for ; Wed, 13 Oct 2004 15:55:25 +0300 (EET DST) X-Scanned: Wed, 13 Oct 2004 15:55:05 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i9DCt5Rw009043 for ; Wed, 13 Oct 2004 15:55:05 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 007OmwFZ; Wed, 13 Oct 2004 15:55:03 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9DCt2S01172 for ; Wed, 13 Oct 2004 15:55:02 +0300 (EET DST) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 13 Oct 2004 07:54:51 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Oct 2004 07:54:50 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF4403B1BF55@daebe007.americas.nokia.com> Thread-Topic: draft-patel-mipv6-auth-protocol-01.txt Thread-Index: AcSw9znQVOJEvTJ/Qeez6zBu6KDbtwALJA/Q X-Priority: 1 Priority: Urgent Importance: high To: X-OriginalArrivalTime: 13 Oct 2004 12:54:51.0085 (UTC) FILETIME=[D3EF17D0:01C4B123] X-Spam-Score: 1.6 (+) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: quoted-printable Subject: [Mip6] FW: draft-patel-mipv6-auth-protocol-01.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 1.6 (+) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: mailman-bounces@lists.ietf.org > [mailto:mailman-bounces@lists.ietf.org]On Behalf Of ext Parviz Yegani > To: mip6-owner@ietf.org > Cc: pyegani@cisco.com > Subject: draft-patel-mipv6-auth-protocol-01.txt > Importance: High >=20 >=20 > Hi Raj, Gopal, >=20 > As I understand the above subject draft is under discussion=20 > in IETF, MIPv6=20 > WG. I'd like to > let you know that Cisco will support this draft to be published as a=20 > standard track RFC. Please > note that this document is in the IETF dependency list and marked as=20 > "critically important" for > 3GPP2 and TIA towards publication of their next release of cdma2000=20 > wireless IP standards > X.S0011-D and TIA-835-D, respectively. >=20 > Please forward this email to the MIPv6 WG mailing list as appropriate. >=20 > Parviz Yegani > Chair, TIA TR-45.6 Subcommittee >=20 >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Oct 13 11:33:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08562 for ; Wed, 13 Oct 2004 11:33:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHlIu-0007Xp-IY for mip6-web-archive@ietf.org; Wed, 13 Oct 2004 11:44:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHl5S-0004Cz-7A; Wed, 13 Oct 2004 11:30:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHkxP-0002Nr-7f for mip6@megatron.ietf.org; Wed, 13 Oct 2004 11:22:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07804 for ; Wed, 13 Oct 2004 11:22:27 -0400 (EDT) Received: from dns1.tilab.com ([163.162.42.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHl8M-0007KM-Sm for mip6@ietf.org; Wed, 13 Oct 2004 11:33:48 -0400 Received: from iowa2k01a.cselt.it ([163.162.242.201]) by dns1.cselt.it (PMDF V6.0-025 #38895) with ESMTP id <0I5J0057B3XDHX@dns1.cselt.it> for mip6@ietf.org; Wed, 13 Oct 2004 17:20:01 +0200 (MEST) Received: from EXC01B.cselt.it ([163.162.4.199]) by iowa2k01a.cselt.it with Microsoft SMTPSVC(6.0.3790.0); Wed, 13 Oct 2004 17:23:46 +0200 Date: Wed, 13 Oct 2004 17:21:52 +0200 From: Giaretta Gerardo To: mip6@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: New version of "MIPv6 Authorization and Configuration based on EAP" Thread-Index: AcSxOF36eKEJHrqvQNmVfSNzyN9jrQ== Content-class: urn:content-classes:message X-OriginalArrivalTime: 13 Oct 2004 15:23:46.0296 (UTC) FILETIME=[A1BC1780:01C4B138] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Cc: Julien Bournelle , Demaria Elena , Maryline MAKNAVICIUS-LAURENT , Guardini Ivano Subject: [Mip6] New version of "MIPv6 Authorization and Configuration based on EAP" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable Hi all, A new version of draft-giaretta-mip6-authorization-eap is available at the following location:=20 http://www.ietf.org/internet-drafts/draft-giaretta-mip6-authorization-ea p-02.txt The draft defines a method for bootstrapping Mobile IPv6 relying on a AAA infrastructure and EAP. Main changes from the last version are: - both Pre-Shared Key and certificates can be used as peer authentication methods in IKE Phase 1; - the Pre-Shared Key can be either generated by the AAA server of the MSP or derived from the EAP key hierarchy (as described in draft-giaretta-mip6-amsk-00); - the message format has been re-designed in such a way to be easily adapted to any EAP method supporting the exchange of arbitrary parameters. The draft provides the specific message formats for PEAPv2, EAP-FAST, EAP-SIM, EAP-AKA, EAP-IKEv2 and EAP-TTLS. Comments are appreciated. Regards, --Gerardo Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to=20 MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Oct 13 11:38:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09023 for ; Wed, 13 Oct 2004 11:38:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHlOA-0007dw-6s for mip6-web-archive@ietf.org; Wed, 13 Oct 2004 11:50:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHlAL-0005PL-4X; Wed, 13 Oct 2004 11:35:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHl67-0004Q7-TO for mip6@megatron.ietf.org; Wed, 13 Oct 2004 11:31:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08382 for ; Wed, 13 Oct 2004 11:31:27 -0400 (EDT) Received: from dns1.tilab.com ([163.162.42.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHlH6-0007Uz-9k for mip6@ietf.org; Wed, 13 Oct 2004 11:42:48 -0400 Received: from iowa2k01a.cselt.it ([163.162.242.201]) by dns1.cselt.it (PMDF V6.0-025 #38895) with ESMTP id <0I5J0054F4CEXT@dns1.cselt.it> for mip6@ietf.org; Wed, 13 Oct 2004 17:29:02 +0200 (MEST) Received: from EXC01B.cselt.it ([163.162.4.199]) by iowa2k01a.cselt.it with Microsoft SMTPSVC(6.0.3790.0); Wed, 13 Oct 2004 17:32:47 +0200 Date: Wed, 13 Oct 2004 17:30:54 +0200 From: Giaretta Gerardo To: mip6@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: New I-D: Application Master Session Key (AMSK) for Mobile IPv6 Thread-Index: AcSxOaExx1J9G4/qTMyIE9emxRG6Jw== Content-class: urn:content-classes:message X-OriginalArrivalTime: 13 Oct 2004 15:32:47.0812 (UTC) FILETIME=[E480E040:01C4B139] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable Cc: Julien Bournelle , Demaria Elena , Maryline MAKNAVICIUS-LAURENT , Guardini Ivano Subject: [Mip6] New I-D: Application Master Session Key (AMSK) for Mobile IPv6 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable Hi all, we have submitted a new I-D about the generation of an Application Master Session Key (AMSK) specific to Mobile IPv6. This AMSK can be used by Mobile Node and Home Agent as the shared secret needed to bootstrap Mobile IPv6 protocol operation.=20 The I-D can be found at: http://www.ietf.org/internet-drafts/draft-giaretta-mip6-amsk-00.txt.=20 Comments are welcome. --Gerardo Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to=20 MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Oct 13 11:49:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09441 for ; Wed, 13 Oct 2004 11:49:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHlYP-0007lj-JP for mip6-web-archive@ietf.org; Wed, 13 Oct 2004 12:00:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHlHj-00078U-Pc; Wed, 13 Oct 2004 11:43:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHlBu-0005qr-S8 for mip6@megatron.ietf.org; Wed, 13 Oct 2004 11:37:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08939 for ; Wed, 13 Oct 2004 11:37:26 -0400 (EDT) From: Basavaraj.Patil@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHlMs-0007cB-K2 for mip6@ietf.org; Wed, 13 Oct 2004 11:48:48 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9DFbNC29089 for ; Wed, 13 Oct 2004 18:37:23 +0300 (EET DST) X-Scanned: Wed, 13 Oct 2004 18:36:55 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i9DFatvr017393 for ; Wed, 13 Oct 2004 18:36:55 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00auuFua; Wed, 13 Oct 2004 18:35:51 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9DFZoa26674 for ; Wed, 13 Oct 2004 18:35:50 +0300 (EET DST) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 13 Oct 2004 10:35:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Oct 2004 10:35:46 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF4403B1BF5C@daebe007.americas.nokia.com> Thread-Topic: Consensus Call Conclusion Thread-Index: AcSxOk9OuuIYoreTThyhTtaBKVxiBg== To: X-OriginalArrivalTime: 13 Oct 2004 15:35:48.0150 (UTC) FILETIME=[4FFE4560:01C4B13A] X-Spam-Score: 0.3 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable Subject: [Mip6] Consensus Call Conclusion X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable The outcome of the consensus call on the question, " 1. Should we standardize the authentication protocol specified in I-D draft-ietf-mip6-auth-protocol-00.txt as an alternative (to the IPSec mechanism specified in RFC3775/6) means to securing the BUs and BAcks between the MN and HA. Note that this solution is an additional mechanism for doing registration with an HA and does not deprecate the currently specified solution.=20 " (http://www1.ietf.org/mail-archive/web/mip6/current/msg01722.html) is as follows: We have rough consensus to standardize the authentication protocol specified in the above mentioned I-D.=20 Several people have expressed that they would like to see some changes w.r.t the details. These will be discussed on the MIP6 ML and changes made based on consensus. Alpesh Patel who is currently an author of this I-D will be the document editor. Comments/feedback from the security directorate is also expected. We will post it to the list as soon as we get this input. Some details of the consensus call: [Yes] - 25 [No ] - 13 Of the 13 people who said No, 4 of them are agreeable to publishing the I-D as an Informational RFC.=20 -Chairs _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Oct 13 11:55:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09962 for ; Wed, 13 Oct 2004 11:55:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHlef-0007sO-8V for mip6-web-archive@ietf.org; Wed, 13 Oct 2004 12:07:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHlOp-0000Tq-7S; Wed, 13 Oct 2004 11:50:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHlLY-0007wu-Ic for mip6@megatron.ietf.org; Wed, 13 Oct 2004 11:47:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09400 for ; Wed, 13 Oct 2004 11:47:24 -0400 (EDT) From: Basavaraj.Patil@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHlWW-0007kW-A5 for mip6@ietf.org; Wed, 13 Oct 2004 11:58:45 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9DFlLW19793 for ; Wed, 13 Oct 2004 18:47:21 +0300 (EET DST) X-Scanned: Wed, 13 Oct 2004 18:47:11 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i9DFlBTW019964 for ; Wed, 13 Oct 2004 18:47:11 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 009fm3vy; Wed, 13 Oct 2004 18:47:11 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9DFl9a06207 for ; Wed, 13 Oct 2004 18:47:09 +0300 (EET DST) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 13 Oct 2004 10:47:01 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Oct 2004 10:47:00 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF4403B1BF5D@daebe007.americas.nokia.com> Thread-Topic: MIP6 WG meeting at IETF61 Thread-Index: AcSxO+Ekm7LRK0HFQSaKcBDEvQ4XtA== To: X-OriginalArrivalTime: 13 Oct 2004 15:47:01.0636 (UTC) FILETIME=[E16C1440:01C4B13B] X-Spam-Score: 0.3 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable Subject: [Mip6] MIP6 WG meeting at IETF61 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable The MIP6 working group will meet at IETF61. We have requested a 2.5 hour slot for the WG meeting in Washington D.C.=20 If you would like a timeslot on the MIP6 WG agenda, please send a request to the chairs. Include in the request: 1. Discussion Topic 2. Draft Name 3. Slot Duration 4. Is this in the scope of the Charter? (if not explain the relation) 5. What do you want to accomplish by this presentation (e.g resolve the = following issues) 6. Was this draft discussed in the mailing list 7. Are there any open issues? -Chairs _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Oct 13 13:23:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17317 for ; Wed, 13 Oct 2004 13:23:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHn1F-000169-Qm for mip6-web-archive@ietf.org; Wed, 13 Oct 2004 13:34:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHmmW-0005by-Dh; Wed, 13 Oct 2004 13:19:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHmb7-0002mm-9J for mip6@megatron.ietf.org; Wed, 13 Oct 2004 13:07:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16242 for ; Wed, 13 Oct 2004 13:07:32 -0400 (EDT) From: Basavaraj.Patil@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHmm6-0000n1-Cd for mip6@ietf.org; Wed, 13 Oct 2004 13:18:55 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9DH7Uh02665 for ; Wed, 13 Oct 2004 20:07:30 +0300 (EET DST) X-Scanned: Wed, 13 Oct 2004 20:07:16 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i9DH7Gh4023063 for ; Wed, 13 Oct 2004 20:07:16 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00RTvOFC; Wed, 13 Oct 2004 20:07:06 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9DH73a18021 for ; Wed, 13 Oct 2004 20:07:04 +0300 (EET DST) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 13 Oct 2004 12:05:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Oct 2004 12:05:40 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF4403B1BF67@daebe007.americas.nokia.com> Thread-Topic: WGLC: draft-ietf-mip6-firewalls-00.txt Thread-Index: AcSxRt2gwGUByFcDTJ2504VIKeSiDA== To: X-OriginalArrivalTime: 13 Oct 2004 17:05:43.0878 (UTC) FILETIME=[E0190660:01C4B146] X-Spam-Score: 0.3 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: quoted-printable Subject: [Mip6] WGLC: draft-ietf-mip6-firewalls-00.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable Hello, This is a Working Group last call for the following I-D: I-D :draft-ietf-mip6-firewalls-00.txt Title: Mobile IPv6 and Firewalls Problem Statement =20 The status associated with this I-D is : Informational and will be progressed as such. Please review and post your comments by October 27th, 2004. -Chairs URL to I-D: http://ietf.org/internet-drafts/draft-ietf-mip6-firewalls-00.txt _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Oct 14 05:48:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24092 for ; Thu, 14 Oct 2004 05:48:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CI2Os-0005pe-6T for mip6-web-archive@ietf.org; Thu, 14 Oct 2004 05:59:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI27y-0005Zz-LQ; Thu, 14 Oct 2004 05:42:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI25Y-00052e-GV for mip6@megatron.ietf.org; Thu, 14 Oct 2004 05:40:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22706 for ; Thu, 14 Oct 2004 05:39:57 -0400 (EDT) Received: from mail32.messagelabs.com ([62.173.108.211]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CI2GT-0005WU-7r for mip6@ietf.org; Thu, 14 Oct 2004 05:51:30 -0400 X-VirusChecked: Checked X-Env-Sender: xiaobao.chen@orange.co.uk X-Msg-Ref: server-15.tower-32.messagelabs.com!1097746741!22701207 X-StarScan-Version: 5.2.10; banners=orange.co.uk,-,- X-Originating-IP: [193.35.135.133] Received: (qmail 6217 invoked from network); 14 Oct 2004 09:39:02 -0000 Received: from smtpout10.orange.co.uk (HELO hagrid.orange.co.uk) (193.35.135.133) by server-15.tower-32.messagelabs.com with SMTP; 14 Oct 2004 09:39:02 -0000 Received: from bot.orange.co.uk (bot.orange.co.uk) by hagrid.orange.co.uk (Content Technologies SMTPRS 4.3.10) with ESMTP id for ; Thu, 14 Oct 2004 10:37:59 +0100 Received: from ukexbrismtp02.uk.orangegad.com (ukexbrismtp02.orange.co.uk [172.16.131.106]) by bot.orange.co.uk with SMTP id i9E9bwl12419 for ; Thu, 14 Oct 2004 10:37:58 +0100 (BST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 14 Oct 2004 10:37:57 +0100 Message-ID: <8C8F0E870815804FAC506E74B8A6F7B401A0F00A@UKEXBRIMBX001.uk.orangegad.com> Thread-Topic: The revised I-D: draft-chen-mip6-gprs-02.txt Thread-Index: AcSx0XyorLJx0GLyTO6FF05wWDk+rw== From: "CHEN, Xiaobao" To: X-OriginalArrivalTime: 14 Oct 2004 09:37:57.0865 (UTC) FILETIME=[7D1E8590:01C4B1D1] X-Spam-Score: 0.1 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e Subject: [Mip6] The revised I-D: draft-chen-mip6-gprs-02.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1658592197==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b This is a multi-part message in MIME format. --===============1658592197== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4B1D1.7CCABD00" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4B1D1.7CCABD00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI.=20Comments=20are=20welcome. http://www.ietf.org/internet-drafts/draft-chen-mip6-gprs-02.txt Problem=20Statement=20for=20MIPv6=20Interactions=20with=20GPRS/UMTS=20Pack= et=20Filtering=20 =09=09draft-chen-mip6-gprs-02.txt=20 Abstract=20 This=20document=20provides=20an=20analysis=20of=20certain=20inter-working=20= problems=20between IPv6=20nodes=20running=20Mobile=20IPv=20at=20least=20one=20of=20which=20is= =20connected=20to=20a=20Third Generation=20Partnership=20Project=20(3GPP)=20specified=20General=20Packet= =20Radio Service/Universal=20Mobile=20Tele-=20communications=20System=20(GPRS/UMTS)= =20network.=20The inter-working=20problems=20are=20caused=20by=20some=20specific=20packet=20= filtering operations=20at=20the=20edge=20of=20the=20GPRS/UMTS=20network=20which=20ar= e=20applied=20to=20control access=20to=20the=20GPRS/UMTS=20services=20and=20network=20resources.=20Ho= wever,=20we=20believe that=20other=20scenarios=20may=20exist=20in=20which=20similar=20packet=20f= iltering=20operations may=20be=20applied=20and=20that=20similar=20problems=20would=20arise=20in=20= these=20more=20general scenarios.=20The=20GPRS=20Gateway=20Support=20Node=20(GGSN)=20checks=20the= =20source=20address=20or the=20destination=20address=20in=20the=20basic=20IPv6=20header=20of=20inco= ming=20or=20outgoing=20IP datagrams=20against=20a=20set=20of=20packet=20filtering=20information=20es= tablished=20during the=20GPRS/UMTS=20session=20set-up.=20The=20packet=20filtering=20informati= on=20remains=20stable during=20the=20sessions=20and=20independent=20of=20Mobile=20IP.=20When=20M= IPv6=20is=20activated=20by either=20end=20of=20the=20IPv6=20mobile=20nodes,=20the=20packet=20filterin= g=20will=20fail=20to perform=20properly=20and=20subsequently=20block=20the=20traffic=20due=20to= =20the=20mismatch between=20the=20packet=20filters=20and=20the=20current=20source=20address=20= or=20destination address=20in=20the=20basic=20IPv6=20header=20of=20the=20IP=20datagrams=20t= o=20and=20from=20the=20IPv6 mobile=20nodes.=20 Xiaobao=20Chen Orange=20PCS=20Ltd. ******************************************************************** Important. Confidentiality:=20This=20communication=20is=20intended=20for=20the=20abov= e-named person=20and=20may=20be=20confidential=20and/or=20legally=20privileged. Any=20opinions=20expressed=20in=20this=20communication=20are=20not=20neces= sarily=20 those=20of=20the=20company.=20If=20it=20has=20come=20to=20you=20in=20error= =20you=20must=20 take=20no=20action=20based=20on=20it,=20nor=20must=20you=20copy=20or=20sho= w=20it=20to=20anyone;=20 please=20delete/destroy=20and=20inform=20the=20sender=20immediately. Monitoring/Viruses. Orange=20may=20monitor=20all=20incoming=20and=20outgoing=20emails=20in=20l= ine=20with=20 current=20legislation.=20=20Although=20we=20have=20taken=20steps=20to=20en= sure=20that=20 this=20email=20and=20attachments=20are=20free=20from=20any=20virus,=20we=20= advise=20that=20 in=20keeping=20with=20good=20computing=20practice=20the=20recipient=20shou= ld=20ensure=20 they=20are=20actually=20virus=20free. Orange=20PCS=20Limited=20is=20a=20subsidiary=20of=20Orange=20SA=20and=20is= =20registered=20 in=20England=20No=202178917,=20with=20its=20address=20at=20St=20James=20Co= urt,=20 Great=20Park=20Road,=20Almondsbury=20Park,=20Bradley=20Stoke,=20Bristol=20= BS32=204QJ. ******************************************************************** ------_=_NextPart_001_01C4B1D1.7CCABD00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The=20revised=20I-D:=20draft-chen-mip6-gprs-02.txt

FYI.=20Comments=20are=20welcome.
http://ww= w.ietf.org/internet-drafts/draft-chen-mip6-gprs-02.txt

Problem=20Statement=20for=20MIPv6=20= Interactions=20with=20GPRS/UMTS=20Packet=20Filtering=20
       =20    &= nbsp;  =20draft-chen-mip6-g= prs-02.txt=20

Abstract=20
This=20document=20provides=20an=20= analysis=20of=20certain=20inter-working=20problems=20between=20IPv6=20node= s=20running=20Mobile=20IPv=20at=20least=20one=20of=20which=20is=20connecte= d=20to=20a=20Third=20Generation=20Partnership=20Project=20(3GPP)=20specifi= ed=20General=20Packet=20Radio=20Service/Universal=20Mobile=20Tele-=20commu= nications=20System=20(GPRS/UMTS)=20network.=20The=20inter-working=20proble= ms=20are=20caused=20by=20some=20specific=20packet=20filtering=20operations= =20at=20the=20edge=20of=20the=20GPRS/UMTS=20network=20which=20are=20applie= d=20to=20control=20access=20to=20the=20GPRS/UMTS=20services=20and=20networ= k=20resources.=20However,=20we=20believe=20that=20other=20scenarios=20may=20= exist=20in=20which=20similar=20packet=20filtering=20operations=20may=20be=20= applied=20and=20that=20similar=20problems=20would=20arise=20in=20these=20m= ore=20general=20scenarios.=20The=20GPRS=20Gateway=20Support=20Node=20(GGSN= )=20checks=20the=20source=20address=20or=20the=20destination=20address=20i= n=20the=20basic=20IPv6=20header=20of=20incoming=20or=20outgoing=20IP=20dat= agrams=20against=20a=20set=20of=20packet=20filtering=20information=20estab= lished=20during=20the=20GPRS/UMTS=20session=20set-up.=20The=20packet=20fil= tering=20information=20remains=20stable=20during=20the=20sessions=20and=20= independent=20of=20Mobile=20IP.=20When=20MIPv6=20is=20activated=20by=20eit= her=20end=20of=20the=20IPv6=20mobile=20nodes,=20the=20packet=20filtering=20= will=20fail=20to=20perform=20properly=20and=20subsequently=20block=20the=20= traffic=20due=20to=20the=20mismatch=20between=20the=20packet=20filters=20a= nd=20the=20current=20source=20address=20or=20destination=20address=20in=20= the=20basic=20IPv6=20header=20of=20the=20IP=20datagrams=20to=20and=20from=20= the=20IPv6=20mobile=20nodes.=20



Xiaobao=20Chen

Orange=20PCS=20Ltd.


********************************************************************
Important.
Confidentiality:=20This=20communication=20is=20intended=20for=20the=20abov= e-named
person=20and=20may=20be=20confidential=20and/or=20legally=20privileged. Any=20opinions=20expressed=20in=20this=20communication=20are=20not=20neces= sarily=20
those=20of=20the=20company.=20If=20it=20has=20come=20to=20you=20in=20error= =20you=20must=20
take=20no=20action=20based=20on=20it,=20nor=20must=20you=20copy=20or=20sho= w=20it=20to=20anyone;=20
please=20delete/destroy=20and=20inform=20the=20sender=20immediately.

Monitoring/Viruses.
Orange=20may=20monitor=20all=20incoming=20and=20outgoing=20emails=20in=20l= ine=20with=20
current=20legislation.=20=20Although=20we=20have=20taken=20steps=20to=20en= sure=20that=20
this=20email=20and=20attachments=20are=20free=20from=20any=20virus,=20we=20= advise=20that=20
in=20keeping=20with=20good=20computing=20practice=20the=20recipient=20shou= ld=20ensure=20
they=20are=20actually=20virus=20free.

Orange=20PCS=20Limited=20is=20a=20subsidiary=20of=20Orange=20SA=20and=20is= =20registered=20
in=20England=20No=202178917,=20with=20its=20address=20at=20St=20James=20Co= urt,=20
Great=20Park=20Road,=20Almondsbury=20Park,=20Bradley=20Stoke,=20Bristol=20= BS32=204QJ.
********************************************************************
------_=_NextPart_001_01C4B1D1.7CCABD00-- --===============1658592197== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1658592197==-- From mip6-bounces@ietf.org Thu Oct 14 06:56:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29903 for ; Thu, 14 Oct 2004 06:56:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CI3Sp-00076O-GF for mip6-web-archive@ietf.org; Thu, 14 Oct 2004 07:08:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI3Ei-0004Rt-GK; Thu, 14 Oct 2004 06:53:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI3A0-0003ak-2T for mip6@megatron.ietf.org; Thu, 14 Oct 2004 06:48:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29035 for ; Thu, 14 Oct 2004 06:48:37 -0400 (EDT) Received: from mn-2.atm.tut.fi ([130.230.52.147] helo=mn-2) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CI3L9-0006tU-56 for mip6@ietf.org; Thu, 14 Oct 2004 07:00:11 -0400 Received: from mark by mn-2 with local (Exim 3.36 #1 (Debian)) id 1CI3Ed-0000TN-00; Thu, 14 Oct 2004 13:53:27 +0300 From: Mark Borst To: mip6@ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 14 Oct 2004 13:53:26 +0300 Message-Id: <1097751206.1501.6.camel@mn-2> Mime-Version: 1.0 X-Mailer: Evolution 1.5.94.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Subject: [Mip6] New I-D: Mobile IPv6 Application API draft-borst-mip6api-00.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Hello all We have submitted a new Internet-Draft specifying a Mobile IPv6 Application API. Abstract: By design, Mobile IPv6 does not provide movement information to higher layers or applications. However, new breeds of location-sensitive applications and technologies would benefit from having access to such information. This document outlines how the knowledge of mobility can be usefully harnessed by applications which reside in a mobile node as well as a correspondent node. It then defines an application-level API to fulfill those needs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-borst-mip6api-00.txt Please let us know if you have any comments. -- Mark Borst Researcher Network and Protocols Group Tampere University of Technology, Finland _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Oct 14 17:03:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03099 for ; Thu, 14 Oct 2004 17:03:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CICwc-0004sM-N7 for mip6-web-archive@ietf.org; Thu, 14 Oct 2004 17:15:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CICNs-0006pU-WE; Thu, 14 Oct 2004 16:39:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIC4v-0000DI-Vs; Thu, 14 Oct 2004 16:20:02 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25548; Thu, 14 Oct 2004 16:19:59 -0400 (EDT) Message-Id: <200410142019.QAA25548@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 14 Oct 2004 16:19:59 -0400 Cc: mip6@ietf.org Subject: [Mip6] I-D ACTION:draft-ietf-mip6-bootstrap-ps-01.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv6 Working Group of the IETF. Title : Problem Statement for bootstrapping Mobile IPv6 Author(s) : A. Patel Filename : draft-ietf-mip6-bootstrap-ps-01.txt Pages : 26 Date : 2004-10-14 A mobile node needs home address, home agent address and security association with home agent to register with the home agent. The process of obtaining this information is called bootstrapping. This document This document defines the problem for how the mobile can be bootstrapped in various deployment scenarios. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrap-ps-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mip6-bootstrap-ps-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip6-bootstrap-ps-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-14164545.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-bootstrap-ps-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-bootstrap-ps-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-14164545.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --NextPart-- From mip6-bounces@ietf.org Fri Oct 15 03:58:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03128 for ; Fri, 15 Oct 2004 03:58:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CINAM-0000Jo-90 for mip6-web-archive@ietf.org; Fri, 15 Oct 2004 04:10:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIMwd-00028N-Im; Fri, 15 Oct 2004 03:56:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIMvy-00020G-M9 for mip6@megatron.ietf.org; Fri, 15 Oct 2004 03:55:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03024 for ; Fri, 15 Oct 2004 03:55:28 -0400 (EDT) Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIN7F-0000H3-3A for mip6@ietf.org; Fri, 15 Oct 2004 04:07:12 -0400 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id i9F7tIY9019310; Fri, 15 Oct 2004 00:55:18 -0700 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id i9F7tHie019296; Fri, 15 Oct 2004 00:55:17 -0700 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Fri, 15 Oct 2004 00:55:17 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: MIP6 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 054490fec19f6a94c68e63428d06db69 Cc: "Wijnen, Bert \(Bert\)" Subject: [Mip6] MIB Doctor review for: draft-ietf-mip6-mipv6-mib-04.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3643ee1fccf5d6cf2af25f27d28abb29 Greetings, This MIB Doctor review of the MOBILEIPV6-MIB document looks at draft-ietf-mip6-mipv6-mib-04.txt. It is a follow-up to a previous review posted to the MIP6 mailing list on 10 August 2004 that dealt with draft-ietf-mip6-mipv6-mib-03.txt. As before, those who wish to respond to these comments should do so on the MIP6 mailing list, with copies to Bert Wijnen and myself. The format is patterned after the checklist in Appendix A of . 0.) Title -- I would recommend "A Management Information Base Module for Mobile IPv6" or perhaps even "Managed Objects for Mobile IPv6". (Strictly speaking, there is only one MIB, and the components are MIB modules, which contain managed objects.) [Also suggested in the previous review.] 1.) I-D Boilerplate -- OK. 2.) Abstract -- OK. 3.) MIB Boilerplate -- OK. 4.) IPR Notice -- OK. 5.) References -- as requested in the previous review, the obsolete documents that were present in the -03 draft have been removed from the reference list and the document containing the IPv6-capable update of the IP-MIB has been added. Unfortunately, the reference list now lacks citation tags and does not have sub-headings to clearly indicate which references are normative and which are informative. In addition, RFC 2119 is cited in the text but is not listed; since the imperative keywords are used, that document is required to be listed as a normative reference. Similarly, items from the INET-ADDRESS-MIB are imported, but it is neither listed in the references nor cited in the text (this point was missed in the review of the -03 draft). Finally, although the IPv6-capable update of the IP-MIB document is present in the reference list, it is not cited in the text as required by RFC Editor policy. Here are the recommended fixes. First, change the second paragraph of Section 4 as follows: OLD: It is assumed that the Mobile IPv6 Management Information Base (MOBILEIPV6-MIB) will always be implemented in conjunction with the (to-be-published) IP-MIB. NEW: It is assumed that the Mobile IPv6 Management Information Base (MOBILEIPV6-MIB) will always be implemented in conjunction with the IPv6-capable version of the IP-MIB [RFC2011bis]. It uses the textual conventions defined in the INET-ADDRESS-MIB [RFC3291bis]. Second, change the body of Section 8 as follows: OLD: McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, Structure of Management Information Version 2 (SMIv2), STD 58, RFC 2578, April 1999. McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, Textual Conventions for SMIv2, STD 58, RFC 2579, April 1999. McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, Conformance Statements for SMIv2, STD 58, RFC 2580, April 1999. Johnson, D., Perkins, C. and Arkko J., Mobility Support in IPv6q RFC 3775, June 2004. Routhier, S., Management Information Base for the Internet Protocol (IP), work in progress (currently ). Case, J., Mundy, R., Partain, D. and B. Stewart, Introduction and Applicability Statements for Internet-Standard Management Framework, RFC 3410, December 2002. NEW: 8.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirements Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [MIPv6] Johnson, D., Perkins, C. and Arkko J., "Mobility Support in IPv6", RFC 3775, June 2004. [RFC2011bis] Routhier, S., "Management Information Base for the Internet Protocol (IP)", work in progress (currently ). [RFC3291bis] Daniele, M., Haberman, B., Routhier, S. and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", work in progress (currently draft-ietf-ops-rfc3291bis-06.txt). 8.2 Informative References [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. As a matter of stylistic consistency, it might be desirable also to change all occurrences of the citation tag [MIPv6] to [RFC3775] (there are two in the text), but that is not required. 6.) Security Considerations Section -- appears to be complete and well thought out. 7.) IANA Considerations Section -- there is a typo in Section 7: s/'mipv6MIB'/'mip6MIB'/ Apart from that it looks just fine. 8.) Copyright Notices -- OK. 9.) Other issues from http://www.ietf.org/ID-Checklist.html not covered elsewhere -- none found. Thanks for cleaning up the stuff found in the -03 draft. 10.) Technical content -- review of actual technical content for compliance with : (a) verify that the the DESCRIPTION clauses of the MOBILEIPV6-MIB rows that use ipv6InterfaceIfIndex as an index explicitly state for which ipv6InterfaceIfIndex values the row is instantiated, as requested in the review of the -03 draft (this requirement comes from the last paragraph of RFC 2578 Section 7.8) -- OK. (b) verify that the IP-MIB is mentioned in the narrative part of the document, as requested in the review of the -03 draft -- OK, subject to implementation of the fixes requested under (5) above. (c) MIB compilation using smilint -- MOBILEIPV6-MIB:191: [5] {index-exceeds-too-large} warning: index of row `mip6BindingCacheEntry' can exceed OID size limit by 142 subidentifier(s) MOBILEIPV6-MIB:407: [5] {index-exceeds-too-large} warning: index of row `mip6BindingHistoryEntry' can exceed OID size limit by 143 subidentifier(s) MOBILEIPV6-MIB:771: [5] {index-exceeds-too-large} warning: index of row `mip6NodeTrafficEntry' can exceed OID size limit by 142 subidentifier(s) MOBILEIPV6-MIB:991: [5] {index-exceeds-too-large} warning: index of row `mip6MnHomeAddressEntry' can exceed OID size limit by 142 subidentifier(s) MOBILEIPV6-MIB:1230: [5] {index-exceeds-too-large} warning: index of row `mip6MnBLEntry' can exceed OID size limit by 399 subidentifier(s) MOBILEIPV6-MIB:1902: [5] {index-exceeds-too-large} warning: index of row `mip6CnCounterEntry' can exceed OID size limit by 142 subidentifier(s) MOBILEIPV6-MIB:2504: [5] {index-exceeds-too-large} warning: index of row `mip6HaCounterEntry' can exceed OID size limit by 142 subidentifier(s) MOBILEIPV6-MIB:2635: [5] {index-exceeds-too-large} warning: index of row `mip6HaListEntry' can exceed OID size limit by 143 subidentifier(s) MOBILEIPV6-MIB:2747: [5] {index-exceeds-too-large} warning: index of row `mip6HaGlAddrEntry' can exceed OID size limit by 144 subidentifier(s) Such warnings are expected when a conceptual row has unconstrained InetAddress objects in the INDEX clause. They are acceptable provided that the actual size constraints which must be observed are documented in the conceptual row DESCRIPTION clauses (or in the narrative part of the MIB document). However, the definitions flagged above do not do that; instead, there is language in the DESCRIPTION clauses of the the InetAddressType/InetAddress objects that restricts their values to ipv6(2) or ipv6z(4) address types. This is equivalent to subtyping, and so contravenes the intent of draft-ietf-ops-rfc3291bis-06.txt. If it is desired to leave open the possibility of using these tables for other IP versions then it would be better to remove the restrictive language from the InetAddressType/InetAddress pair DESCRIPTION clauses and instead document the constraints in the DESCRIPTION clauses of the corresponding conceptual rows, as was done, e.g., for inetCidrRouteEntry in the IP-FORWARD-MIB (see draft-ietf-ipv6-rfc2096-update-07.txt). Let us examine the mip6MnBLEntry for a specific example for how this can be done for the conceptual rows in the MOBILEIPV6-MIB. There are two InetAddress objects mentioned in the INDEX clause. Their underlying type is OCTET STRING (SIZE(0..255)), so the sum of their sizes can go up to 510 octets. According to the smilint report this would cause the column instance OIDs to exceed the limit by 399 sub-IDs. So to avoid OID overflow the sum of the sizes should not exceed 510 - 399 = 111 octets. This can be documented by adding the the following language to the the mip6MnBLEntry DESCRIPTION clause: Implementers need to be aware that if the total number of octets in mip6MnHomeAddress and mip6MnBLNodeAddress exceeds 111 then OIDs of column instances in this row will have more than 128 sub-identifiers and cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3. The pattern of modifications needed for the other row object DESCRIPTION clauses should be clear. (d) Corrections for some typos in some of the InetAddressType objects: OLD: mip6BindingHstHomeAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION ! "The InetAddressType of the mip6BindingHomeAddress ! ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ that follows. - The only allowed type for this object is ipv6(2). " ::= { mip6BindingHistoryEntry 1 } NEW: mip6BindingHstHomeAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The InetAddressType of the mip6BindingHstHomeAddress that follows. " ::= { mip6BindingHistoryEntry 1 } OLD: mip6BindingHstCOAType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION ! "The InetAddressType of the mip6BindingCOA that ! ^^^^^^^^^^^^^^^^^^^ follows. - The only allowed type for this object is ipv6(2). " ::= { mip6BindingHistoryEntry 4 } NEW: mip6BindingHstCOAType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The InetAddressType of the mip6BindingHstCOA that follows. " ::= { mip6BindingHistoryEntry 4 } Note: I assume here that the type constraints will be removed from _all_ InetAddressType/InetAddress object DESCRIPTION clauses, as recommended in (c) above. (e) Corrections for some typos in the mip6CoreCompliance compliance statement: OLD: -- OBJECT mip6BindingHomeAddressType -- SYNTAX InetAddressType (ipv6(2)) -- DESCRIPTION -- This MIB module requires support for global -- ipv6 addresses for the mip6BindingHomeAddress -- object. -- -- OBJECT mip6BindingHomeAddress -- SYNTAX InetAddress (SIZE 16) -- DESCRIPTION -- This MIB module requires support for global -- ipv6 addresses for the mip6BindingHomeAddress -- object. -- -- OBJECT mip6BindingHstHomeAddressType -- SYNTAX InetAddressType (ipv6(2)) -- DESCRIPTION -- This MIB module requires support for global -- ipv6 addresses for the -- mip6BindingHstHomeAddress object. -- -- OBJECT mip6BindingHstHomeAddress -- SYNTAX InetAddress (SIZE 16) -- DESCRIPTION -- This MIB module requires support for global -- ipv6 addresses for the -- mip6BindingHstHomeAddress object. -- -- OBJECT mip6MnHomeAddressType -- SYNTAX InetAddressType (ipv6(2)) -- DESCRIPTION -- This MIB module requires support for global -- ipv6 addresses for the mip6MnHomeAddress -- object. -- -- OBJECT mip6MnHomeAddress -- SYNTAX InetAddress (SIZE 16) -- DESCRIPTION -- This MIB module requires support for global -- ipv6 addresses for the mip6MnHomeAddress -- object. -- -- OBJECT mip6MnBLNodeAddressType -- SYNTAX InetAddressType (ipv6(2)) -- DESCRIPTION -- This MIB module requires support for global -- ipv6 addresses for the mip6MnBLNodeAddress -- object. -- -- OBJECT mip6MnBLNodeAddress -- SYNTAX InetAddress (SIZE 16) -- DESCRIPTION -- This MIB module requires support for global -- ipv6 addresses for the mip6MnBLNodeAddress -- object. -- -- OBJECT mip6HaLinkLocalAddressType -- SYNTAX InetAddressType (ipv6z(4)) -- DESCRIPTION -- This MIB module requires support for local -- ipv6 addresses for the mip6HaLinkLocalAddress -- object -- -- OBJECT mip6HaLinkLocalAddressType -- SYNTAX InetAddress (SIZE 20) -- DESCRIPTION -- This MIB module requires support for local -- ipv6 addresses for the mip6HaLinkLocalAddress -- object. -- " NEW: -- OBJECT mip6BindingHomeAddressType -- SYNTAX InetAddressType { ipv6(2) } -- DESCRIPTION -- This MIB module requires support for global -- ipv6 addresses for the mip6BindingHomeAddress -- object. -- -- OBJECT mip6BindingHomeAddress -- SYNTAX InetAddress (SIZE(16)) -- DESCRIPTION -- This MIB module requires support for global -- ipv6 addresses for the mip6BindingHomeAddress -- object. -- -- OBJECT mip6BindingHstHomeAddressType -- SYNTAX InetAddressType { ipv6(2) } -- DESCRIPTION -- This MIB module requires support for global -- ipv6 addresses for the -- mip6BindingHstHomeAddress object. -- -- OBJECT mip6BindingHstHomeAddress -- SYNTAX InetAddress (SIZE(16)) -- DESCRIPTION -- This MIB module requires support for global -- ipv6 addresses for the -- mip6BindingHstHomeAddress object. -- -- OBJECT mip6MnHomeAddressType -- SYNTAX InetAddressType { ipv6(2) } -- DESCRIPTION -- This MIB module requires support for global -- ipv6 addresses for the mip6MnHomeAddress -- object. -- -- OBJECT mip6MnHomeAddress -- SYNTAX InetAddress (SIZE(16)) -- DESCRIPTION -- This MIB module requires support for global -- ipv6 addresses for the mip6MnHomeAddress -- object. -- -- OBJECT mip6MnBLNodeAddressType -- SYNTAX InetAddressType { ipv6(2) } -- DESCRIPTION -- This MIB module requires support for global -- ipv6 addresses for the mip6MnBLNodeAddress -- object. -- -- OBJECT mip6MnBLNodeAddress -- SYNTAX InetAddress (SIZE(16)) -- DESCRIPTION -- This MIB module requires support for global -- ipv6 addresses for the mip6MnBLNodeAddress -- object. -- -- OBJECT mip6HaLinkLocalAddressType -- SYNTAX InetAddressType { ipv6z(4) } -- DESCRIPTION -- This MIB module requires support for local -- ipv6 addresses for the mip6HaLinkLocalAddress -- object -- -- OBJECT mip6HaLinkLocalAddressType -- SYNTAX InetAddress (SIZE(20)) -- DESCRIPTION -- This MIB module requires support for local -- ipv6 addresses for the mip6HaLinkLocalAddress -- object. -- " (f) In the following OBJECT-GROUP definition mip6MnSystemGroup OBJECT-GROUP OBJECTS { -- mip6MnHomeAddressType, -- mip6MnHomeAddress, mip6MnHomeAddressState } please remove the commented-out INDEX objects mip6MnHomeAddressType and mip6MnHomeAddress. They are mentioned in the DESCRIPTION clause of mip6CoreCompliance (see above), and that is sufficient; their presence here is not helpful. (g) Is the following a typo, which should have said "mip6HaReadOnlyCompliance2"? mip6HaiReadOnlyCompliance2 MODULE-COMPLIANCE [ ... ] ::= { mip6Compliances 15 } (h) mip6HaReadOnlyCompliance3 includes mip6BindingCacheCtlGroup in the MANDATORY-GROUPS list, but does not have an OBJECT clause for mip6BindingAdminStatus that specifies a MIN-ACCESS of read-only. This oversight needs to be corrected. Please note that I have not yet performed a front-to-back review of the MOBILEIPV6-MIB for correctness of each object definition. I promise to do so in a forthcoming review. Regards, Mike Heard _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Oct 15 09:49:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29839 for ; Fri, 15 Oct 2004 09:49:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CISeR-0007h6-61 for mip6-web-archive@ietf.org; Fri, 15 Oct 2004 10:01:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CISRL-0004CE-Rc; Fri, 15 Oct 2004 09:48:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CISNk-0003fz-Hi for mip6@megatron.ietf.org; Fri, 15 Oct 2004 09:44:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29143 for ; Fri, 15 Oct 2004 09:44:30 -0400 (EDT) From: Basavaraj.Patil@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CISZ7-0007X6-Li for mip6@ietf.org; Fri, 15 Oct 2004 09:56:18 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9FDiTh27186 for ; Fri, 15 Oct 2004 16:44:29 +0300 (EET DST) X-Scanned: Fri, 15 Oct 2004 16:44:24 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i9FDiO0i008433 for ; Fri, 15 Oct 2004 16:44:24 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00Yzj573; Fri, 15 Oct 2004 16:44:23 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9FDiMS26695 for ; Fri, 15 Oct 2004 16:44:22 +0300 (EET DST) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 15 Oct 2004 08:43:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 15 Oct 2004 08:43:51 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF4403B1BFA0@daebe007.americas.nokia.com> Thread-Topic: Request security perspective for Mobile IPv6 I-D Thread-Index: AcSyRlQu3HAmw5ddS/WKnfI//s8aigAdnRUQ To: X-OriginalArrivalTime: 15 Oct 2004 13:43:53.0483 (UTC) FILETIME=[0290E5B0:01C4B2BD] X-Spam-Score: 0.3 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Content-Transfer-Encoding: quoted-printable Subject: [Mip6] FW: Request security perspective for Mobile IPv6 I-D [Auth-protocol] X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Content-Transfer-Encoding: quoted-printable Feeback from the security directorate on the Auth-protocol proposal. -BPa > -----Original Message----- > From: ext Radia Perlman [mailto:Radia.Perlman@Sun.COM] > Sent: Thursday, October 14, 2004 6:34 PM > To: Russ Housley > Cc: hartmans@mit.edu; Patil Basavaraj=20 > gdommety@cisco.com; smb@research.att.com > Subject: Re: Request security perspective for Mobile IPv6 I-D >=20 >=20 > I'd like to see more description of why IPsec is not compatible with=20 > MIP6. Unless > there's something really special about MIP6, then if IPsec won't meet=20 > their needs > or is too much work, then IPsec should be changed. >=20 > If inventing a new mechanism is because of a short term "this is what=20 > the implementations > are doing now", I think instead it would be better to switch=20 > to IPsec,=20 > so that there > aren't lots of different security protocols being invented. >=20 > Admittedly, IPsec has a bunch of functionality that you don't=20 > need, like > encryption and perfect forward secrecy. So your mechanism is=20 > certainly=20 > simpler. > If it was implementing that instead of IPsec, then certainly I could=20 > imagine the > appeal. However, if the node will wind up implementing IPsec=20 > anyway, it=20 > doesn't > seem like it should be that hard to use it for MIP6. But=20 > maybe I don't=20 > understand > the issues (like why existing hardware doing IPsec would have to be=20 > modified to > support MIPv6....maybe because the existing hardware is only=20 > doing IPv4,=20 > in which > case the hardware would just ignore IPv6 packets, I'd assume,=20 > so maybe=20 > that's > what you mean...that you'd have to change the hardware to do=20 > IPsec for=20 > IPv6). >=20 > Aside from whether there should be another mechanism, the=20 > only issue I=20 > could see > is how you avoid replay. With the "identification option" you=20 > make sure=20 > that an > old message outside of the acceptable window will be=20 > discarded. But if=20 > the acceptable > window were, say, 10 minutes, then it would seem like an=20 > attacker would=20 > be able > to continue to replay a message for 10 minutes (or worse, if the=20 > client's clock is > n minutes ahead of the server's). >=20 > Radia >=20 >=20 >=20 > Russ Housley wrote: >=20 > > Radia and Sam: > > > > Please review for the Security Directorate. > > > > Please respond directly to Basavaraj.Patil@nokia.com and=20 > > gdommety@cisco.com, but CC housley@vigilsec.com and=20 > > smb@research.att.com too. > > > > Russ > > > > > > > -----Original Message----- > > > From: Patil Basavaraj=20 > > > Sent: Thursday, October 07, 2004 1:56 PM > > > To: housley@vigilsec.com; smb@research.att.com > > > Cc: Thomas Narten; Gopal Dommety (E-mail); Margaret=20 > Wasserman (E-mail) > > > Subject: Request security perspective for Mobile IPv6 I-D > > > > > > Hello Security ADs, > > > > > > The Mobile IPv6 WG is currently proposing a mechanism to allow a > > > Mobile node (MN) to register with its Home agent (HA) via an > > > authentication mechanism which involves carrying Auth-Data via > > > an authentication-data-suboption within the binding > > > update/Ack messages. > > > This mechanism is akin to the one that is currently used in Mobile > > > IPv4. > > > RFC3775/6 which specify Mobile IPv6, currently mandate the > > > establishment > > > of an IPsec SA between the MN and HA and thus=20 > authentication of the MN > > > is achieved via the presence of this SA. The Binding > > > update/Ack messages > > > are secured using IPsec ESP (from the MN-HA SA). > > > > > > The proposal to authenticate a MN to its HA in the=20 > absence of an IPsec > > > SA is specified in I-D: > > >=20 > http://ietf.org/internet-drafts/draft-ietf-mip6-auth-protocol-00.txt > > > > > > The justifications for why this is needed are contained in: > > > http://ietf.org/internet-drafts/draft-patil-mip6-whyauthdataop > > tion-00.txt > > as well as some additional justifications at: > > http://www1.ietf.org/mail-archive/web/mip6/current/msg01657.html > > > > We would appreciate your views from a security perspective on=20 > > standardizing > > the authentication of a MIP6 MN to its HA using Auth-data=20 > carried in=20 > > the BU. > > > > Rgds, > > -Basavaraj >=20 >=20 >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Oct 15 18:08:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28594 for ; Fri, 15 Oct 2004 18:08:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIaRB-00077g-Jb for mip6-web-archive@ietf.org; Fri, 15 Oct 2004 18:20:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIaEj-0005Fk-8k; Fri, 15 Oct 2004 18:07:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIa2R-0007U0-5f for mip6@megatron.ietf.org; Fri, 15 Oct 2004 17:55:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27447 for ; Fri, 15 Oct 2004 17:55:00 -0400 (EDT) From: Basavaraj.Patil@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIaDs-0006qR-2S for mip6@ietf.org; Fri, 15 Oct 2004 18:06:53 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9FLt0h28452 for ; Sat, 16 Oct 2004 00:55:00 +0300 (EET DST) X-Scanned: Sat, 16 Oct 2004 00:54:53 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i9FLsrWW022236 for ; Sat, 16 Oct 2004 00:54:53 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00MVyPGa; Sat, 16 Oct 2004 00:54:52 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9FLsoa16777 for ; Sat, 16 Oct 2004 00:54:51 +0300 (EET DST) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 15 Oct 2004 16:54:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 15 Oct 2004 16:54:49 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF4403B1BFB5@daebe007.americas.nokia.com> Thread-Topic: WGLC: I-D draft-ietf-mip6-bootstrap-ps-01.txt Thread-Index: AcSzAZeje317ZfECRoe1ZdKl6aA5UA== To: X-OriginalArrivalTime: 15 Oct 2004 21:54:50.0353 (UTC) FILETIME=[983A8E10:01C4B301] X-Spam-Score: 0.3 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: quoted-printable Subject: [Mip6] WGLC: I-D draft-ietf-mip6-bootstrap-ps-01.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable Hello, This is a Working Group last call for the following I-D: I-D :draft-ietf-mip6-bootstrap-ps-01.txt Title: Problem Statement for bootstrapping Mobile IPv6 The status associated with this I-D is : Informational and will be progressed as such. Please review and post your comments by October 30th, 2004. -Chairs URL to I-D: http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrap-ps-01.txt _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Oct 18 09:44:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17172 for ; Mon, 18 Oct 2004 09:44:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJY0U-0000W5-43 for mip6-web-archive@ietf.org; Mon, 18 Oct 2004 09:57:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJXjG-0001mH-9W; Mon, 18 Oct 2004 09:39:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJXhe-0001UK-Jd for mip6@megatron.ietf.org; Mon, 18 Oct 2004 09:37:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16066 for ; Mon, 18 Oct 2004 09:37:33 -0400 (EDT) From: Basavaraj.Patil@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJXtd-0000KO-KU for mip6@ietf.org; Mon, 18 Oct 2004 09:49:59 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9IDbUW28258 for ; Mon, 18 Oct 2004 16:37:30 +0300 (EET DST) X-Scanned: Mon, 18 Oct 2004 16:37:21 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i9IDbLak018479 for ; Mon, 18 Oct 2004 16:37:21 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 003rCeHd; Mon, 18 Oct 2004 16:37:20 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9IDbES16289 for ; Mon, 18 Oct 2004 16:37:14 +0300 (EET DST) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 18 Oct 2004 08:34:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Oct 2004 08:34:56 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF4403B1BFBC@daebe007.americas.nokia.com> Thread-Topic: Request security perspective for Mobile IPv6 I-D Thread-Index: AcS0voWY98yS7V++R32T6gyvINqt3wAWKVjw To: X-OriginalArrivalTime: 18 Oct 2004 13:34:56.0920 (UTC) FILETIME=[41FD2180:01C4B517] X-Spam-Score: 0.3 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable Subject: [Mip6] FW: Request security perspective for Mobile IPv6 I-D [Auth-ID] X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable Security feedback on the auth-ID proposal from the security directorate: > -----Original Message----- > From: ext Sam Hartman [mailto:hartmans@mit.edu] > Sent: Sunday, October 17, 2004 9:58 PM > To: Radia Perlman > Cc: Russ Housley; Patil Basavaraj (Nokia-NET/Dallas); > gdommety@cisco.com; smb@research.att.com > Subject: Re: Request security perspective for Mobile IPv6 I-D >=20 >=20 > I'm fairly busy now so I only have time for a brief review. >=20 >=20 > I tend to agree with Radia's comments. I think that a better approach > than standardizing this option would be to write up an explanation of > what is wrong with IPSec and asking the IPSec community to fix their > protocol to meet your needs. >=20 > Several of the concerns that you propose do sound like global problems > with IPSec. For example the IETF either needs to decide that IPSec > should not be used to secure other protocols (unlikely) or decide how > to deal with multiple applications needing to interact with the SPD. >=20 > In general it makes me uncomfortable when some application tries to > invent an authentication protocol. It is hard to deploy security when > the authentication expected by a particular application does not use > the same credentials as your security infrastructure already supports. > You end up having to define support for all the common authentication > credentials to each of these authentication protocols and you > significantly increase the work necessary if someone wants to come up > with a new type of credential. >=20 > If IPSec really is not an appropriate option, you should rule out all > the other IETF authentication protocols including EAP, GSSAPI, TLS and > CMS before defining your own. >=20 >=20 > I briefly looked at the actual draft specifying the authentication > option. I found it incredibly hard to understand; it seemed to reuse > IPSec terminology in a manner inconsistent with IPSec without defining > the tirms. The draft also does not provide a way to negotiate new > hashes. What will happen when a problem is found with SHA-1? =20 >=20 > Those are my initial thoughts. >=20 > --Sam >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Oct 18 22:29:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20693 for ; Mon, 18 Oct 2004 22:29:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJjwO-0000M0-0Q for mip6-web-archive@ietf.org; Mon, 18 Oct 2004 22:41:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJjbg-00024u-Ov; Mon, 18 Oct 2004 22:20:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJjVi-0000p3-Qn for mip6@megatron.ietf.org; Mon, 18 Oct 2004 22:14:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19370 for ; Mon, 18 Oct 2004 22:13:55 -0400 (EDT) Received: from cms5.etri.re.kr ([129.254.16.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJjhj-0008Sy-Gy for mip6@ietf.org; Mon, 18 Oct 2004 22:26:28 -0400 Received: from RESTART (jhjee.etri.re.kr [129.254.242.56]) by cms5.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id TGWBWD0V; Tue, 19 Oct 2004 11:19:03 +0900 Message-ID: <002c01c4b581$3be68bf0$38f2fe81@RESTART> From: "Junghoon Jee" To: Subject: [Mip6] New I-D: Diameter Mobile IPv6 Bootstrapping Application using PANA Date: Tue, 19 Oct 2004 11:13:33 +0900 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 1.2 (+) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1731714112==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 1.2 (+) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 --===============1731714112== Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGVsbG8sIEFMTC4NCg0KSGVyZSBpcyBhIG5ldyBJLUQsIERpYW1ldGVyIE1vYmlsZSBJUHY2IEJv b3RzdHJhcHBpbmcgQXBwbGljYXRpb24gdXNpbmcgUEFOQS4NCg0KQWJzdHJhY3Q6DQogIFRoaXMg ZG9jdW1lbnQgc3BlY2lmaWVzIGEgbmV3IERpYW1ldGVyIEFwcGxpY2F0aW9uIHRvIHN1cHBvcnQg dGhlIA0KICAgTW9iaWxlIElQdjYncyBib290c3RyYXBwaW5nIG1lY2hhbmlzbSBkdXJpbmcgdGhl IEFBQSBhdXRoZW50aWNhdGlvbiANCiAgIGFuZCBhdXRob3JpemF0aW9uIHBoYXNlIGJhc2VkIG9u IFBBTkEuIFBBTkEgaXMgdXNlZCBhcyBhIHByb3RvY29sIGZvciANCiAgIG5ldHdvcmsgYXV0aGVu dGljYXRpb24gYmV0d2VlbiBtb2JpbGUgbm9kZXMgYW5kIGFjY2VzcyBuZXR3b3Jrcy4gDQogICBE dXJpbmcgdGhlIFBBTkEgYXV0aGVudGljYXRpb24gcGhhc2UsIHRoZSBtb2JpbGUgbm9kZSdzIGlu aXRpYWwgDQogICBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9uIGxpa2UgaXRzIGhvbWUgYWRkcmVz cywgaG9tZSBhZ2VudCBhZGRyZXNzIA0KICAgYW5kIElLRSBwcmUtc2hhcmVkIGtleWluZyBtYXRl cmlhbCBpcyBwaWdneWJhY2tlZCB0byB0aGUgUEFOQSANCiAgIG1lc3NhZ2VzIGNyeXB0b2dyYXBo aWNhbGx5IHByb3RlY3RlZCBieSB0aGUgUEFOQSBTQS4gVGhlIERpYW1ldGVyIGFuZCANCiAgIFBB TkEgbWVzc2FnZSBmb3JtYXRzIHRvIHN1cHBvcnQgdGhlIE1vYmlsZSBJUHY2IGJvb3RzdHJhcHBp bmcgYXJlIA0KICAgZGVmaW5lZC4gDQoNClVSTCB0byBJLUQ6DQpodHRwOi8vd3d3LmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy9kcmFmdC1qZWUtbWlwNi1ib290c3RyYXAtcGFuYS0wMC50eHQNCg0K Q29tbWVudHMgYXJlIHdlbGNvbWUuDQoNCg0KSnVuZ2hvb24gSmVlDQoNCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIA0KRWxlY3Ryb25pY3MgYW5kIFRl bGVjb21tdW5pY2F0aW9ucyBSZXNlYXJjaCBJbnN0aXR1dGUgDQoxNjEgR2FqZW9uZy1kb25nLCBZ dXNlb25nLWd1LCBEYWVqZW9uLCAzMDUtMzUwLCBSZXAuIG9mIEtPUkVBIA0KRS1tYWlsOiBqaGpl ZUBldHJpLnJlLmtyIChKdW5naG9vbiBKRUUpIA0KVGVsOiArODIgNDIgODYwIDUxMjYsIE1vYmls ZTogKzgyIDExIDkwMzAgMDA1MSANCg0K --===============1731714112== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1731714112==-- From mip6-bounces@ietf.org Tue Oct 19 13:49:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21735 for ; Tue, 19 Oct 2004 13:49:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJyJC-0004uZ-4p for mip6-web-archive@ietf.org; Tue, 19 Oct 2004 14:02:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJsm6-0006wq-0o; Tue, 19 Oct 2004 08:07:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJsT3-0003jA-Bo for mip6@megatron.ietf.org; Tue, 19 Oct 2004 07:47:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14214 for ; Tue, 19 Oct 2004 07:47:46 -0400 (EDT) Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJsf9-0002Sj-OL for mip6@ietf.org; Tue, 19 Oct 2004 08:00:24 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id i9JBlhP6005057; Tue, 19 Oct 2004 13:47:43 +0200 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id i9JBlgBO017116; Tue, 19 Oct 2004 13:47:42 +0200 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id <4BVRY13A>; Tue, 19 Oct 2004 13:47:42 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F046868E9@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Junghoon Jee'" , mip6@ietf.org Subject: RE: [Mip6] New I-D: Diameter Mobile IPv6 Bootstrapping Applicatio n using PANA Date: Tue, 19 Oct 2004 13:47:36 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 hi junghoon, i have only read the title of your document but you might be interested in the following document: Bootstrapping Mobile IPv6 using PANA http://www.tschofenig.com/drafts/draft-tschofenig-mip6-bootstrapping-pana-00 .txt ciao hannes > -----Original Message----- > From: Junghoon Jee [mailto:jhjee@etri.re.kr] > Sent: Tuesday, October 19, 2004 4:14 AM > To: mip6@ietf.org > Subject: [Mip6] New I-D: Diameter Mobile IPv6 Bootstrapping > Application using PANA > > Hello, ALL. > > Here is a new I-D, Diameter Mobile IPv6 Bootstrapping > Application using PANA. > > Abstract: > This document specifies a new Diameter Application to support the > Mobile IPv6's bootstrapping mechanism during the AAA > authentication > and authorization phase based on PANA. PANA is used as a > protocol for > network authentication between mobile nodes and access networks. > During the PANA authentication phase, the mobile node's initial > configuration information like its home address, home > agent address > and IKE pre-shared keying material is piggybacked to the PANA > messages cryptographically protected by the PANA SA. The > Diameter and > PANA message formats to support the Mobile IPv6 bootstrapping are > defined. > > URL to I-D: > http://www.ietf.org/internet-drafts/draft-jee-mip6-bootstrap-p > ana-00.txt > > Comments are welcome. > > > Junghoon Jee > > -------------------------------------------------- > Electronics and Telecommunications Research Institute > 161 Gajeong-dong, Yuseong-gu, Daejeon, 305-350, Rep. of KOREA > E-mail: jhjee@etri.re.kr (Junghoon JEE) > Tel: +82 42 860 5126, Mobile: +82 11 9030 0051 > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Oct 19 17:12:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13638 for ; Tue, 19 Oct 2004 17:12:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK1TU-0002k9-RF for mip6-web-archive@ietf.org; Tue, 19 Oct 2004 17:24:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJsml-00076S-4T; Tue, 19 Oct 2004 08:08:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJsUe-0003wx-MJ; Tue, 19 Oct 2004 07:49:32 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14562; Tue, 19 Oct 2004 07:49:31 -0400 (EDT) Message-Id: <200410191149.HAA14562@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 19 Oct 2004 07:49:31 -0400 Cc: mip6@ietf.org Subject: [Mip6] I-D ACTION:draft-ietf-mip6-ro-sec-02.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv6 Working Group of the IETF. Title : Mobile IP version 6 Route Optimization Security Design Background Author(s) : P. Nikander, et al. Filename : draft-ietf-mip6-ro-sec-02.txt Pages : 40 Date : 2004-10-18 This document is a succint account of the rationale behind the Mobile IPv6 (MIPv6) Route Optimization Security Design. The purpose of this document is to present the thinking and to preserve the reasoning behind the Mobile IPv6 Security Design in 2001-2002. The document has two target audiences: (1) MIPv6 implementors so that they can better understand the design choices in MIPv6 security procedures; and (2) people dealing with mobility or multi-homing so that they can avoid a number of potential security pitfalls in their design. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-ro-sec-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mip6-ro-sec-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip6-ro-sec-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-18173202.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-ro-sec-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-ro-sec-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-18173202.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --NextPart-- From mip6-bounces@ietf.org Tue Oct 19 22:19:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16836 for ; Tue, 19 Oct 2004 22:19:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK6Gh-0003WQ-0i for mip6-web-archive@ietf.org; Tue, 19 Oct 2004 22:32:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK4Cg-0003x2-UQ; Tue, 19 Oct 2004 20:19:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJvvx-0002e9-Uz for mip6@megatron.ietf.org; Tue, 19 Oct 2004 11:29:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07155 for ; Tue, 19 Oct 2004 11:29:55 -0400 (EDT) Received: from laposte.enst-bretagne.fr ([192.108.115.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJw8A-0000aL-IF for mip6@ietf.org; Tue, 19 Oct 2004 11:42:36 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i9JFTI210552; Tue, 19 Oct 2004 17:29:18 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i9JFTJSj086505; Tue, 19 Oct 2004 17:29:19 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200410191529.i9JFTJSj086505@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Basavaraj.Patil@nokia.com Subject: Re: [Mip6] MIP6 WG meeting at IETF61 In-reply-to: Your message of Wed, 13 Oct 2004 10:47:00 CDT. <697DAA22C5004B4596E033803A7CEF4403B1BF5D@daebe007.americas.nokia.com> Date: Tue, 19 Oct 2004 17:29:19 +0200 X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 In your previous mail you wrote: If you would like a timeslot on the MIP6 WG agenda, please send a request to the chairs. Include in the request: => I have two requests (already presented but not discussed enough so no decission was taken): -------------------------------- FIRST -------------------------------- 1. Discussion Topic => use of IPsec to protect signaling between MN and CN 2. Draft Name => draft-dupont-mipv6-cn-ipsec-01.txt 3. Slot Duration => 5 minutes (1 minute presentation, 4 minutes discussion) 4. Is this in the scope of the Charter? (if not explain the relation) => quoting the charter: "Mechanisms using a shared secret Key/Security Association will be considered." 5. What do you want to accomplish by this presentation (e.g resolve the following issues) => make the draft a WG item and/or what is missing in it. 6. Was this draft discussed in the mailing list => not enough! 7. Are there any open issues? => none (note I implemented it) -------------------------------- SECOND -------------------------------- 1. Discussion Topic => care-of address test procedure using a state cookie 2. Draft Name => Annex of draft-dupont-mipv6-cn-ipsec-01.txt (note I am extracting it to make a stand-alone document, an XML version should be available soon) 3. Slot Duration => 5 minutes (3 minutes presentation, 2 minutes to find someone else who needs it) 4. Is this in the scope of the Charter? (if not explain the relation) => same argument (Mechanisms using a shared secret Key/Security Association will be considered): these mechanisms don't provide a built-in care-of address test. 5. What do you want to accomplish by this presentation (e.g resolve the following issues) => find someone else (i.e., another alternative to the RR procedure) who (which) needs it and very shortly discussed if the solution is good or can be improved. 6. Was this draft discussed in the mailing list => not enough, in particular I don't know who share my feeling that to initiate the care-of address test by the CN is good. 7. Are there any open issues? => IANA considerations (so a WG document status should be fine) Regard Francis.Dupont@enst-bretagne.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Oct 19 23:57:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23508 for ; Tue, 19 Oct 2004 23:57:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK7ne-0005bp-B8 for mip6-web-archive@ietf.org; Wed, 20 Oct 2004 00:10:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK4iV-0003dN-Kj; Tue, 19 Oct 2004 20:52:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK0FA-0004b7-UY for mip6@megatron.ietf.org; Tue, 19 Oct 2004 16:06:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07535 for ; Tue, 19 Oct 2004 16:05:57 -0400 (EDT) Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK0RL-0000gM-DR for mip6@ietf.org; Tue, 19 Oct 2004 16:18:40 -0400 Received: from eamrcnt751.exu.ericsson.se (eamrcnt751.exu.ericsson.se [138.85.133.52]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i9JK67CR027605; Tue, 19 Oct 2004 15:06:07 -0500 (CDT) Received: by eamrcnt751.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id <47WD0J09>; Tue, 19 Oct 2004 15:05:20 -0500 Received: from [142.133.113.83] (142.133.113.83 [142.133.113.83]) by EAMMLEX034.dyn.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 4L000TAZ; Tue, 19 Oct 2004 16:04:20 -0400 From: Wassim Michel Haddad To: mip6@ietf.org Content-Type: text/plain Organization: Ericsson Research Canada Message-Id: <1098216305.2150.141.camel@127750> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 19 Oct 2004 16:05:05 -0400 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: multi6@ietf.org Subject: [Mip6] [Fwd: I-D ACTION:draft-haddad-momipriv-problem-statement-00.txt] X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Wassim.Haddad@ericsson.ca List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Hi all, > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Privacy for Mobile and Multi-homed Nodes: MoMiPriv > Problem Statement > Author(s) : W. Haddad, et al. > Filename : draft-haddad-momipriv-problem-statement-00.txt > Pages : 13 > Date : 2004-10-18 > > This memo describes the privacy in mobility and multi-homing problem > statement. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-haddad-momipriv-problem-statement-00.txt Comments are appreciated. Regards, Wassim H _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Oct 20 01:04:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28607 for ; Wed, 20 Oct 2004 01:04:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK8qh-0007A0-8x for mip6-web-archive@ietf.org; Wed, 20 Oct 2004 01:17:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK5FB-0001yL-9H; Tue, 19 Oct 2004 21:26:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK3fe-0007Ar-Js for mip6@megatron.ietf.org; Tue, 19 Oct 2004 19:45:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03400 for ; Tue, 19 Oct 2004 19:45:30 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK3rq-00084L-Rg for mip6@ietf.org; Tue, 19 Oct 2004 19:58:16 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i9JNHif00589 for ; Tue, 19 Oct 2004 16:17:44 -0700 X-mProtect: <200410192317> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd1HnOOl; Tue, 19 Oct 2004 16:17:43 PDT Message-ID: <4175AA16.8040000@iprg.nokia.com> Date: Tue, 19 Oct 2004 16:58:14 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040430 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mip6@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Subject: [Mip6] Mobile IPv6 and IKEv2 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit hi all, here is a draft I submitted before the deadline on the use of IKEv2 and the revised IPsec architecture with Mobile IPv6. it is a very early version and I am certain it has many issues. :) for some reason, it hasnt been announced yet. meanwhile you can access it at http://people.nokia.net/vijayd/mip6/draft-ietf-mip6-ikev2-ipsec-00.txt it revises the SPD and SAD configuration examples described in RFC 3776. it allows the use of EAP to authenticate the MN in addition to using shared secrets and public key based mechanisms during IKE negotiation. it also allows the MN to configure a Home Address from the Home Agent using the Configuration Payload in IKEv2. comments are welcome. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Oct 20 05:25:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13771 for ; Wed, 20 Oct 2004 05:25:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKCun-0003fy-5r for mip6-web-archive@ietf.org; Wed, 20 Oct 2004 05:37:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK9L0-0004h1-1Z; Wed, 20 Oct 2004 01:48:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK6v4-00031U-M1 for mip6@megatron.ietf.org; Tue, 19 Oct 2004 23:13:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20785 for ; Tue, 19 Oct 2004 23:13:39 -0400 (EDT) Received: from neon.tcs.hut.fi ([130.233.215.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK77I-0004eB-T5 for mip6@ietf.org; Tue, 19 Oct 2004 23:26:26 -0400 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id EE5F080035B for ; Wed, 20 Oct 2004 06:13:07 +0300 (EEST) Date: Wed, 20 Oct 2004 06:13:07 +0300 (EEST) From: Wassim Haddad To: mip6@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Mip6] I-D ACTION:draft-haddad-momipriv-problem-statement-00.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Hi all, > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Privacy for Mobile and Multi-homed Nodes: > MoMiPriv Problem Statement > Author(s) : W. Haddad, et al. > Filename : draft-haddad-momipriv-problem-statement-00.txt > Pages : 13 > Date : 2004-10-18 > > This memo describes the privacy in mobility and multi-homing problem > statement. > > A URL for this Internet-Draft is: > http://ietf.org/internet-drafts/draft-haddad-momipriv-problem-statement-00.txt Comments are appreciated. Regards, Wassim H. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Oct 20 21:46:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06646 for ; Wed, 20 Oct 2004 21:46:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKSEh-0000YX-CL for mip6-web-archive@ietf.org; Wed, 20 Oct 2004 21:59:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKIQw-0007BE-RJ; Wed, 20 Oct 2004 11:31:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKHlC-0001pW-Tn; Wed, 20 Oct 2004 10:48:19 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11327; Wed, 20 Oct 2004 10:48:16 -0400 (EDT) Message-Id: <200410201448.KAA11327@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 20 Oct 2004 10:48:16 -0400 Cc: mip6@ietf.org Subject: [Mip6] I-D ACTION:draft-ietf-mip6-ikev2-ipsec-00.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv6 Working Group of the IETF. Title : Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture Author(s) : V. Devarapalli Filename : draft-ietf-mip6-ikev2-ipsec-00.txt Pages : 21 Date : 2004-10-19 This document describes Mobile IPv6 operation with the revised IPsec architecture and IKEv2. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-ikev2-ipsec-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mip6-ikev2-ipsec-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip6-ikev2-ipsec-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-20105421.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-ikev2-ipsec-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-ikev2-ipsec-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-20105421.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --NextPart-- From mip6-bounces@ietf.org Thu Oct 21 07:29:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03658 for ; Thu, 21 Oct 2004 07:29:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKbLN-0004y1-Cf for mip6-web-archive@ietf.org; Thu, 21 Oct 2004 07:42:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKTFX-00071o-E0; Wed, 20 Oct 2004 23:04:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKIVj-0000lv-G9 for mip6@megatron.ietf.org; Wed, 20 Oct 2004 11:36:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15195 for ; Wed, 20 Oct 2004 11:36:15 -0400 (EDT) Received: from mail-eur.microsoft.com ([213.199.128.145]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKIi5-0003CB-JW for mip6@ietf.org; Wed, 20 Oct 2004 11:49:09 -0400 Received: from EUR-MSG-20.europe.corp.microsoft.com ([65.53.210.18]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 20 Oct 2004 16:35:44 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Mobile IPv6 and IKEv2 Date: Wed, 20 Oct 2004 16:35:43 +0100 Message-ID: <892867B805D4DA42A1C48103BF4CFA5A8EDEB7@EUR-MSG-20.europe.corp.microsoft.com> Thread-Topic: [Mip6] Mobile IPv6 and IKEv2 Thread-Index: AcS2Y/ypBdWkS8ZORsGIfpl7WKJEmAARfdiQ From: "Michael Roe" To: X-OriginalArrivalTime: 20 Oct 2004 15:35:44.0212 (UTC) FILETIME=[7689A140:01C4B6BA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: quoted-printable X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: quoted-printable Vijay, Thanks for circulating draft-ietf-mip6-ikev2-ipsec-00.txt. In section 3.2, you say that: "It is not required to configure security policies per interface in order to protect return routability signaling messages." This is true, but I found it misleading. The ability to configure security policies per interface is still used to protect payload packets, even though it is no longer used for RR messages. The document doesn't make this very clear, because section 4.4 (Payload packets) just refers you to RFC 3776 for the SPD entry. You have to go and read section 5.2.4 of RFC 3776 to find out that per-interface SPDs are still used: mobile node SPD OUT: - IF interface =3D IPv6 tunnel to home_agent_1 & source =3D home_address_1 & destination =3D any & proto =3D X THEN USE SA SA7 mobile node SPD IN: - IF interface =3D IPv6 tunnel from home_agent_1 & source =3D any & destination =3D home_address_1 & proto =3D X THEN USE SA SA8 I have two suggestions that would solve the immediate problem: (a) Section 3.2 should make it clear that if IPsec protection of payload = packets is implemented, then per interface SPDs are still required and (b) Section 5.1.4 should describe the SPD entry for payload packets, = rather than referring the reader to RFC 3776, so that the whole SPD is = described in one document. However, there's some deeper problems: (a) RFC 3776 treats "interface =3D IPv6 tunnel to home_agent_1" as a = selector. In the new IPSec architecture, is it really a selector? Or are there = just two SPD's on different interfaces? So should it be something more like this: mobile node SPD OUT 1: # SPD on tunnel to home agent - IF source =3D home_address_1 & destination =3D any & proto =3D X THEN USE SA SA7 mobile node SPD IN 1: # SPD on tunnel to home agent - IF source =3D any & destination =3D home_address_1 & proto =3D X THEN USE SA SA8 mobile node SPD OUT 2: # SPD for other interfaces mobile node SPD IN 2: # SPD for other interfaces (b) Is this a legitimate use of per-interface SPDs? Now, I can understand how a machine with two physical interfaces can have a different SPD for each one. But here, when IPSec processes an outbound packet, it has to decide whether "interface =3D IPv6 tunnel to home_agent_1" is true BEFORE it decides to USE SA7 - ie. put the packet in the tunnel. So this policy is saying "if the packet uses the tunnel to the home agent, then use the tunnel to the home agent". This looks like a circular dependency to me - I think there's something not quite right about it. Another way of modelling it might be to use the "SPD Selection Function", and say that a mobile node with home addresses on N different networks has (N+1) SPDs - and the MIPv6 code swaps in the appropriate SPD every time the mobile node moves. Maybe it should be like this: mobile node SPD OUT 1: # SPD when mobile is away from home - IF source =3D home_address_1 & destination =3D any & proto =3D X THEN USE SA SA7 mobile node SPD IN 1: # SPD when mobile is away from home - IF source =3D any & destination =3D home_address_1 & proto =3D X THEN USE SA SA8 mobile node SPD OUT 2: # SPD when mobile is at home mobile node SPD IN 2: # SPD when mobile is at home Mike _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Oct 21 10:08:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01741 for ; Thu, 21 Oct 2004 10:08:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKdoR-0003jZ-F7 for mip6-web-archive@ietf.org; Thu, 21 Oct 2004 10:21:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKdVH-0007P7-VI; Thu, 21 Oct 2004 10:01:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKdOQ-00048B-Sh for mip6@megatron.ietf.org; Thu, 21 Oct 2004 09:54:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29915 for ; Thu, 21 Oct 2004 09:54:12 -0400 (EDT) Received: from laposte.enst-bretagne.fr ([192.108.115.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKdb2-0003Gt-Gj for mip6@ietf.org; Thu, 21 Oct 2004 10:07:18 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i9LDre808548; Thu, 21 Oct 2004 15:53:40 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i9LDrfSj096086; Thu, 21 Oct 2004 15:53:41 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200410211353.i9LDrfSj096086@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Michael Roe" Subject: Re: [Mip6] Mobile IPv6 and IKEv2 In-reply-to: Your message of Wed, 20 Oct 2004 16:35:43 BST. <892867B805D4DA42A1C48103BF4CFA5A8EDEB7@EUR-MSG-20.europe.corp.microsoft.com> Date: Thu, 21 Oct 2004 15:53:41 +0200 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 In your previous mail you wrote: In section 3.2, you say that: "It is not required to configure security policies per interface in order to protect return routability signaling messages." => IMHO the basic issue is IKEv2 makes no sense outside the RFC 2401bis (currently draft-ietf-ipsec-rfc2401bis-03.txt but perhaps it will be updated 5 seconds after I send this message :-)... Francis.Dupont@enst-bretagne.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Oct 21 14:21:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02087 for ; Thu, 21 Oct 2004 14:21:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKhll-0002IT-1a for mip6-web-archive@ietf.org; Thu, 21 Oct 2004 14:34:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKhLX-0000tM-NE; Thu, 21 Oct 2004 14:07:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKh50-0000XJ-MG for mip6@megatron.ietf.org; Thu, 21 Oct 2004 13:50:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28753 for ; Thu, 21 Oct 2004 13:50:24 -0400 (EDT) From: Basavaraj.Patil@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKhHc-0001Mj-Dn for mip6@ietf.org; Thu, 21 Oct 2004 14:03:31 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9LHnEe02026; Thu, 21 Oct 2004 20:49:14 +0300 (EET DST) X-Scanned: Thu, 21 Oct 2004 20:49:09 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i9LHn9b1011553; Thu, 21 Oct 2004 20:49:09 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00PkV7hu; Thu, 21 Oct 2004 20:49:09 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9LHn8S28192; Thu, 21 Oct 2004 20:49:08 +0300 (EET DST) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 21 Oct 2004 12:48:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Oct 2004 12:48:31 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF4403B1C009@daebe007.americas.nokia.com> Thread-Topic: Next steps for I-D: draft-ietf-mip6-auth-protocol Thread-Index: AcS3li3gJBysPydHT7eU8n9xf34LfQ== To: X-OriginalArrivalTime: 21 Oct 2004 17:48:33.0421 (UTC) FILETIME=[2EF82BD0:01C4B796] X-Spam-Score: 0.3 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable Cc: alpesh@cisco.com Subject: [Mip6] Next steps for I-D: draft-ietf-mip6-auth-protocol X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable Next steps for I-D: draft-ietf-mip6-auth-protocol 1. Merge the NAI Option for MIP6 (specified in I-D: draft-ietf-mip6-nai-option) with the Auth protocol draft.=20 =20 2. There were several people who suggested during the consensus call that they would like to see some changes to the current proposal. Please send the changes that you would like to see to the I-D by raising an issue. The issue list for MIP6 is at: http://www.mip4.org/issues/tracker/mip6/ 3. We will issue a Working group last call as soon as the next revision of the I-D is published. -Basavaraj =20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Oct 21 14:27:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02633 for ; Thu, 21 Oct 2004 14:27:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKhrM-0002SD-Tr for mip6-web-archive@ietf.org; Thu, 21 Oct 2004 14:40:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKhM9-0001Qr-Sf; Thu, 21 Oct 2004 14:08:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKhCf-0004lW-U0 for mip6@megatron.ietf.org; Thu, 21 Oct 2004 13:58:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29318 for ; Thu, 21 Oct 2004 13:58:19 -0400 (EDT) From: Basavaraj.Patil@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKhPJ-0001XC-9Q for mip6@ietf.org; Thu, 21 Oct 2004 14:11:26 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9LHwGo21575 for ; Thu, 21 Oct 2004 20:58:16 +0300 (EET DST) X-Scanned: Thu, 21 Oct 2004 20:58:02 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i9LHw2d7007797 for ; Thu, 21 Oct 2004 20:58:02 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00GAm0Ew; Thu, 21 Oct 2004 20:58:01 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9LHw0S02929 for ; Thu, 21 Oct 2004 20:58:00 +0300 (EET DST) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 21 Oct 2004 12:57:51 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Oct 2004 12:57:50 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF4403B1C00A@daebe007.americas.nokia.com> Thread-Topic: Requests for time on agenda at IETF61 meeting Thread-Index: AcS3l3q1hNuyjMjuR92bg08E5gAyEw== To: X-OriginalArrivalTime: 21 Oct 2004 17:57:52.0124 (UTC) FILETIME=[7BFB7BC0:01C4B797] X-Spam-Score: 0.3 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable Subject: [Mip6] Requests for time on agenda at IETF61 meeting X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: quoted-printable Requests received so far: # Requester I-D Time -- --------- 1 Giaretta Gerardo draft-giaretta-mip6-authorization-eap-02 15 draft-giaretta-mip6-amsk-00.txt=20 2 Junghoon Jee draft-jee-mip6-bootstrap-pana-00.txt 15 3 Francis Dupont draft-dupont-mipv6-cn-ipsec-01.txt 5 draft-dupont-mipv6-cn-ipsec-01.txt 5 4 Vijay Devarapalli draft-ietf-mip6-ikev2-ipsec-00.txt 20 5 Alper Yegin draft-yegin-mip6-aaa-fwk-00.txt 10 6 Yoshihiro Ohba draft-ohba-mip6-boot-arch-dhcp-00.txt 15 Please let me know if I have missed any requests. -Basavaraj _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Oct 21 14:39:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04364 for ; Thu, 21 Oct 2004 14:39:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKi3Y-0002vO-QK for mip6-web-archive@ietf.org; Thu, 21 Oct 2004 14:53:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKhkQ-0003zp-Kl; Thu, 21 Oct 2004 14:33:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKhT1-0004XK-63 for mip6@megatron.ietf.org; Thu, 21 Oct 2004 14:15:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01318 for ; Thu, 21 Oct 2004 14:15:12 -0400 (EDT) From: Basavaraj.Patil@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKhfe-000237-Cp for mip6@ietf.org; Thu, 21 Oct 2004 14:28:19 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9LIF5o14714; Thu, 21 Oct 2004 21:15:05 +0300 (EET DST) X-Scanned: Thu, 21 Oct 2004 21:14:04 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i9LIE4Kf012933; Thu, 21 Oct 2004 21:14:04 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 000xeytJ; Thu, 21 Oct 2004 21:14:02 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9LIDua06490; Thu, 21 Oct 2004 21:13:56 +0300 (EET DST) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 21 Oct 2004 13:13:39 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Oct 2004 13:13:37 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF4403B1C00B@daebe007.americas.nokia.com> Thread-Topic: Please progress I-D: draft-ietf-mip6-mipext-advapi Thread-Index: AcS3ma+r2WLgdSXZToOek4v0E17gSg== To: , X-OriginalArrivalTime: 21 Oct 2004 18:13:39.0348 (UTC) FILETIME=[B0926540:01C4B799] X-Spam-Score: 0.3 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org Subject: [Mip6] Please progress I-D: draft-ietf-mip6-mipext-advapi X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: quoted-printable Hello, The MIP6 WG I-D "Extension to Sockets API for Mobile IPv6",=20 draft-ietf-mip6-mipext-advapi-03.txt has completed working group last call. All issues have been closed and the I-D being submitted for IESG consideration is the revised one that incorporates all the changes made as a result of the WG LC. We would like the document to be reviewed by the IESG and progressed for publication as Informational RFC. URL to I-D: http://ietf.org/internet-drafts/draft-ietf-mip6-mipext-advapi-03.txt 1) Have the chairs personally reviewed this version of the ID and do they believe this ID is sufficiently baked to forward to the IESG for publication?=20 Yes 2) Has the document had adequate review from both key WG members and key non-WG members? Do you have any concerns about the depth or breadth of the reviews that have been performed? The I-D has been reviewed by several implementers as well as people outside the WG. This I-D has been also discussed in the IPv6 WG and the WG LC was notified to the IPv6 WG as well.=20 We (chairs) do not have concerns about the depth and breadth of the reviews performed on this I-D. 3) Do you have concerns that the document needs more review from a particular (broader) perspective (e.g., security, operational complexity, someone familiar with AAA, etc.)?=20 No. The IPv6 WG is the most relevant other WG for this I-D and that WG has been kept in the loop. =20 4) Do you have any specific concerns/issues with this document that you believe the ADs and/or IESG should be aware of? For example, perhaps you are uncomfortable with certain parts of the document, or whether there really is a need for it, etc., but at the same time these issues have been discussed in the WG and the WG has indicated it wishes to advance the document anyway. No. The I-D is of high quality. =20 5) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is strong consensus on the need for an API within the WG. There is no dissent on the I-D being progressed. 6) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize what are they upset about. No. =20 7) Have the chairs verified that the document adheres to _all_ of the ID nits? (see http://www.ietf.org/ID-nits.html). Yes. =20 8) Does the document a) split references into normative/informative, and b) are there normative references to IDs, where the IDs are not also ready for advancement or are otherwise in an unclear state? (Note: the RFC editor will not publish an RFC with normative references to IDs, it will delay publication until all such IDs are also ready for publication as RFCs.) The document does split the references into normative/informative sections. There are no I-Ds in the normative section. 9) For Standards Track and BCP documents, the IESG approval announcement includes a writeup section with the following sections: - Technical Summary - Working Group Summary - Protocol Quality The I-D is being proposed to be published as an Informational RFC. -Basavaraj _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Oct 21 14:58:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06098 for ; Thu, 21 Oct 2004 14:58:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKiLp-0003RG-Ry for mip6-web-archive@ietf.org; Thu, 21 Oct 2004 15:11:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKhmv-0005dV-T3; Thu, 21 Oct 2004 14:35:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKhjP-0003Nr-64 for mip6@megatron.ietf.org; Thu, 21 Oct 2004 14:32:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03133 for ; Thu, 21 Oct 2004 14:32:09 -0400 (EDT) From: Basavaraj.Patil@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKhw3-0002bG-1l for mip6@ietf.org; Thu, 21 Oct 2004 14:45:16 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9LIVue04658; Thu, 21 Oct 2004 21:31:57 +0300 (EET DST) X-Scanned: Thu, 21 Oct 2004 21:31:00 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i9LIV0GL014797; Thu, 21 Oct 2004 21:31:00 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 002qUtKO; Thu, 21 Oct 2004 21:30:59 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9LIUwS25867; Thu, 21 Oct 2004 21:30:58 +0300 (EET DST) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 21 Oct 2004 13:30:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Oct 2004 13:30:06 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF4403B1C00D@daebe007.americas.nokia.com> Thread-Topic: Please progress I-D: draft-ietf-mip6-ro-sec-02 Thread-Index: AcS3m/yL81ffCLlWTBCt4RPQin3qdQ== To: , X-OriginalArrivalTime: 21 Oct 2004 18:30:08.0084 (UTC) FILETIME=[FDE78940:01C4B79B] X-Spam-Score: 0.3 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org Subject: [Mip6] Please progress I-D: draft-ietf-mip6-ro-sec-02 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: quoted-printable Hello, The MIP6 WG I-D "Mobile IP version 6 Route Optimization Security Design Background", =20 draft-ietf-mip6-ro-sec-02 has completed working group last call. All issues have been closed and the I-D being submitted for IESG consideration is the revised one that incorporates all the changes made as a result of the WG LC. We would like the document to be reviewed by the IESG and progressed for publication as Informational RFC. URL to I-D: http://ietf.org/internet-drafts/draft-ietf-mip6-ro-sec-02.txt 1) Have the chairs personally reviewed this version of the ID and do they believe this ID is sufficiently baked to forward to the IESG for publication?=20 Yes 2) Has the document had adequate review from both key WG members and key non-WG members? Do you have any concerns about the depth or breadth of the reviews that have been performed? The I-D has been reviewed by a sufficient number of people. The I-D provides the background information on the security design of the RO protocol for MIPv6. The WG had a design team in 2001/2 that discussed various types of threats and issues that went into the design of RO. This discussion and design information is being published in this I-D.=20 We (chairs) do not have concerns about the depth and breadth of the reviews performed on this I-D. Issues raised during last call and their resolutions are available at: http://www.mip4.org/issues/tracker/mip6/ 3) Do you have concerns that the document needs more review from a particular (broader) perspective (e.g., security, operational complexity, someone familiar with AAA, etc.)?=20 No.=20 The MIP6 RO mechanism is already incorporated in RFC 3775. The information contained in this I-D are details of discussions and design choices that went into the currently specified RO mechanism.=20 =20 4) Do you have any specific concerns/issues with this document that you believe the ADs and/or IESG should be aware of? For example, perhaps you are uncomfortable with certain parts of the document, or whether there really is a need for it, etc., but at the same time these issues have been discussed in the WG and the WG has indicated it wishes to advance the document anyway. No.=20 =20 5) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The RO design background is useful material for MIP6 implementers and people who would like to understand the logic and reasoning that went into it. It also acts as good information for people developing alternate RO mechanisms or optimizations to RO. 6) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize what are they upset about. No. =20 7) Have the chairs verified that the document adheres to _all_ of the ID nits? (see http://www.ietf.org/ID-nits.html). Yes. =20 8) Does the document a) split references into normative/informative, and b) are there normative references to IDs, where the IDs are not also ready for advancement or are otherwise in an unclear state? (Note: the RFC editor will not publish an RFC with normative references to IDs, it will delay publication until all such IDs are also ready for publication as RFCs.) The document only has Informative references. 9) For Standards Track and BCP documents, the IESG approval announcement includes a writeup section with the following sections: - Technical Summary - Working Group Summary - Protocol Quality The I-D is being proposed to be published as an Informational RFC. -Basavaraj _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Oct 21 15:17:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08880 for ; Thu, 21 Oct 2004 15:17:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKieI-0003x0-0X for mip6-web-archive@ietf.org; Thu, 21 Oct 2004 15:30:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKiCI-0005tD-DA; Thu, 21 Oct 2004 15:02:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKi3U-0006jE-Jq for mip6@megatron.ietf.org; Thu, 21 Oct 2004 14:52:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05350 for ; Thu, 21 Oct 2004 14:52:54 -0400 (EDT) Received: from av1-2-sn1.fre.skanova.net ([81.228.11.108]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKiFw-0003Dg-KL for mip6@ietf.org; Thu, 21 Oct 2004 15:05:58 -0400 Received: by av1-2-sn1.fre.skanova.net (Postfix, from userid 502) id 6D7B837F42; Thu, 21 Oct 2004 20:52:09 +0200 (CEST) Received: from smtp3-1-sn1.fre.skanova.net (smtp3-1-sn1.fre.skanova.net [81.228.11.163]) by av1-2-sn1.fre.skanova.net (Postfix) with ESMTP id 5EF4537E51 for ; Thu, 21 Oct 2004 20:52:09 +0200 (CEST) Received: from shiraz.levkowetz.com (h195n1fls311o871.telia.com [213.64.174.195]) by smtp3-1-sn1.fre.skanova.net (Postfix) with ESMTP id 4B6B237E56 for ; Thu, 21 Oct 2004 20:52:09 +0200 (CEST) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=h195n1fls311o871.telia.com) by shiraz.levkowetz.com with esmtp (Exim 4.34) id 1CKi2i-0007qK-Op for mip6@ietf.org; Thu, 21 Oct 2004 20:52:09 +0200 To: mip6@ietf.org From: admin Date: Thu, 21 Oct 2004 18:52:07 +0000 MIME-Version: 1.0 Message-Id: <1098384727.28.0.319617979166.issue9@mip4.org> X-Roundup-Name: Mip6 issue tracker X-Roundup-Loop: hello X-Exim-Helo-Check-Failed: Verification failed for HELO h195n1fls311o871.telia.com X-SA-Exim-Connect-IP: 192.168.3.14 X-SA-Exim-Mail-From: roundup-admin@mip4.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on shiraz.levkowetz.com X-Spam-Status: No, hits=-2.9 required=3.0 tests=BAYES_00, X_HELO_CHECK_FAILED autolearn=no version=2.64 X-SA-Exim-Version: 4.1 (built Tue, 17 Aug 2004 11:06:07 +0200) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable Subject: [Mip6] [issue9] Merge MIP6 NAI into the Auth I-D X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mip6 issue tracker List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: quoted-printable New submission from admin : Please incorporate the MIP6 NAI into the Auth I-D. There is no reason for t= he NAI to be specified as a separate I-D. -BPa ---------- category: Editorial draft: draft-ietf-mip6-auth-protocol messages: 42 nosy: admin priority: Must fix status: Pending title: Merge MIP6 NAI into the Auth I-D ________________________________________________ Mip6 issue tracker ________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Oct 21 15:28:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10501 for ; Thu, 21 Oct 2004 15:28:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKioX-0004E7-33 for mip6-web-archive@ietf.org; Thu, 21 Oct 2004 15:41:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKiWB-0007CV-Pc; Thu, 21 Oct 2004 15:22:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKiSN-0003l7-3r for mip6@megatron.ietf.org; Thu, 21 Oct 2004 15:18:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08993 for ; Thu, 21 Oct 2004 15:18:37 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKif1-0003xN-TM for mip6@ietf.org; Thu, 21 Oct 2004 15:31:45 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i9LIoin11293; Thu, 21 Oct 2004 11:50:44 -0700 X-mProtect: <200410211850> Nokia Silicon Valley Messaging Protection Received: from mvdhcp141115.americas.nokia.com (172.18.141.115, claiming to be "[172.18.141.115]") by darkstar.iprg.nokia.com smtpdbvtjLc; Thu, 21 Oct 2004 11:50:42 PDT Message-ID: <41780AA4.4010405@iprg.nokia.com> Date: Thu, 21 Oct 2004 12:14:44 -0700 From: Charlie P Organization: NOKIA User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com Subject: Re: [Mip6] Next steps for I-D: draft-ietf-mip6-auth-protocol References: <697DAA22C5004B4596E033803A7CEF4403B1C009@daebe007.americas.nokia.com> In-Reply-To: <697DAA22C5004B4596E033803A7CEF4403B1C009@daebe007.americas.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, alpesh@cisco.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Hello Basvaraj, I am in favor of getting things done as quickly as possible, but I hope that we do not have to rush to completion so soon on this. What are the driving factors for expediting the standardization of the protocol? For instance, I strongly disagree that authentication should mandate including the NAI. I also wonder why there is any mandate to agree with anything in rfc3012bis, since that is a protocol specification concerned with IPv4. I think there could be a number of other issues about which discussion is needed. Regards, Charlie P. Basavaraj.Patil@nokia.com wrote: >Next steps for I-D: draft-ietf-mip6-auth-protocol > >1. Merge the NAI Option for MIP6 (specified in I-D: > draft-ietf-mip6-nai-option) with the Auth protocol draft. > >2. There were several people who suggested during the consensus call > that they would like to see some changes to the current > proposal. Please send the changes that you would like to see to the > I-D by raising an issue. The issue list for MIP6 is at: > http://www.mip4.org/issues/tracker/mip6/ > >3. We will issue a Working group last call as soon as the next > revision of the I-D is published. > >-Basavaraj > > >_______________________________________________ >Mip6 mailing list >Mip6@ietf.org >https://www1.ietf.org/mailman/listinfo/mip6 > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Oct 21 15:52:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13272 for ; Thu, 21 Oct 2004 15:52:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKjBk-0004ty-6Y for mip6-web-archive@ietf.org; Thu, 21 Oct 2004 16:05:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKits-0000GE-I8; Thu, 21 Oct 2004 15:47:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKifR-0005vk-LL for mip6@megatron.ietf.org; Thu, 21 Oct 2004 15:32:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10742 for ; Thu, 21 Oct 2004 15:32:07 -0400 (EDT) From: Basavaraj.Patil@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKis6-0004HZ-JG for mip6@ietf.org; Thu, 21 Oct 2004 15:45:16 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9LJW4o21883; Thu, 21 Oct 2004 22:32:04 +0300 (EET DST) X-Scanned: Thu, 21 Oct 2004 22:31:39 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i9LJVdih004422; Thu, 21 Oct 2004 22:31:39 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00DwXlMT; Thu, 21 Oct 2004 22:31:38 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9LJVaS05434; Thu, 21 Oct 2004 22:31:36 +0300 (EET DST) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 21 Oct 2004 14:30:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Next steps for I-D: draft-ietf-mip6-auth-protocol Date: Thu, 21 Oct 2004 14:30:53 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF4403B1C018@daebe007.americas.nokia.com> Thread-Topic: [Mip6] Next steps for I-D: draft-ietf-mip6-auth-protocol Thread-Index: AcS3ou7QDMugz/5ESS+S+GegvsWo5wAAYTnw To: X-OriginalArrivalTime: 21 Oct 2004 19:30:56.0974 (UTC) FILETIME=[7CCFF6E0:01C4B7A4] X-Spam-Score: 0.3 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org, alpesh@cisco.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: quoted-printable Hi Charlie, >Hello Basvaraj, > >I am in favor of getting things done as quickly as possible, >but I hope that we do not have to rush to completion so >soon on this. What are the driving factors for expediting >the standardization of the protocol? Well, one of the key driving factors for expediting the work on this I-D is because of the fact that 3GPP2 would like to incorporate MIP6 into the TIA-835 specification (Rev D). This would be a major step forward in terms of MIP6 deployment. The charter of the WG is to take on tasks that aid in deployment. This is one of those tasks. >For instance, I strongly disagree that authentication >should mandate including the NAI. =20 If you are going to use the AAA infra as a means for authenticating a MIP6 user, and the identity used/configured in the AAA-Home for the user is an NAI, it makes sense to include the NAI as part of the auth-protocol.=20 >I also wonder >why there is any mandate to agree with anything >in rfc3012bis, since that is a protocol specification >concerned with IPv4. ???? I dont understand your concern here Charlie. >I think there could be a number of other issues >about which discussion is needed. Sure. Please feel free to raise the issues with the I-D. The I-D is a WG document and we will specify the mechanism based on WG consensus. >Regards, >Charlie P. -Basavaraj _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Oct 21 16:47:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23165 for ; Thu, 21 Oct 2004 16:47:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKk31-0007vg-2R for mip6-web-archive@ietf.org; Thu, 21 Oct 2004 17:00:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKiut-00033h-3A; Thu, 21 Oct 2004 15:48:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKilf-0002Oa-Mr for mip6@megatron.ietf.org; Thu, 21 Oct 2004 15:38:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11316 for ; Thu, 21 Oct 2004 15:38:33 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKiyK-0004Nm-R6 for mip6@ietf.org; Thu, 21 Oct 2004 15:51:42 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 21 Oct 2004 12:46:00 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i9LJbhYL009737; Thu, 21 Oct 2004 12:37:46 -0700 (PDT) Received: from cisco.com (dhcp-128-107-176-152.cisco.com [128.107.176.152]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id AYG89483; Thu, 21 Oct 2004 12:39:07 -0700 (PDT) Message-ID: <41781014.9060904@cisco.com> Date: Thu, 21 Oct 2004 12:37:56 -0700 From: Alpesh User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Charlie P Subject: Re: [Mip6] Next steps for I-D: draft-ietf-mip6-auth-protocol References: <697DAA22C5004B4596E033803A7CEF4403B1C009@daebe007.americas.nokia.com> <41780AA4.4010405@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, Basavaraj.Patil@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Charlie - I just did a grep on doc and we don't have a MUST that NAI and MHAE/MN-AAA AE must go together. NAI "should" be used with the auth. option (not must). Beyond that, can you list the issues? I can add them up on the issue tracker (or maybe you can too) and we can track it there? -a Charlie P wrote: > > Hello Basvaraj, > > I am in favor of getting things done as quickly as possible, > but I hope that we do not have to rush to completion so > soon on this. What are the driving factors for expediting > the standardization of the protocol? > > For instance, I strongly disagree that authentication > should mandate including the NAI. I also wonder > why there is any mandate to agree with anything > in rfc3012bis, since that is a protocol specification > concerned with IPv4. > > I think there could be a number of other issues > about which discussion is needed. > > Regards, > Charlie P. > > > > Basavaraj.Patil@nokia.com wrote: > >> Next steps for I-D: draft-ietf-mip6-auth-protocol >> >> 1. Merge the NAI Option for MIP6 (specified in I-D: >> draft-ietf-mip6-nai-option) with the Auth protocol draft. 2. >> There were several people who suggested during the consensus call >> that they would like to see some changes to the current >> proposal. Please send the changes that you would like to see to the >> I-D by raising an issue. The issue list for MIP6 is at: >> http://www.mip4.org/issues/tracker/mip6/ >> >> 3. We will issue a Working group last call as soon as the next >> revision of the I-D is published. >> >> -Basavaraj >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 >> >> > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Oct 21 18:37:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17808 for ; Thu, 21 Oct 2004 18:37:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKllw-0006Xu-7R for mip6-web-archive@ietf.org; Thu, 21 Oct 2004 18:51:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKl4r-0004DR-7c; Thu, 21 Oct 2004 18:06:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKiwV-0004IX-W6 for mip6@megatron.ietf.org; Thu, 21 Oct 2004 15:49:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12961 for ; Thu, 21 Oct 2004 15:49:45 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKj9B-0004qJ-7B for mip6@ietf.org; Thu, 21 Oct 2004 16:02:54 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i9LJLsD16007; Thu, 21 Oct 2004 12:21:54 -0700 X-mProtect: <200410211921> Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdpwB2gs; Thu, 21 Oct 2004 12:21:53 PDT Message-ID: <4178131D.3BA5013@iprg.nokia.com> Date: Thu, 21 Oct 2004 12:50:53 -0700 From: "Charles E.Perkins" 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: Basavaraj.Patil@nokia.com Subject: Re: [Mip6] Next steps for I-D: draft-ietf-mip6-auth-protocol References: <697DAA22C5004B4596E033803A7CEF4403B1C018@daebe007.americas.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Hello Basvaraj, Basavaraj.Patil@nokia.com wrote: > Well, one of the key driving factors for expediting the work on this > I-D is because of the fact that 3GPP2 would like to incorporate MIP6 > into the TIA-835 specification (Rev D). This would be a major step > forward in terms of MIP6 deployment. The charter of the WG is to take > on tasks that aid in deployment. This is one of those tasks. No problem with that. What is their timeline? >> For instance, I strongly disagree that authentication >> should mandate including the NAI. > > If you are going to use the AAA infra as a means for authenticating a > MIP6 user, and the identity used/configured in the AAA-Home for the > user is an NAI, it makes sense to include the NAI as part of the > auth-protocol. Of course, it is not insane to include the NAI. It is useful in many circumstances. That means "MAY", not "SHOULD". It is equally sensible to run the protocol without NAI, just not with pre-existing equipment that expects otherwise. >> I also wonder >> why there is any mandate to agree with anything >> in rfc3012bis, since that is a protocol specification >> concerned with IPv4. > ???? I dont understand your concern here Charlie. The draft says: The MN MUST use either CHAP_SPI or HMAC_CHAP_SPI as defined in [3012bis] to indicate CHAP style authentication. I don't think it is a good idea to make the specification this way, unless it is already agreed that the numbering space would be kept identical forever. Otherwise, there will have to be two numbering spaces for the SPI field, and in that case the above quoted specification would not be a good idea it seems to me. But this is a relatively minor point, and the original request was to delay the scheduled WG last call in order that I might have time to fully understand the draft. I don't mind adding issues to the issue tracker, but my point is that it's premature for WG last call. Regards, Charlie P. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Oct 21 21:13:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20106 for ; Thu, 21 Oct 2004 21:13:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKoCZ-0008Q5-B0 for mip6-web-archive@ietf.org; Thu, 21 Oct 2004 21:26:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKlJ7-00014v-KY; Thu, 21 Oct 2004 18:21:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKjmH-0001jo-7E for mip6@megatron.ietf.org; Thu, 21 Oct 2004 16:43:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22665 for ; Thu, 21 Oct 2004 16:43:14 -0400 (EDT) From: Basavaraj.Patil@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKjyx-0007ks-JD for mip6@ietf.org; Thu, 21 Oct 2004 16:56:24 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9LKhDo18147 for ; Thu, 21 Oct 2004 23:43:14 +0300 (EET DST) X-Scanned: Thu, 21 Oct 2004 23:43:06 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i9LKh6Cs008378 for ; Thu, 21 Oct 2004 23:43:06 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00gIg2sW; Thu, 21 Oct 2004 23:43:05 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9LKgwa05857 for ; Thu, 21 Oct 2004 23:42:59 +0300 (EET DST) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 21 Oct 2004 15:42:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Next steps for I-D: draft-ietf-mip6-auth-protocol Date: Thu, 21 Oct 2004 15:42:39 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF4403B1C01A@daebe007.americas.nokia.com> Thread-Topic: [Mip6] Next steps for I-D: draft-ietf-mip6-auth-protocol Thread-Index: AcS3pyNPC4wMBTyzTVqAaIZE0ATbFwABvqaQ To: X-OriginalArrivalTime: 21 Oct 2004 20:42:40.0146 (UTC) FILETIME=[81B3E720:01C4B7AE] X-Spam-Score: 0.3 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable >=20 > The draft says: >=20 > The MN MUST use either CHAP_SPI or HMAC_CHAP_SPI as defined in > [3012bis] to indicate CHAP style authentication. >=20 > I don't think it is a good idea to make the specification > this way, unless it is already agreed that the numbering > space would be kept identical forever. Otherwise, there > will have to be two numbering spaces for the SPI field, > and in that case the above quoted specification would not > be a good idea it seems to me. >=20 > But this is a relatively minor point, and the original > request was to delay the scheduled WG last call in order > that I might have time to fully understand the draft. >=20 > I don't mind adding issues to the issue tracker, but > my point is that it's premature for WG last call. The I-D is relatively small and simple. I believe it is possible to get any issues (such as the one above) and others resolved fairly quickly. The draft has been discussed at two IETF meetings now. So I am of the opinion that it is ready to go to WG LC in the next few weeks. >=20 > Regards, > Charlie P. -BPa _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Oct 21 21:14:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20303 for ; Thu, 21 Oct 2004 21:14:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKoDg-0008Sq-0h for mip6-web-archive@ietf.org; Thu, 21 Oct 2004 21:27:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKlN3-0005JU-13; Thu, 21 Oct 2004 18:25:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKjsH-0004Ps-RD for mip6@megatron.ietf.org; Thu, 21 Oct 2004 16:49:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23465 for ; Thu, 21 Oct 2004 16:49:27 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKk4x-0007zi-Eq for mip6@ietf.org; Thu, 21 Oct 2004 17:02:36 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i9LKLbl09273 for ; Thu, 21 Oct 2004 13:21:37 -0700 X-mProtect: <200410212021> Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdWKPZvg; Thu, 21 Oct 2004 13:21:36 PDT Message-ID: <4178211C.C2A173E7@iprg.nokia.com> Date: Thu, 21 Oct 2004 13:50:36 -0700 From: "Charles E.Perkins" 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: Mobile IPv6 Mailing List Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit Subject: [Mip6] New draft revision for preconfigured keys for authenticating Binding Updates X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit Hello folks, I am expecting to finish today a new revision for "Preconfigured Binding Management Key Data for Mobile IPv6" namely, draft-ietf-mip6-precfgKbm-01.txt During the last IETF, there was discussion about whether or not to include a Care-of Address test in this draft, so that a correspondent node could use the basic idea of the draft while still having equal confidence that the mobile node is legitimately addressable as it claims. The consensus as I recall is that this "preconfigured" draft should NOT take on the additional specification for the Care-of Test that would have been needed. That's good in a way, because it keeps this draft simpler. On the other hand, I would very much like to see that there is as much commonality as possible between the various approaches, mainly so that the code can be kept as simple as possible and to reduce the number of hiding places for bugs. One way to promote this code simplicity is by re-using the material in the base draft as much as possible. With that in mind, I am proposing in the new draft that the computation for Kbm be made in the same way as in the base Mobile IPv6 specification, but with preconfigured data used in the formula. This is a real improvement as well as, in some ways, a simplification. This means that, instead of preconfiguring the key itself (Kbm), one would instead preconfigure the Home Keygen Token (Hkt) and the Care-of Keygen Token (Ckt), as well as the nonce values used in the computation. This allows for quite a few bits of randomness for the data used in the computation. Then, Kbm is computed exactly as specfied in the base draft, using the preconfigured Keygen Tokens. This has another great advantage, which is that the Kbm used changes at every new care-of address. This makes the replay protection much improved than if the care-of address does not affect the value of Kbm. The replay protection is, as computed in the draft, already sufficient for many cases. But having the replay also depend on specific care-of addresses in use will just be that much better. Also, I expect this will make it just a little more difficult to gather enough data to crack the preconfigured secret data. I believe this formulation maintains the ability to create a stronger security association than afforded by return routability, albeit only applicable in a restricted set of scenarios as documented in the draft. Comments on this will be welcome; please excuse the short amount of time before the submission deadline. If need be, I will be happy to revise the draft just after the blackout period ends again after the IETF. Regards, Charlie P. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Oct 21 21:20:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21393 for ; Thu, 21 Oct 2004 21:20:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKoIq-0000Dn-BN for mip6-web-archive@ietf.org; Thu, 21 Oct 2004 21:33:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKlUC-0004TH-W0; Thu, 21 Oct 2004 18:32:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKkLZ-000847-4s for mip6@megatron.ietf.org; Thu, 21 Oct 2004 17:19:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00492 for ; Thu, 21 Oct 2004 17:19:42 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKkYG-0001lg-0r for mip6@ietf.org; Thu, 21 Oct 2004 17:32:52 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i9LKpr432159; Thu, 21 Oct 2004 13:51:53 -0700 X-mProtect: <200410212051> Nokia Silicon Valley Messaging Protection Received: from mvdhcp14195.americas.nokia.com (172.18.141.95, claiming to be "[172.18.141.95]") by darkstar.iprg.nokia.com smtpdvNiX3L; Thu, 21 Oct 2004 13:51:52 PDT Message-ID: <417827C4.9000607@iprg.nokia.com> Date: Thu, 21 Oct 2004 14:19:00 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alpesh Subject: Re: [Mip6] Next steps for I-D: draft-ietf-mip6-auth-protocol References: <697DAA22C5004B4596E033803A7CEF4403B1C009@daebe007.americas.nokia.com> <41780AA4.4010405@iprg.nokia.com> <41781014.9060904@cisco.com> In-Reply-To: <41781014.9060904@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, Charlie P , Basavaraj.Patil@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: 7bit Alpesh wrote: > Charlie - > > I just did a grep on doc and we don't have a MUST that NAI and > MHAE/MN-AAA AE > must go together. NAI "should" be used with the auth. option (not must). "should" is not defined in RFC 2119. :) when used in an RFC, the lowercase should is generally considered the equivalent of MUST. alteast thats my understanding. I guess you wanted to say NAI option SHOULD be used with auth option (?). Vijay > > Beyond that, can you list the issues? I can add them up on the issue > tracker > (or maybe you can too) and we can track it there? > > -a > > Charlie P wrote: > >> >> Hello Basvaraj, >> >> I am in favor of getting things done as quickly as possible, >> but I hope that we do not have to rush to completion so >> soon on this. What are the driving factors for expediting >> the standardization of the protocol? >> >> For instance, I strongly disagree that authentication >> should mandate including the NAI. I also wonder >> why there is any mandate to agree with anything >> in rfc3012bis, since that is a protocol specification >> concerned with IPv4. >> >> I think there could be a number of other issues >> about which discussion is needed. >> >> Regards, >> Charlie P. >> >> >> >> Basavaraj.Patil@nokia.com wrote: >> >>> Next steps for I-D: draft-ietf-mip6-auth-protocol >>> >>> 1. Merge the NAI Option for MIP6 (specified in I-D: >>> draft-ietf-mip6-nai-option) with the Auth protocol draft. 2. >>> There were several people who suggested during the consensus call >>> that they would like to see some changes to the current >>> proposal. Please send the changes that you would like to see to the >>> I-D by raising an issue. The issue list for MIP6 is at: >>> http://www.mip4.org/issues/tracker/mip6/ >>> >>> 3. We will issue a Working group last call as soon as the next >>> revision of the I-D is published. >>> >>> -Basavaraj >>> _______________________________________________ >>> Mip6 mailing list >>> Mip6@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mip6 >>> >>> >> >> > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Oct 21 21:33:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25102 for ; Thu, 21 Oct 2004 21:33:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKoVh-0001Cu-3X for mip6-web-archive@ietf.org; Thu, 21 Oct 2004 21:46:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKnLK-0000qG-EJ; Thu, 21 Oct 2004 20:31:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKl6x-0005c2-7l for mip6@megatron.ietf.org; Thu, 21 Oct 2004 18:08:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11283 for ; Thu, 21 Oct 2004 18:08:40 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKlJd-0004mt-CA for mip6@ietf.org; Thu, 21 Oct 2004 18:21:50 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 21 Oct 2004 15:18:34 -0700 X-BrightmailFiltered: true Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i9LM876u021456; Thu, 21 Oct 2004 15:08:08 -0700 (PDT) Received: from cisco.com (dhcp-128-107-163-246.cisco.com [128.107.163.246]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id AYH04889; Thu, 21 Oct 2004 15:09:15 -0700 (PDT) Message-ID: <41783345.4050507@cisco.com> Date: Thu, 21 Oct 2004 15:08:05 -0700 From: Alpesh User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [Mip6] Next steps for I-D: draft-ietf-mip6-auth-protocol References: <697DAA22C5004B4596E033803A7CEF4403B1C009@daebe007.americas.nokia.com> <41780AA4.4010405@iprg.nokia.com> <41781014.9060904@cisco.com> <417827C4.9000607@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, Charlie P , Basavaraj.Patil@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: 7bit cut and paste :) The MN SHOULD use NAI option to enable the Home Agent to make use of available AAA infrastructure which requires NAI. This is what I have :) -a Vijay Devarapalli wrote: > Alpesh wrote: > >> Charlie - >> >> I just did a grep on doc and we don't have a MUST that NAI and >> MHAE/MN-AAA AE >> must go together. NAI "should" be used with the auth. option (not must). > > > "should" is not defined in RFC 2119. :) when used in an RFC, > the lowercase should is generally considered the equivalent > of MUST. alteast thats my understanding. > > I guess you wanted to say NAI option SHOULD be used with auth > option (?). > > Vijay > >> >> Beyond that, can you list the issues? I can add them up on the issue >> tracker >> (or maybe you can too) and we can track it there? >> >> -a >> >> Charlie P wrote: >> >>> >>> Hello Basvaraj, >>> >>> I am in favor of getting things done as quickly as possible, >>> but I hope that we do not have to rush to completion so >>> soon on this. What are the driving factors for expediting >>> the standardization of the protocol? >>> >>> For instance, I strongly disagree that authentication >>> should mandate including the NAI. I also wonder >>> why there is any mandate to agree with anything >>> in rfc3012bis, since that is a protocol specification >>> concerned with IPv4. >>> >>> I think there could be a number of other issues >>> about which discussion is needed. >>> >>> Regards, >>> Charlie P. >>> >>> >>> >>> Basavaraj.Patil@nokia.com wrote: >>> >>>> Next steps for I-D: draft-ietf-mip6-auth-protocol >>>> >>>> 1. Merge the NAI Option for MIP6 (specified in I-D: >>>> draft-ietf-mip6-nai-option) with the Auth protocol draft. 2. >>>> There were several people who suggested during the consensus call >>>> that they would like to see some changes to the current >>>> proposal. Please send the changes that you would like to see to the >>>> I-D by raising an issue. The issue list for MIP6 is at: >>>> http://www.mip4.org/issues/tracker/mip6/ >>>> >>>> 3. We will issue a Working group last call as soon as the next >>>> revision of the I-D is published. >>>> >>>> -Basavaraj >>>> _______________________________________________ >>>> Mip6 mailing list >>>> Mip6@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/mip6 >>>> >>>> >>> >>> >> >> >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Oct 21 22:16:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01347 for ; Thu, 21 Oct 2004 22:16:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKpBs-0002oN-VV for mip6-web-archive@ietf.org; Thu, 21 Oct 2004 22:30:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKom6-0003Zl-Pb; Thu, 21 Oct 2004 22:03:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKoLf-0003HV-RP for mip6@megatron.ietf.org; Thu, 21 Oct 2004 21:36:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25813 for ; Thu, 21 Oct 2004 21:36:04 -0400 (EDT) Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKoYO-0001P2-F9 for mip6@ietf.org; Thu, 21 Oct 2004 21:49:16 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 21 Oct 2004 21:35:33 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Next steps for I-D: draft-ietf-mip6-auth-protocol Date: Thu, 21 Oct 2004 21:35:23 -0400 Message-ID: Thread-Topic: [Mip6] Next steps for I-D: draft-ietf-mip6-auth-protocol Thread-Index: AcS31S1ik9BKfJMOQkirF+q/KQdk4QAAhcRg From: "Soliman, Hesham" To: "Vijay Devarapalli" , "Alpesh" X-OriginalArrivalTime: 22 Oct 2004 01:35:33.0039 (UTC) FILETIME=[6BF693F0:01C4B7D7] X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org, Charlie P , Basavaraj.Patil@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: quoted-printable > > Charlie - > >=20 > > I just did a grep on doc and we don't have a MUST that NAI and=20 > > MHAE/MN-AAA AE > > must go together. NAI "should" be used with the auth.=20 > option (not must). >=20 > "should" is not defined in RFC 2119. :) when used in an RFC, > the lowercase should is generally considered the equivalent > of MUST. alteast thats my understanding. =3D> Correct. See 2461, there are no upper case keywords. >=20 > I guess you wanted to say NAI option SHOULD be used with auth > option (?). =3D> I agree with Charlie, SHOULD is too strong. There SHOULD be alternatives like IMSI ...etc Hesham >=20 > Vijay >=20 > >=20 > > Beyond that, can you list the issues? I can add them up on=20 > the issue=20 > > tracker > > (or maybe you can too) and we can track it there? > >=20 > > -a > >=20 > > Charlie P wrote: > >=20 > >> > >> Hello Basvaraj, > >> > >> I am in favor of getting things done as quickly as possible, > >> but I hope that we do not have to rush to completion so > >> soon on this. What are the driving factors for expediting > >> the standardization of the protocol? > >> > >> For instance, I strongly disagree that authentication > >> should mandate including the NAI. I also wonder > >> why there is any mandate to agree with anything > >> in rfc3012bis, since that is a protocol specification > >> concerned with IPv4. > >> > >> I think there could be a number of other issues > >> about which discussion is needed. > >> > >> Regards, > >> Charlie P. > >> > >> > >> > >> Basavaraj.Patil@nokia.com wrote: > >> > >>> Next steps for I-D: draft-ietf-mip6-auth-protocol > >>> > >>> 1. Merge the NAI Option for MIP6 (specified in I-D: > >>> draft-ietf-mip6-nai-option) with the Auth protocol draft. 2.=20 > >>> There were several people who suggested during the consensus call > >>> that they would like to see some changes to the current > >>> proposal. Please send the changes that you would like=20 > to see to the > >>> I-D by raising an issue. The issue list for MIP6 is at: > >>> http://www.mip4.org/issues/tracker/mip6/ > >>> > >>> 3. We will issue a Working group last call as soon as the next > >>> revision of the I-D is published. > >>> > >>> -Basavaraj > >>> _______________________________________________ > >>> Mip6 mailing list > >>> Mip6@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/mip6 > >>> =20 > >>> > >> > >> > >=20 > >=20 > >=20 > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review or distribution by others is = strictly prohibited. If you are not the intended recipient please contact the = sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Oct 22 03:56:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10092 for ; Fri, 22 Oct 2004 03:56:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKuUp-0000Q9-B3 for mip6-web-archive@ietf.org; Fri, 22 Oct 2004 04:10:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKuGT-000356-Oa; Fri, 22 Oct 2004 03:55:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKu6T-0007jn-R8 for mip6@megatron.ietf.org; Fri, 22 Oct 2004 03:44:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09317 for ; Fri, 22 Oct 2004 03:44:47 -0400 (EDT) Received: from ip-10-194-65-202.rev.dyxnet.com ([202.65.194.10] helo=hitachi.cn) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CKuJC-00007o-Ot for mip6@ietf.org; Fri, 22 Oct 2004 03:58:00 -0400 Received: (qmail 8405 invoked by uid 104); 22 Oct 2004 07:44:11 -0000 Received: from hdeng@hitachi.cn by hitachihk1 with network-box scanner-1.10 (received+scanned in 11.277329 secs); 22 Oct 2004 07:44:11 -0000 X-Scanned-By-hitachihk1: Virus scan performed by network-box (www.network-box.com) X-Scanned-By-hitachihk1: Scanner file id is hitachihk110984310405118292 X-Scanned-By-hitachihk1: No known viruses found in message (received+scanned in 11.277329 secs) X-Scanned-By-hitachihk1: Spam-Check-Result: No, hits=-92.4 required=7.0 tests=AWL, USER_IN_WHITELIST autolearn=no version=2.63 X-Spam-Status: No Received: from unknown (HELO europa.hitachi.cn) (202.0.122.180) by ip-11-194-65-202.rev.dyxnet.com with SMTP; 22 Oct 2004 07:43:59 -0000 Received: from HCBJDC2.hitachi-china.com ([170.95.81.2]) by europa.hitachi.cn with Microsoft SMTPSVC(5.0.2195.5329); Fri, 22 Oct 2004 15:43:05 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Date: Fri, 22 Oct 2004 15:42:57 +0800 Message-ID: <834B54D356AA8F46B9B233DD88BEAA381E9523@hcbjdc2> Thread-Topic: Updated I-D: Load Balance for Distributed Home Agents in Mobile IPv6 Thread-Index: AcS4CPwslT34/8ESTVG5fBC1J6Xskw== From: "DENG, HUI -HCHIBJ" To: X-OriginalArrivalTime: 22 Oct 2004 07:43:06.0015 (UTC) FILETIME=[C48FAAF0:01C4B80A] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable Cc: gdommety@cisco.com, zhangr@gsta.com, duanxiaodong@chinamobile.com, Brian.Haley@hp.com, zhangkai98@mails.tsinghua.edu.cn, basavaraj.patil@nokia.com Subject: [Mip6] Updated I-D: Load Balance for Distributed Home Agents in Mobile IPv6 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable Hello, ALL. Here is a updated I-D, Load Balance for Distributed Home Agents in Mobile IPv6. Abstract: =20 This document specifies a dynamic load balance mechanism among multiple home agents by taking into account acceptable number of mobile nodes for each home agent up to now, with the goal of reducing and preventing traffic bottlenecks at the home agent. This mechanism can be used when a home agent is overloaded, wants to achieve better load-balancing with peer home agents, or is going offline for service. URL to I-D: http://www.ietf.org/internet-drafts/draft-deng-mip6-ha-loadbalance-02.tx t Comments are welcome. Hui DENG Senior Researcher Research & Development Center Hitachi (China), Investment Ltd. Beijing Fortune Bldg. 1701, 5 Dong San Huan Bei-Lu Chao Yang District, Beijing 100004, China Tel ; (86) 10-6590-8111 ext(3042) Mob:(86) 13910750201 Fax ; (86) 10-6590-8179 E-mail; hdeng@hitachi.cn _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Oct 22 03:59:42 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10322 for ; Fri, 22 Oct 2004 03:59:42 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKuXf-0000Ti-OC for mip6-web-archive@ietf.org; Fri, 22 Oct 2004 04:12:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKuGU-00035N-PX; Fri, 22 Oct 2004 03:55:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKu6Z-0007jq-Hi for mip6@megatron.ietf.org; Fri, 22 Oct 2004 03:45:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09330 for ; Fri, 22 Oct 2004 03:44:53 -0400 (EDT) Received: from ip-10-194-65-202.rev.dyxnet.com ([202.65.194.10] helo=hitachi.cn) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CKuJK-000081-9a for mip6@ietf.org; Fri, 22 Oct 2004 03:58:07 -0400 Received: (qmail 8531 invoked by uid 104); 22 Oct 2004 07:44:21 -0000 Received: from hdeng@hitachi.cn by hitachihk1 with network-box scanner-1.10 (received+scanned in 9.266492 secs); 22 Oct 2004 07:44:21 -0000 X-Scanned-By-hitachihk1: Virus scan performed by network-box (www.network-box.com) X-Scanned-By-hitachihk1: Scanner file id is hitachihk110984310525118410 X-Scanned-By-hitachihk1: No known viruses found in message (received+scanned in 9.266492 secs) X-Scanned-By-hitachihk1: Spam-Check-Result: No, hits=-92.3 required=7.0 tests=AWL, J_CHICKENPOX_39, USER_IN_WHITELIST autolearn=no version=2.63 X-Spam-Status: No Received: from unknown (HELO europa.hitachi.cn) (202.0.122.180) by ip-11-194-65-202.rev.dyxnet.com with SMTP; 22 Oct 2004 07:44:11 -0000 Received: from HCBJDC2.hitachi-china.com ([170.95.81.2]) by europa.hitachi.cn with Microsoft SMTPSVC(5.0.2195.5329); Fri, 22 Oct 2004 15:43:12 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Date: Fri, 22 Oct 2004 15:43:01 +0800 Message-ID: <834B54D356AA8F46B9B233DD88BEAA381E9524@hcbjdc2> Thread-Topic: New I-D: Bootstrap Control Function mechanism for Mobile IPv6 Bootstrap Thread-Index: AcS4CPwslT34/8ESTVG5fBC1J6Xskw== From: "DENG, HUI -HCHIBJ" To: X-OriginalArrivalTime: 22 Oct 2004 07:43:12.0203 (UTC) FILETIME=[C83FE1B0:01C4B80A] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable Cc: gdommety@cisco.com, xiechf@ctbri.com.cn, basavaraj.patil@nokia.com Subject: [Mip6] New I-D: Bootstrap Control Function mechanism for Mobile IPv6 Bootstrap X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable Hello, ALL. Here is a new I-D, Bootstrap Control Function mechanism for Mobile IPv6 Bootstrap. Abstract: This document specifies a mechanism for Mobile IPv6 bootstrap procedure. By making a extension of MIP6 specification and using IKE to guarantee its security, this mechanism bring into a new component BCF(Bootstrap Control Function) to handle MN's bootstrap procedure between MN and multiple HAs. Two new bootstrap messages Init and Ack have been defined to support bootstrap procedure. URL to I-D: http://www.ietf.org/internet-drafts/draft-deng-mip6-bootstrap-bcf-00.txt Comments are welcome. Hui DENG Senior Researcher Research & Development Center Hitachi (China), Investment Ltd. Beijing Fortune Bldg. 1701, 5 Dong San Huan Bei-Lu Chao Yang District, Beijing 100004, China Tel ; (86) 10-6590-8111 ext(3042) Mob:(86) 13910750201 Fax ; (86) 10-6590-8179 E-mail; hdeng@hitachi.cn _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Oct 22 09:52:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04457 for ; Fri, 22 Oct 2004 09:52:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL02k-0006hF-93 for mip6-web-archive@ietf.org; Fri, 22 Oct 2004 10:05:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKzjN-0006am-H0; Fri, 22 Oct 2004 09:45:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKzfU-0004So-FR for mip6@megatron.ietf.org; Fri, 22 Oct 2004 09:41:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03589 for ; Fri, 22 Oct 2004 09:41:17 -0400 (EDT) Received: from mail-ash.bigfish.com ([206.16.192.253] helo=mail53-ash-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKzsE-0006RU-8m for mip6@ietf.org; Fri, 22 Oct 2004 09:54:33 -0400 Received: from mail53-ash.bigfish.com (localhost.localdomain [127.0.0.1]) by mail53-ash-R.bigfish.com (Postfix) with ESMTP id 5EBC053AF7E; Fri, 22 Oct 2004 13:40:41 +0000 (UCT) X-BigFish: VC Received: by mail53-ash (MessageSwitch) id 1098452441328625_6012; Fri, 22 Oct 2004 13:40:41 +0000 (UCT) Received: from smtpgw6.it.sprintspectrum.com (smtpgw6.sprintspectrum.com [207.40.188.14]) by mail53-ash.bigfish.com (Postfix) with ESMTP id 225BD53AD21; Fri, 22 Oct 2004 13:40:41 +0000 (UCT) Received: from mailhost.sprintspectrum.com (smtpgw8.it.sprintspectrum.com [207.40.65.56]) by smtpgw6.it.sprintspectrum.com (8.12.11.Beta0/8.12.8) with ESMTP id i9MDeZ3E005679; Fri, 22 Oct 2004 08:40:35 -0500 (CDT) Received: from PDAWG02A.corp.sprint.com (PDAWG02A.corp.sprint.com [10.184.134.80]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9MDeZ118016; Fri, 22 Oct 2004 08:40:35 -0500 (CDT) Received: from pkdwb04c.ad.sprint.com ([10.185.12.36]) by PDAWG02A.corp.sprint.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 22 Oct 2004 08:40:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Next steps for I-D: draft-ietf-mip6-auth-protocol Date: Fri, 22 Oct 2004 08:40:25 -0500 Message-ID: <59BFA9886BBACC439D7875FEA85C9AB708EC18C0@PKDWB04C.ad.sprint.com> Thread-Topic: [Mip6] Next steps for I-D: draft-ietf-mip6-auth-protocol Thread-Index: AcS3wOkuYX/7uRr6Tj+EKuTR8CBsCAAev3DQ From: "Lipford, Mark A [NTK]" To: "Charles E.Perkins" , X-OriginalArrivalTime: 22 Oct 2004 13:40:25.0812 (UTC) FILETIME=[AFAD1140:01C4B83C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: quoted-printable Charlie, I sent a brief reply yesterday, but it may be lost somewhere. 3GPP2 is currently in their R&F piece of completing their release D. This is the review and freeze process where the document is baselined and comments submitted against it. The goal is to try and complete that this month so that the document can be forward to the 3GPP2 SDO's for balloting and to have the ballot comments liaised back to 3GPP2 in time to start addressing them at the December meeting. The general rule is that 3GP2 and TIA will not publish a document with references to IETF Internet-drafts, so we would need to have an RFC number before we complete ballot resolution, which Sprint is pushing to have done in January. You probably recall the FA Challenge I-D and how it held up our initial release, but it is also a critical piece to the successful mobile IP deployments we have. This I-D is similar in importance from our [Sprint's] perspective. Hope this helps. Mark A. Lipford=20 Manager, Sprint Industry Standards=20 6220 Sprint Parkway (Eisenhower C)=20 Mailstop: KSOPHD0504-5D128=20 Overland Park, KS 66251-6118=20 (913) 794-3764 (office)=20 (913) 794-0420 (fax)=20 (913) 579-2319 (mobile)=20 Mark.A.Lipford@mail.sprint.com=20 -----Original Message----- From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On Behalf Of Charles E.Perkins Sent: Thursday, October 21, 2004 2:51 PM To: Basavaraj.Patil@nokia.com Cc: mip6@ietf.org Subject: Re: [Mip6] Next steps for I-D: draft-ietf-mip6-auth-protocol Hello Basvaraj, Basavaraj.Patil@nokia.com wrote: > Well, one of the key driving factors for expediting the work on this > I-D is because of the fact that 3GPP2 would like to incorporate MIP6 > into the TIA-835 specification (Rev D). This would be a major step > forward in terms of MIP6 deployment. The charter of the WG is to take > on tasks that aid in deployment. This is one of those tasks. No problem with that. What is their timeline? >> For instance, I strongly disagree that authentication >> should mandate including the NAI. >=20 > If you are going to use the AAA infra as a means for authenticating a > MIP6 user, and the identity used/configured in the AAA-Home for the > user is an NAI, it makes sense to include the NAI as part of the > auth-protocol. Of course, it is not insane to include the NAI. It is useful in many circumstances. That means "MAY", not "SHOULD". It is equally sensible to run the protocol without NAI, just not with pre-existing equipment that expects otherwise. >> I also wonder >> why there is any mandate to agree with anything >> in rfc3012bis, since that is a protocol specification >> concerned with IPv4. > ???? I dont understand your concern here Charlie. The draft says: The MN MUST use either CHAP_SPI or HMAC_CHAP_SPI as defined in [3012bis] to indicate CHAP style authentication. I don't think it is a good idea to make the specification this way, unless it is already agreed that the numbering space would be kept identical forever. Otherwise, there will have to be two numbering spaces for the SPI field, and in that case the above quoted specification would not be a good idea it seems to me. But this is a relatively minor point, and the original request was to delay the scheduled WG last call in order that I might have time to fully understand the draft. I don't mind adding issues to the issue tracker, but my point is that it's premature for WG last call. Regards, Charlie P. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Oct 22 10:17:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07399 for ; Fri, 22 Oct 2004 10:17:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL0R9-0007HJ-8d for mip6-web-archive@ietf.org; Fri, 22 Oct 2004 10:30:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL06R-00014D-4T; Fri, 22 Oct 2004 10:09:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKzx8-0002TN-5x for mip6@megatron.ietf.org; Fri, 22 Oct 2004 09:59:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04901 for ; Fri, 22 Oct 2004 09:59:31 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL09v-0006oU-8t for mip6@ietf.org; Fri, 22 Oct 2004 10:12:47 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i9MDVXw25152; Fri, 22 Oct 2004 06:31:33 -0700 X-mProtect: <200410221331> Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdXQyOAe; Fri, 22 Oct 2004 06:31:32 PDT Message-ID: <41791283.A9F65CD4@iprg.nokia.com> Date: Fri, 22 Oct 2004 07:00:35 -0700 From: "Charles E.Perkins" 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: "Lipford, Mark A [NTK]" Subject: Re: [Mip6] Next steps for I-D: draft-ietf-mip6-auth-protocol References: <59BFA9886BBACC439D7875FEA85C9AB708EC18C0@PKDWB04C.ad.sprint.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, Basavaraj.Patil@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: 7bit Hello Mark, I could imagine getting through WG last call by January. I can't imagine getting through the RFC editor's queue by January. Would that be O.K.? Regards, Charlie P. "Lipford, Mark A [NTK]" wrote: > > Charlie, > > I sent a brief reply yesterday, but it may be lost somewhere. > > 3GPP2 is currently in their R&F piece of completing their release D. > This is the review and freeze process where the document is baselined > and comments submitted against it. The goal is to try and complete that > this month so that the document can be forward to the 3GPP2 SDO's for > balloting and to have the ballot comments liaised back to 3GPP2 in time > to start addressing them at the December meeting. The general rule is > that 3GP2 and TIA will not publish a document with references to IETF > Internet-drafts, so we would need to have an RFC number before we > complete ballot resolution, which Sprint is pushing to have done in > January. > > You probably recall the FA Challenge I-D and how it held up our initial > release, but it is also a critical piece to the successful mobile IP > deployments we have. This I-D is similar in importance from our > [Sprint's] perspective. > > Hope this helps. > > Mark A. Lipford > Manager, Sprint Industry Standards > 6220 Sprint Parkway (Eisenhower C) > Mailstop: KSOPHD0504-5D128 > Overland Park, KS 66251-6118 > > (913) 794-3764 (office) > (913) 794-0420 (fax) > (913) 579-2319 (mobile) > Mark.A.Lipford@mail.sprint.com > > -----Original Message----- > From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On Behalf Of > Charles E.Perkins > Sent: Thursday, October 21, 2004 2:51 PM > To: Basavaraj.Patil@nokia.com > Cc: mip6@ietf.org > Subject: Re: [Mip6] Next steps for I-D: draft-ietf-mip6-auth-protocol > > Hello Basvaraj, > > Basavaraj.Patil@nokia.com wrote: > > > Well, one of the key driving factors for expediting the work on this > > I-D is because of the fact that 3GPP2 would like to incorporate MIP6 > > into the TIA-835 specification (Rev D). This would be a major step > > forward in terms of MIP6 deployment. The charter of the WG is to take > > on tasks that aid in deployment. This is one of those tasks. > > No problem with that. What is their timeline? > > >> For instance, I strongly disagree that authentication > >> should mandate including the NAI. > > > > If you are going to use the AAA infra as a means for authenticating a > > MIP6 user, and the identity used/configured in the AAA-Home for the > > user is an NAI, it makes sense to include the NAI as part of the > > auth-protocol. > > Of course, it is not insane to include the NAI. It is > useful in many circumstances. That means "MAY", not "SHOULD". > It is equally sensible to run the protocol without NAI, just > not with pre-existing equipment that expects otherwise. > > >> I also wonder > >> why there is any mandate to agree with anything > >> in rfc3012bis, since that is a protocol specification > >> concerned with IPv4. > > > ???? I dont understand your concern here Charlie. > > The draft says: > > The MN MUST use either CHAP_SPI or HMAC_CHAP_SPI as defined in > [3012bis] to indicate CHAP style authentication. > > I don't think it is a good idea to make the specification > this way, unless it is already agreed that the numbering > space would be kept identical forever. Otherwise, there > will have to be two numbering spaces for the SPI field, > and in that case the above quoted specification would not > be a good idea it seems to me. > > But this is a relatively minor point, and the original > request was to delay the scheduled WG last call in order > that I might have time to fully understand the draft. > > I don't mind adding issues to the issue tracker, but > my point is that it's premature for WG last call. > > Regards, > Charlie P. > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Oct 22 10:22:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08123 for ; Fri, 22 Oct 2004 10:22:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL0WV-0007NC-Ug for mip6-web-archive@ietf.org; Fri, 22 Oct 2004 10:36:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL06V-000177-SN; Fri, 22 Oct 2004 10:09:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL01U-00062C-CF for mip6@megatron.ietf.org; Fri, 22 Oct 2004 10:04:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05325 for ; Fri, 22 Oct 2004 10:04:01 -0400 (EDT) Received: from mail-res.bigfish.com ([63.161.60.61] helo=mail44-res-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL0EH-0006tZ-R1 for mip6@ietf.org; Fri, 22 Oct 2004 10:17:18 -0400 Received: from mail44-res.bigfish.com (localhost.localdomain [127.0.0.1]) by mail44-res-R.bigfish.com (Postfix) with ESMTP id CC0E065905F; Fri, 22 Oct 2004 14:03:30 +0000 (UCT) X-BigFish: VC Received: by mail44-res.bigfish.com (MessageSwitch) id 1098453810771539_28883; Fri, 22 Oct 2004 14:03:30 +0000 (UCT) Received: from smtpgw6.it.sprintspectrum.com (smtpgw6.sprintspectrum.com [207.40.188.14]) by mail44-res.bigfish.com (Postfix) with ESMTP id 9700465902F; Fri, 22 Oct 2004 14:03:30 +0000 (UCT) Received: from mailhost.sprintspectrum.com (smtpgw8.it.sprintspectrum.com [207.40.65.56]) by smtpgw6.it.sprintspectrum.com (8.12.11.Beta0/8.12.8) with ESMTP id i9ME3UwL018053; Fri, 22 Oct 2004 09:03:30 -0500 (CDT) Received: from PDAWG01A.corp.sprint.com (PDAWG01A.corp.sprint.com [10.184.134.78]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9ME3U105180; Fri, 22 Oct 2004 09:03:30 -0500 (CDT) Received: from pkdwb04c.ad.sprint.com ([10.185.12.36]) by PDAWG01A.corp.sprint.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 22 Oct 2004 09:03:28 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Next steps for I-D: draft-ietf-mip6-auth-protocol Date: Fri, 22 Oct 2004 09:03:05 -0500 Message-ID: <59BFA9886BBACC439D7875FEA85C9AB706292AB2@PKDWB04C.ad.sprint.com> Thread-Topic: [Mip6] Next steps for I-D: draft-ietf-mip6-auth-protocol Thread-Index: AcS4P0iS4xQDIeYcRESUx+BLVX8pzQAAHGWA From: "Lipford, Mark A [NTK]" To: "Charles E.Perkins" X-OriginalArrivalTime: 22 Oct 2004 14:03:28.0361 (UTC) FILETIME=[E7BD4D90:01C4B83F] X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org, Basavaraj.Patil@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Content-Transfer-Encoding: quoted-printable Think there is a chance of at least getting a number assigned? I really don't know how long that takes. Mark A. Lipford=20 Manager, Sprint Industry Standards=20 6220 Sprint Parkway (Eisenhower C)=20 Mailstop: KSOPHD0504-5D128=20 Overland Park, KS 66251-6118=20 (913) 794-3764 (office)=20 (913) 794-0420 (fax)=20 (913) 579-2319 (mobile)=20 Mark.A.Lipford@mail.sprint.com=20 -----Original Message----- From: charliep@darkstar.iprg.nokia.com [mailto:charliep@darkstar.iprg.nokia.com] On Behalf Of Charles E.Perkins Sent: Friday, October 22, 2004 9:01 AM To: Lipford, Mark A [NTK] Cc: Basavaraj.Patil@nokia.com; mip6@ietf.org Subject: Re: [Mip6] Next steps for I-D: draft-ietf-mip6-auth-protocol Hello Mark, I could imagine getting through WG last call by January. I can't imagine getting through the RFC editor's queue by January. Would that be O.K.? Regards, Charlie P. "Lipford, Mark A [NTK]" wrote: >=20 > Charlie, >=20 > I sent a brief reply yesterday, but it may be lost somewhere. >=20 > 3GPP2 is currently in their R&F piece of completing their release D. > This is the review and freeze process where the document is baselined > and comments submitted against it. The goal is to try and complete that > this month so that the document can be forward to the 3GPP2 SDO's for > balloting and to have the ballot comments liaised back to 3GPP2 in time > to start addressing them at the December meeting. The general rule is > that 3GP2 and TIA will not publish a document with references to IETF > Internet-drafts, so we would need to have an RFC number before we > complete ballot resolution, which Sprint is pushing to have done in > January. >=20 > You probably recall the FA Challenge I-D and how it held up our initial > release, but it is also a critical piece to the successful mobile IP > deployments we have. This I-D is similar in importance from our > [Sprint's] perspective. >=20 > Hope this helps. >=20 > Mark A. Lipford > Manager, Sprint Industry Standards > 6220 Sprint Parkway (Eisenhower C) > Mailstop: KSOPHD0504-5D128 > Overland Park, KS 66251-6118 >=20 > (913) 794-3764 (office) > (913) 794-0420 (fax) > (913) 579-2319 (mobile) > Mark.A.Lipford@mail.sprint.com >=20 > -----Original Message----- > From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On Behalf Of > Charles E.Perkins > Sent: Thursday, October 21, 2004 2:51 PM > To: Basavaraj.Patil@nokia.com > Cc: mip6@ietf.org > Subject: Re: [Mip6] Next steps for I-D: draft-ietf-mip6-auth-protocol >=20 > Hello Basvaraj, >=20 > Basavaraj.Patil@nokia.com wrote: >=20 > > Well, one of the key driving factors for expediting the work on this > > I-D is because of the fact that 3GPP2 would like to incorporate MIP6 > > into the TIA-835 specification (Rev D). This would be a major step > > forward in terms of MIP6 deployment. The charter of the WG is to take > > on tasks that aid in deployment. This is one of those tasks. >=20 > No problem with that. What is their timeline? >=20 > >> For instance, I strongly disagree that authentication > >> should mandate including the NAI. > > > > If you are going to use the AAA infra as a means for authenticating a > > MIP6 user, and the identity used/configured in the AAA-Home for the > > user is an NAI, it makes sense to include the NAI as part of the > > auth-protocol. >=20 > Of course, it is not insane to include the NAI. It is > useful in many circumstances. That means "MAY", not "SHOULD". > It is equally sensible to run the protocol without NAI, just > not with pre-existing equipment that expects otherwise. >=20 > >> I also wonder > >> why there is any mandate to agree with anything > >> in rfc3012bis, since that is a protocol specification > >> concerned with IPv4. >=20 > > ???? I dont understand your concern here Charlie. >=20 > The draft says: >=20 > The MN MUST use either CHAP_SPI or HMAC_CHAP_SPI as defined in > [3012bis] to indicate CHAP style authentication. >=20 > I don't think it is a good idea to make the specification > this way, unless it is already agreed that the numbering > space would be kept identical forever. Otherwise, there > will have to be two numbering spaces for the SPI field, > and in that case the above quoted specification would not > be a good idea it seems to me. >=20 > But this is a relatively minor point, and the original > request was to delay the scheduled WG last call in order > that I might have time to fully understand the draft. >=20 > I don't mind adding issues to the issue tracker, but > my point is that it's premature for WG last call. >=20 > Regards, > Charlie P. >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Oct 22 12:58:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20406 for ; Fri, 22 Oct 2004 12:58:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL2wt-0002Cy-Dn for mip6-web-archive@ietf.org; Fri, 22 Oct 2004 13:11:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL2gS-0003LU-Ib; Fri, 22 Oct 2004 12:54:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL2ab-0001fg-Ke for mip6@megatron.ietf.org; Fri, 22 Oct 2004 12:48:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19786 for ; Fri, 22 Oct 2004 12:48:25 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL2nP-00022l-Ol for mip6@ietf.org; Fri, 22 Oct 2004 13:01:44 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i9MGKX225232 for ; Fri, 22 Oct 2004 09:20:33 -0700 X-mProtect: <200410221620> Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdB7iSkB; Fri, 22 Oct 2004 09:20:31 PDT Message-ID: <41793A1F.3A6F4909@iprg.nokia.com> Date: Fri, 22 Oct 2004 09:49:35 -0700 From: "Charles E.Perkins" 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: Mobile IPv6 Mailing List Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Subject: [Mip6] "Precomputable Binding Management Key Kbm for Mobile IPv6" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Hello folks, I have submitted a revised version of the abovementioned Internet Draft, draft-ietf-mip6-precfgKbm-01.txt to the Internet Draft directories. Until it is published, you can access it at the following URL: http://people.nokia.net/~charliep/txt/mobilev6/precfg.txt I thought the filename should be changed to reflect the revised functionality, but then that would probably violate some rule and cause a significant delay in publication. Regards, Charlie P. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Oct 22 13:02:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20645 for ; Fri, 22 Oct 2004 13:02:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL30x-0002Gw-PF for mip6-web-archive@ietf.org; Fri, 22 Oct 2004 13:15:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL2gV-0003OD-76; Fri, 22 Oct 2004 12:54:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL2cU-0001za-04 for mip6@megatron.ietf.org; Fri, 22 Oct 2004 12:50:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19899 for ; Fri, 22 Oct 2004 12:50:21 -0400 (EDT) From: Basavaraj.Patil@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL2pF-00024t-NN for mip6@ietf.org; Fri, 22 Oct 2004 13:03:41 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9MGoIo23489 for ; Fri, 22 Oct 2004 19:50:18 +0300 (EET DST) X-Scanned: Fri, 22 Oct 2004 19:50:07 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i9MGo6UK028786 for ; Fri, 22 Oct 2004 19:50:07 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00pUEX4V; Fri, 22 Oct 2004 19:50:06 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9MGo5S28387 for ; Fri, 22 Oct 2004 19:50:05 +0300 (EET DST) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 22 Oct 2004 11:50:04 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Requests for time on agenda at IETF61 meeting (Rev1) Date: Fri, 22 Oct 2004 11:50:03 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF4403B1C035@daebe007.americas.nokia.com> Thread-Topic: Requests for time on agenda at IETF61 meeting Thread-Index: AcS3l3q1hNuyjMjuR92bg08E5gAyEwAv6CBA To: X-OriginalArrivalTime: 22 Oct 2004 16:50:04.0296 (UTC) FILETIME=[2DC7F080:01C4B857] X-Spam-Score: 0.3 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: quoted-printable X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable I missed a couple earlier. # Requester I-D Time -- --------- 1 Giaretta Gerardo draft-giaretta-mip6-authorization-eap-02 25 draft-giaretta-mip6-amsk-00.txt=20 draft-giaretta-mip6-aaa-ha-goals-00 2 Junghoon Jee draft-jee-mip6-bootstrap-pana-00.txt 15 3 Francis Dupont draft-dupont-mipv6-cn-ipsec-01.txt 5 draft-dupont-mipv6-cn-ipsec-01.txt 5 4 Vijay Devarapalli draft-ietf-mip6-ikev2-ipsec-00.txt 20 5 Alper Yegin draft-yegin-mip6-aaa-fwk-00.txt 10 6 Yoshihiro Ohba draft-ohba-mip6-boot-arch-dhcp-00.txt 15 7 Jianying Zhou draft-qiu-mip6-rr-improvement-00.txt 10 Please let me know if I have missed any requests. -Basavaraj _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Oct 22 13:07:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21047 for ; Fri, 22 Oct 2004 13:07:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL36E-0002M7-AN for mip6-web-archive@ietf.org; Fri, 22 Oct 2004 13:21:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL2p0-0006PT-98; Fri, 22 Oct 2004 13:03:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL2h4-0003uN-V6 for mip6@megatron.ietf.org; Fri, 22 Oct 2004 12:55:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20165 for ; Fri, 22 Oct 2004 12:55:06 -0400 (EDT) Received: from av1-2-sn4.m-sp.skanova.net ([81.228.10.115]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL2tj-00028K-9T for mip6@ietf.org; Fri, 22 Oct 2004 13:08:25 -0400 Received: by av1-2-sn4.m-sp.skanova.net (Postfix, from userid 502) id 9F33337F02; Fri, 22 Oct 2004 18:54:25 +0200 (CEST) Received: from smtp2-1-sn4.m-sp.skanova.net (smtp2-1-sn4.m-sp.skanova.net [81.228.10.183]) by av1-2-sn4.m-sp.skanova.net (Postfix) with ESMTP id 912C137E59 for ; Fri, 22 Oct 2004 18:54:25 +0200 (CEST) Received: from shiraz.levkowetz.com (h195n1fls311o871.telia.com [213.64.174.195]) by smtp2-1-sn4.m-sp.skanova.net (Postfix) with ESMTP id 7E26C37E44 for ; Fri, 22 Oct 2004 18:54:25 +0200 (CEST) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=h195n1fls311o871.telia.com) by shiraz.levkowetz.com with esmtp (Exim 4.34) id 1CL2gK-0002KX-Gy for mip6@ietf.org; Fri, 22 Oct 2004 18:54:25 +0200 To: mip6@ietf.org From: Basavaraj Patil Date: Fri, 22 Oct 2004 16:54:23 +0000 MIME-Version: 1.0 Message-Id: <1098464063.09.0.475761813675.issue10@mip4.org> X-Roundup-Name: Mip6 issue tracker X-Roundup-Loop: hello X-Exim-Helo-Check-Failed: Verification failed for HELO h195n1fls311o871.telia.com X-SA-Exim-Connect-IP: 192.168.3.14 X-SA-Exim-Mail-From: roundup-admin@mip4.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on shiraz.levkowetz.com X-Spam-Status: No, hits=-1.9 required=3.0 tests=AWL,BAYES_00, X_HELO_CHECK_FAILED autolearn=no version=2.64 X-SA-Exim-Version: 4.1 (built Tue, 17 Aug 2004 11:06:07 +0200) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable Subject: [Mip6] [issue10] Editorial issues to be fixed X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mip6 issue tracker List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable New submission from Basavaraj Patil : - Page 12, paragraph 2.6 'at least one prefix option with the Rou_t_er Address (R) bit set': add 't' in 'Router'. - Page 15, paragraph 3.1 'However, section 7 of Ad_a_vanced API...': remove extra 'a' in 'Advanced'. - Page 15, paragraph 3.1.1 'However, if any Mobile IPv6... send/process pa_kc_ets at..': change 'pakcets' to 'packets' - Page 20, paragraph 10: please change 'Mark Brost' to 'Mark Borst' ;) Furthermore, there are a lot of superfluous spaces in the text. However, a good formatting tool will fix that. And the references to 'Advanced Sockets API for IPv6' are very variable and inconsistent. I would suggest to adapt a short form for it, and either use the correct complete reference or use the short form reference. Now I find a lot of different references. Also the use of capitalization in terms as 'Routing Header Type 2' is not consistent. ---------- category: Editorial draft: draft-ietf-mip6-mipext-advapi messages: 43 nosy: bpatil priority: Must fix status: No discussion title: Editorial issues to be fixed _________________________________________________ Mip6 issue tracker _________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Oct 22 17:39:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23023 for ; Fri, 22 Oct 2004 17:39:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL7LG-0002oS-VT for mip6-web-archive@ietf.org; Fri, 22 Oct 2004 17:52:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL6gE-0007Af-Qb; Fri, 22 Oct 2004 17:10:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL5kz-0000a5-T4; Fri, 22 Oct 2004 16:11:25 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06342; Fri, 22 Oct 2004 16:11:22 -0400 (EDT) Message-Id: <200410222011.QAA06342@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 22 Oct 2004 16:11:21 -0400 Cc: mip6@ietf.org Subject: [Mip6] I-D ACTION:draft-ietf-mip6-precfgkbm-01.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv6 Working Group of the IETF. Title : Preconfigured Binding Management Keys for Mobile IPv6 Author(s) : C. Perkins Filename : draft-ietf-mip6-precfgkbm-01.txt Pages : 5 Date : 2004-10-22 A mobile node and a correspondent node may preconfigure data useful for precomputing a Binding Management Key that can subsequently be used for authorizing Binding Updates. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-precfgkbm-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mip6-precfgkbm-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip6-precfgkbm-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-22162018.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-precfgkbm-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-precfgkbm-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-22162018.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --NextPart-- From mip6-bounces@ietf.org Fri Oct 22 19:38:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14024 for ; Fri, 22 Oct 2004 19:38:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL9Ci-0000mE-Lc for mip6-web-archive@ietf.org; Fri, 22 Oct 2004 19:52:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL8ox-000200-M9; Fri, 22 Oct 2004 19:27:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL8hU-0005tf-Ba for mip6@megatron.ietf.org; Fri, 22 Oct 2004 19:20:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12478 for ; Fri, 22 Oct 2004 19:19:58 -0400 (EDT) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL8uE-0000KH-Tu for mip6@ietf.org; Fri, 22 Oct 2004 19:33:21 -0400 Message-ID: <006601c4b88d$bf0c7260$5d6015ac@dcml.docomolabsusa.com> From: "James Kempf" To: Date: Fri, 22 Oct 2004 16:20:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit Subject: [Mip6] Review of draft-ietf-mip6-firewalls-00.txt (with reference to draft-chen-mip6-gprs-02.txt) X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit I believe this draft is in last call at the moment. It seems to have been a "stealth" WG draft, since it was never listed on the WG Web page until recently. I also personally cannot recall having seen a concensus call on the mailing list to make it a WG draft, but perhaps that might be due to a lapse of memory on my part or an over-eager spam filter on my laptop's. In any case, the draft does deal with a problem that needs attention for successful deployment. In fact, draft-chen-mip6-gprs-02.txt represents a specific instantiation in GPRS of the general problem discussed in draft-ietf-mip6-firewalls. As a general comment, I believe draft-ietf-mip6-firewalls-00.txt is lacking precision in its description of the problem. One need only look at draft-chen-mip6-gprs-02.txt for an excellent example of how to more precisely describe the interaction between firewalls and MIPv6 packets, the firewall in that case being a GGSN. draft-chen goes through a few cases in very specific detail. The description, to be sure, is very specific to GPRS but draft-chen does a much better job of describing the problem than draft-ietf-mip6-firewalls. One way this draft could be made more readable is to organize it more like draft-chen, including all the cases of placement of the MN, HA, and CN. The current draft-ietf-mip6-firewalls has specific sections in 3.1, where the MN is outside and stays outside, and 3.2 in which the MN is inside and stays inside. Even for those cases the discussion is made somewhat vague by lack of specific description of the addresses involved and what state is established (or not) in the firewall when, something that draft-chen does very well. However, in draft-ietf-mip6-firewalls the discussion of the more complex case when an MN moves from outside a firewall to inside is somewhat muddied and vague in Section 3.2.2. This case is especially in need of very explict consideration of addresses and firewall state, and very clear explanation of the problem. Specific comments: Section 3.2.2, starting about Paragraph 3: the description of why packets forwarded between the HA and MN might get dropped is not very clear. The problem seems to be that when a MN roams into an area of network topology controlled by a stateful firewall, there is no state in the firewall corresponding to (HA src addr, MN CoA dest addr). But this is never specifically articulated. Section 3.2.2, Paragraph 8: This point is true for any case where a session is initiated from outside the firewall, for example, an incoming VoIP call started by SIP. Why is MIPv6 any different? Section 3.2.2, Paragraph 10: The discussion doesn't consider the distinction between a TCP and UDP session. Earlier in the text, the description of the state maintained in the firewall implies a distinction. But if a MIPv6 host is receiving TCP packets tunneled from the HA, then the firewall state will be for UDP (presuming it is set up at all). The firewall timers for UDP may interact negatively with the MN's TCP timeouts, and there may be other problems. Section 3.2.3, Paragraph 5: This paragraph is not only true of RR packets but also of BU packets if the MN chooses to use ESP encryption for them as well. Consequently, it should be discussed in a separate section not specifically devoted to RR. Section 3.2.3, Paragraph 7: This paragraph is implying that the problem may be due to the lack of ability to detect firewalls. IPsec can deal with NATs because they can be detected. Why not simply come out and say this? Having the ability to detect and negotiate with a firewall is something that the IETF has (in my opinion) been needing for some time, and MIP only makes the case stronger. In summary, I believe this draft needs a lot of work before it is ready to be sent to the IESG. I'd suggest the authors may want to talk to the authors of draft-chen about merging the two. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Oct 22 20:12:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15729 for ; Fri, 22 Oct 2004 20:12:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL9j9-0001Jz-Im for mip6-web-archive@ietf.org; Fri, 22 Oct 2004 20:25:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL9Ti-0006Z4-Oh; Fri, 22 Oct 2004 20:09:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL9KP-00027t-VT for mip6@megatron.ietf.org; Fri, 22 Oct 2004 20:00:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15130 for ; Fri, 22 Oct 2004 20:00:13 -0400 (EDT) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL9XL-00019Y-28 for mip6@ietf.org; Fri, 22 Oct 2004 20:13:35 -0400 Message-ID: <007401c4b893$63fe73e0$5d6015ac@dcml.docomolabsusa.com> From: "James Kempf" To: Date: Fri, 22 Oct 2004 17:00:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit Subject: [Mip6] Review of draft-giaretta-mip6-authorization-eap-02.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit This draft-giaretta proposes a solution for the dynamic bootstrapping problem that works for IASPs. It is not a solution for WISPs and other scenarios where the MSP is separate from the ASP. I think this version of the draft is a considerable improvement over the previous version. I believe it is a candidate for a WG draft for one solution (not *the* solution) to the dynamic bootstrapping problem, that works for IASPs. Working group chairs: can we have a concensus call in DC after the draft is presented about whether the draft should be made a WG draft? I have a few specific comments on the draft. General editorial comment: In many cases, the authors have parenthetical comments about possible protocols or mechanisms to achieve some kind of result, for example, Section 3, Step 6: ...the MN gains network access and aquires a valid Care-of Address within the visited subnet (e.g. via stateless autoconfiguration). In most cases, the mechanisms cited in the parenthetical comments are not exhaustive, but only examplary. While reading the draft, I was constantly noting other mechanisms that were missing and could be used. I think it would be best to either drop these parenthetical comments or include an exhaustive list. Otherwise, readers may think only the listed mechanisms apply. Section 1, paragraph 1: This is a mischaracterization of the dynamic bootstrapping problem. The problem is not that there is no way in RFC 3775 to autoconfigure the HA addr and HoA addr. The problem is that it is not possible to do that and, at the same time, dynamically configure the IPsec SAs with the home agent. It is also not possible to configure the HA addr and the HoA addr independently from statically configuring some topology information on the MN. Section 1, paragraph 4: The draft at this point lacks sufficient clarity about how a roaming MN would be configured with a dynamically assigned home agent in the foreign network. I believe that should be mentioned, unless it is a goal of the authors to eventually encompass this scenario in the draft. Figure 2: Is the link between the MN and "AAA Client" (presumably NAS or AAA-F) limited to 802.1x and PANA? I think not. Other Layer 2.5 protocols might be used for other Layer 2, for example, 802.16 does not use 802.1x for auth but does use EAP. Section 3, Step 4: The authors have a companion draft for deriving an application master key, wouldn't it be appropriate to cite that draft at the end of this paragraph? Section 4: I think this section should be moved to an appendix. It is necessary and quite relevant, but not to the specification of the protocol. Section 5, paragraph 21: I'm not really sure the AAA server should be responsible for load balancing MNs among HAs. Some people in IETF feel that even using EAP to distribute MIP bootstrapping information isn't such a good idea. From the standpoint of the EAP protocol extensions described in this document, it doesn't matter. I'd suggest dropping this from the text, as it is rather something for the back end protocol between the HA and AAA-H server. Section 8.3: I would like a flag here indicating to the MN that it should derive its HoA from IKEv2. Section 8.8 and 8.9: Could these two options be combined? I don't see any case where a message from the server would come with one and not the other. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat Oct 23 05:14:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10553 for ; Sat, 23 Oct 2004 05:14:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLIBi-0001IK-HL for mip6-web-archive@ietf.org; Sat, 23 Oct 2004 05:27:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLHwO-0000zu-5l; Sat, 23 Oct 2004 05:12:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLHp0-0006ZQ-3C for mip6@megatron.ietf.org; Sat, 23 Oct 2004 05:04:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10106 for ; Sat, 23 Oct 2004 05:04:15 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLI1w-0001AV-19 for mip6@ietf.org; Sat, 23 Oct 2004 05:17:44 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i9N93WZ10663; Sat, 23 Oct 2004 11:03:32 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i9N93VSj006610; Sat, 23 Oct 2004 11:03:31 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200410230903.i9N93VSj006610@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Charles E.Perkins" Subject: Re: [Mip6] New draft revision for preconfigured keys for authenticating Binding Updates In-reply-to: Your message of Thu, 21 Oct 2004 13:50:36 PDT. <4178211C.C2A173E7@iprg.nokia.com> Date: Sat, 23 Oct 2004 11:03:31 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 In your previous mail you wrote: During the last IETF, there was discussion about whether or not to include a Care-of Address test in this draft, so that a correspondent node could use the basic idea of the draft while still having equal confidence that the mobile node is legitimately addressable as it claims. The consensus as I recall is that this "preconfigured" draft should NOT take on the additional specification for the Care-of Test that would have been needed. => I designed a care-of test for the MN-CN IPsec draft: at the last meeting I proposed to make it a separate document which can be used for any RO protection mechanism without a built-in care-of address test. Obviously the pre-configured key document is one of them... Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat Oct 23 05:34:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11588 for ; Sat, 23 Oct 2004 05:34:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLIUg-0001bl-Ux for mip6-web-archive@ietf.org; Sat, 23 Oct 2004 05:47:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLI9Z-00070v-Tl; Sat, 23 Oct 2004 05:25:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLI2M-0003Bg-IT for mip6@megatron.ietf.org; Sat, 23 Oct 2004 05:18:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10707 for ; Sat, 23 Oct 2004 05:18:07 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLIFM-0001Kh-Qc for mip6@ietf.org; Sat, 23 Oct 2004 05:31:37 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i9N9HVZ12230; Sat, 23 Oct 2004 11:17:31 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i9N9HVSj006742; Sat, 23 Oct 2004 11:17:31 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200410230917.i9N9HVSj006742@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Soliman, Hesham" Subject: Re: [Mip6] Next steps for I-D: draft-ietf-mip6-auth-protocol In-reply-to: Your message of Thu, 21 Oct 2004 21:35:23 EDT. Date: Sat, 23 Oct 2004 11:17:31 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: mip6@ietf.org, Vijay Devarapalli , Basavaraj.Patil@nokia.com, Charlie P , Alpesh X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 In your previous mail you wrote: => I agree with Charlie, SHOULD is too strong. There SHOULD be alternatives like IMSI ...etc => I believe you mean the GSM IMSI (the thing which should never be sent in clear over the network :-), don't you? Regards Francis.Dupont@enst-bretagne.fr PS: BTW I agree and I have a real concern about RFC 2119 keyword misused in some documents of this WG, for instance the IKEv2 one... Here an ID is RECOMMENDED or even REQUIRED, but not a particular ID. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat Oct 23 08:58:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24356 for ; Sat, 23 Oct 2004 08:58:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLLgY-0004xT-BX for mip6-web-archive@ietf.org; Sat, 23 Oct 2004 09:11:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLLO0-0007oo-4d; Sat, 23 Oct 2004 08:52:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLLJx-0005ma-9P for mip6@megatron.ietf.org; Sat, 23 Oct 2004 08:48:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23798 for ; Sat, 23 Oct 2004 08:48:31 -0400 (EDT) Received: from laposte.enst-bretagne.fr ([192.108.115.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLLWz-0004lt-8v for mip6@ietf.org; Sat, 23 Oct 2004 09:02:01 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i9NClxZ24664; Sat, 23 Oct 2004 14:47:59 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i9NCm0Sj008478; Sat, 23 Oct 2004 14:48:00 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200410231248.i9NCm0Sj008478@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "James Kempf" Subject: Re: [Mip6] Review of draft-giaretta-mip6-authorization-eap-02.txt In-reply-to: Your message of Fri, 22 Oct 2004 17:00:59 PDT. <007401c4b893$63fe73e0$5d6015ac@dcml.docomolabsusa.com> Date: Sat, 23 Oct 2004 14:47:59 +0200 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c In your previous mail you wrote: I think this version of the draft is a considerable improvement over the previous version. I believe it is a candidate for a WG draft for one solution (not *the* solution) to the dynamic bootstrapping problem, that works for IASPs. => IMHO there cannot be "the" solution, but only some solutions which can be used in particular contexts... (note that I support the draft as a candidate too) Working group chairs: can we have a concensus call in DC after the draft is presented about whether the draft should be made a WG draft? => as it is the most advanced proposal IMHO it should be push. ...the MN gains network access and aquires a valid Care-of Address within the visited subnet (e.g. via stateless autoconfiguration). => I've lost most of my latin by "e.g." explicitely introduce an example. Section 1, paragraph 1: This is a mischaracterization of the dynamic bootstrapping problem. The problem is not that there is no way in RFC 3775 to autoconfigure the HA addr and HoA addr. The problem is that it is not possible to do that and, at the same time, dynamically configure the IPsec SAs with the home agent. => I disagree about the HoA address but you are 100% right about the HA address. Figure 2: Is the link between the MN and "AAA Client" (presumably NAS or AAA-F) limited to 802.1x and PANA? I think not. Other Layer 2.5 protocols might be used for other Layer 2, for example, 802.16 does not use 802.1x for auth but does use EAP. => 802.16 itself (i.e., the IEEE document without an extra letter or digit) uses an authentication scheme derived from DOCSIS very different from EAP. Thanks Francis.Dupont@enst-bretagne.fr PS: it should be fine to collect implementation reports too (note this remark should apply to all WG (relative) documents, including RFC 3775 and 3776). _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat Oct 23 23:26:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12003 for ; Sat, 23 Oct 2004 23:26:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLZF6-0001FA-Nb for mip6-web-archive@ietf.org; Sat, 23 Oct 2004 23:40:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLZ0C-0004Qf-FJ; Sat, 23 Oct 2004 23:25:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLYzD-0004It-3r for mip6@megatron.ietf.org; Sat, 23 Oct 2004 23:24:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11954 for ; Sat, 23 Oct 2004 23:23:59 -0400 (EDT) From: Basavaraj.Patil@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLZCL-0001DT-NU for mip6@ietf.org; Sat, 23 Oct 2004 23:37:39 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9O3Nw318561; Sun, 24 Oct 2004 06:23:58 +0300 (EET DST) X-Scanned: Sun, 24 Oct 2004 06:22:35 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i9O3MZHC007444; Sun, 24 Oct 2004 06:22:35 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00SgW80f; Sun, 24 Oct 2004 06:22:33 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9O3MTa15186; Sun, 24 Oct 2004 06:22:29 +0300 (EET DST) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sat, 23 Oct 2004 22:22:30 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Review of draft-ietf-mip6-firewalls-00.txt (with referenceto draft-chen-mip6-gprs-02.txt) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Sat, 23 Oct 2004 22:22:27 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF4403B1C03B@daebe007.americas.nokia.com> Thread-Topic: [Mip6] Review of draft-ietf-mip6-firewalls-00.txt (with referenceto draft-chen-mip6-gprs-02.txt) Thread-Index: AcS4kHimwPTEH7iuS6+xBLIWhujGFgA5/eOQ To: , X-OriginalArrivalTime: 24 Oct 2004 03:22:30.0960 (UTC) FILETIME=[B22B1B00:01C4B978] X-Spam-Score: 0.3 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable Jim, >=20 > I believe this draft is in last call at the moment. It seems=20 > to have been a > "stealth" WG draft, since it was never listed on the WG Web page until > recently. I also personally cannot recall having seen a=20 > concensus call on > the mailing list to make it a WG draft, but perhaps that=20 > might be due to a > lapse of memory on my part or an over-eager spam filter on my=20 > laptop's.=20 There is no "conspiracy theory" here. There was a problem with the IETF MIP6 WG Web page. It took a while for the web-admin of the page to get the draft listed. The ID has been listed as a WG ID in the repository for quite a while now. -BPa _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Oct 25 11:39:42 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05394 for ; Mon, 25 Oct 2004 11:39:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM7AC-0000af-9e for mip6-web-archive@ietf.org; Mon, 25 Oct 2004 11:53:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM6uH-0003bT-Sy; Mon, 25 Oct 2004 11:37:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM6oq-0003DF-7U for mip6@megatron.ietf.org; Mon, 25 Oct 2004 11:31:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04748 for ; Mon, 25 Oct 2004 11:31:33 -0400 (EDT) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM72J-0000SV-DB for mip6@ietf.org; Mon, 25 Oct 2004 11:45:32 -0400 Message-ID: <006401c4baa7$d4b47ec0$656115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Francis Dupont" References: <200410231248.i9NCm0Sj008478@givry.rennes.enst-bretagne.fr> Subject: Re: [Mip6] Review of draft-giaretta-mip6-authorization-eap-02.txt Date: Mon, 25 Oct 2004 08:32:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Francis, > Section 1, paragraph 1: This is a mischaracterization of the dynamic > bootstrapping problem. The problem is not that there is no way in RFC 3775 > to autoconfigure the HA addr and HoA addr. The problem is that it is not > possible to do that and, at the same time, dynamically configure the IPsec > SAs with the home agent. > > => I disagree about the HoA address but you are 100% right about the HA > address. > Sections 6.5 and 6.6 in RFC 3775 describe Home Agent address discovery, based on the home subnet prefix (that's what I meant by requiring topological information). So the base spec has a procedure, whether or not the described procedure is deployable is of course another question. > Figure 2: Is the link between the MN and "AAA Client" (presumably NAS or > AAA-F) limited to 802.1x and PANA? I think not. Other Layer 2.5 protocols > might be used for other Layer 2, for example, 802.16 does not use 802.1x for > auth but does use EAP. > > => 802.16 itself (i.e., the IEEE document without an extra letter or digit) > uses an authentication scheme derived from DOCSIS very different from EAP. > Section 6.3.2.3.9 (phew!) of the latest draft of 802.16e, the mobility extension, specifies EAP for key managment. I'm not sure what 802.16d, the updated air interface specification, specifies in this space, as I've yet to crack its 900 pages. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Oct 25 11:42:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05659 for ; Mon, 25 Oct 2004 11:42:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM7Ck-0000de-FR for mip6-web-archive@ietf.org; Mon, 25 Oct 2004 11:56:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM6uq-0003dx-92; Mon, 25 Oct 2004 11:37:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM6rC-0003PP-EP for mip6@megatron.ietf.org; Mon, 25 Oct 2004 11:34:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04866 for ; Mon, 25 Oct 2004 11:33:59 -0400 (EDT) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM74f-0000U6-Ps for mip6@ietf.org; Mon, 25 Oct 2004 11:47:58 -0400 Message-ID: <007001c4baa8$2cbc8180$656115ac@dcml.docomolabsusa.com> From: "James Kempf" To: , References: <697DAA22C5004B4596E033803A7CEF4403B1C03B@daebe007.americas.nokia.com> Subject: Re: [Mip6] Review of draft-ietf-mip6-firewalls-00.txt (with referenceto draft-chen-mip6-gprs-02.txt) Date: Mon, 25 Oct 2004 08:34:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Raj, >> I believe this draft is in last call at the moment. It seems >> to have been a >> "stealth" WG draft, since it was never listed on the WG Web page until >> recently. I also personally cannot recall having seen a >> concensus call on >> the mailing list to make it a WG draft, but perhaps that >> might be due to a >> lapse of memory on my part or an over-eager spam filter on my >> laptop's. > >There is no "conspiracy theory" here. There was a problem with the >IETF MIP6 WG Web page. It took a while for the web-admin of the page >to get the draft listed. The ID has been listed as a WG ID in the >repository for quite a while now. Who said anything about a conspiracy theory? As I said, my memory or spam filter may have been at fault. I was just noting that it is quite unusual for a draft to go into Last Call when it isn't listed on the WG web page. In fact, I can't remember that ever having occured for another WG. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Oct 25 12:48:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13140 for ; Mon, 25 Oct 2004 12:48:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM8F8-0002ef-VG for mip6-web-archive@ietf.org; Mon, 25 Oct 2004 13:02:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM7os-0006zy-Ou; Mon, 25 Oct 2004 12:35:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM7jX-00068G-6y for mip6@megatron.ietf.org; Mon, 25 Oct 2004 12:30:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11903 for ; Mon, 25 Oct 2004 12:30:07 -0400 (EDT) Received: from mail-eur.microsoft.com ([213.199.128.145]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM7x0-0002HP-M1 for mip6@ietf.org; Mon, 25 Oct 2004 12:44:07 -0400 Received: from EUR-MSG-20.europe.corp.microsoft.com ([65.53.210.18]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 25 Oct 2004 17:29:35 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 25 Oct 2004 17:29:36 +0100 Message-ID: <892867B805D4DA42A1C48103BF4CFA5A932122@EUR-MSG-20.europe.corp.microsoft.com> Thread-Topic: MIPv6 use of IPsec Thread-Index: AcS6r8SCPy37LWa2TvKCc2t1jUk7/A== From: "Michael Roe" To: X-OriginalArrivalTime: 25 Oct 2004 16:29:35.0242 (UTC) FILETIME=[D0726EA0:01C4BAAF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Subject: [Mip6] MIPv6 use of IPsec X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1756555754==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 --===============1756555754== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 QXQgdGhlIEVUU0kgSVB2NiBwbHVndGVzdCwgSSBlbmNvdW50ZXJlZCBzb21lIGludGVyb3BlcmFi aWxpdHkgcHJvYmxlbXMNCndpdGggTUlQdjYgdXNlIG9mIElQU2VjLiBJIGFtIHN0YXJ0aW5nIHRv IHRoaW5rIHRoYXQgcmVwbGFjZW1lbnRzIGZvcg0KUkZDIDM3NzYgKGUuZy4gdGhlIElLRXYyIGFu ZCBNSVB2NiBkb2N1bWVudCkgb3VnaHQgdG8gZ2l2ZSBtb3JlIGRldGFpbA0Kb24gd2hhdCBpcyBt YW5kYXRvcnkgdG8gaW1wbGVtZW50IC0gc28gdGhhdCB3ZSBjYW4gZ3VhcmFudGVlIHRoYXQgYQ0K Y29uZm9ybWluZyBNTiBhbmQgYSBjb25mb3JtaW5nIEhBIHdpbGwgYmUgYWJsZSB0byB0YWxrIHRv IGVhY2ggb3RoZXIuDQoNClRoZXJlIGFyZSAoYXQgbGVhc3QpIHRocmVlIHdheXMgdG8gSVBTZWMg cHJvdGVjdCBSUiBhbmQgcGF5bG9hZCBwYWNrZXRzDQpiZXR3ZWVuIGEgTU4gYW5kIEhBOg0KDQph KSBSUiBzaWduYWxsaW5nIHVzZXMgU0EzL1NBNDsgcGF5bG9hZCBwYWNrZXRzIHVzZSBJUC1pbi1J UCAobm90IElQU2VjKSBlbmNhcHVsYXRpb24NCg0KYikgUlIgc2lnbmFsbGluZyBhbmQgcGF5bG9h ZCBwYWNrZXRzIHVzZSB0aGUgU0FNRSBwYWlyIG9mIFNhcw0KDQpjKSBSUiBzaWduYWxsaW5nIGFu ZCBwYXlsb2FkIHBhY2tldHMgdXNlIGEgRElGRkVSRU5UIHBhaXIgb2YgU2FzDQogICAoU0E0L1NB NCBmb3IgUlIsIFNBNy9TQTggZm9yIHBheWxvYWQpDQoNClRoZSBNaWNyb3NvZnQgaW1wbGVtZW50 YXRpb24gb25seSBzdXBwb3J0cyBvcHRpb24gKGIpLiBJIGJlbGlldmUgdGhhdA0KS0FNRSBjYW4g YWxzbyBzdXBwb3J0IChiKS4NCg0KUkZDIDM3NzYgc2F5cyB0aGlzOg0KDQogICBvICBFU1AgZW5j YXBzdWxhdGlvbiBvZiB0aGUgSG9tZSBUZXN0IEluaXQgYW5kIEhvbWUgVGVzdCBtZXNzYWdlcw0K ICAgICAgdHVubmVsZWQgYmV0d2VlbiB0aGUgbW9iaWxlIG5vZGUgYW5kIGhvbWUgYWdlbnQgTVVT VCBiZSBzdXBwb3J0ZWQNCiAgICAgIGFuZCBTSE9VTEQgYmUgdXNlZC4NCg0KICAgbyAgRVNQIGVu Y2Fwc3VsYXRpb24gb2YgdGhlIElDTVB2NiBtZXNzYWdlcyByZWxhdGVkIHRvIHByZWZpeA0KICAg ICAgZGlzY292ZXJ5IE1VU1QgYmUgc3VwcG9ydGVkIGFuZCBTSE9VTEQgYmUgdXNlZC4NCg0KICAg byAgRVNQIGVuY2Fwc3VsYXRpb24gb2YgdGhlIHBheWxvYWQgcGFja2V0cyB0dW5uZWxlZCBiZXR3 ZWVuIHRoZQ0KICAgICAgbW9iaWxlIG5vZGUgYW5kIGhvbWUgYWdlbnQgTUFZIGJlIHN1cHBvcnRl ZCBhbmQgdXNlZC4NCg0KQnV0IHRoaXMgaXNuJ3QgZW5vdWdoIHRvIGd1YXJhbnRlZSBpbnRlcm9w ZXJhYmlsaXR5LiBBbiBpbXBsZW1lbnRhdGlvbiB0aGF0DQpvbmx5IHN1cHBvcnRzIChhKSBpcyBj b25mb3JtaW5nLCBidXQgc28gaXMgYW4gaW1wbGVtZW50YXRpb24gdGhhdCBvbmx5IHN1cHBvcnRz DQooYyksIGFuZCB0aGUgdHdvIGRvbid0IGludGVyb3BlcmF0ZS4NCg0KRm9yIGV4YW1wbGUsIFJG QyAzNzc1IGRvZXMgbm90IHNheSB0aGF0IElQLWluLUlQIGVuY2Fwc3VsYXRpb24gb2YgcGF5bG9h ZA0KcGFja2V0cyBNVVNUIGJlIGltcGxlbWVudGVkLiBTaG91bGQgaXQ/DQoNCg0KUkZDIDM3NzUg aXNuJ3QgdmVyeSBjbGVhciBvbiB3aGV0aGVyIHlvdSBzaG91bGQgaW1wbGVtZW50IChiKSBvciAo YykgaWYgeW91DQpzdXBwb3J0IEVTUCBlbmNhcHN1bGF0aW9uIG9mIHBheWxvYWQgcGFja2V0cy4g UGFydCBvZiB0aGUgcHJvYmxlbSBpcyB0aGF0DQp0aGUgSVBTZWMgc2VjdXJpdHkgcG9saWN5IGRh dGFiYXNlIGlzIGFuIG9yZGVyZWQgbGlzdCwgYnV0IFJGQyAzNzc1IGRvZXNuJ3QNCnNheSB3aGF0 IG9yZGVyIHRoZSBydWxlcyBhcmUgaW4uIERvZXMgdGhlIHJ1bGUgaW4gc2VjdGlvbiA1LjIuNCBo YXZlIGhpZ2hlcg0KcHJpb3JpdHkgdGhhbiB0aGUgcnVsZSBpbiBzZWN0aW9uIDUuMi4yIChpbiB3 aGljaCBjYXNlIHdlIGhhdmUgb3B0aW9uIGIpIG9yDQppcyBpdCB0aGUgb3RoZXIgd2F5IHJvdW5k IChpbiB3aGljaCBjYXNlIHdlIGhhdmUgb3B0aW9uIGMpPw0KDQpUaGUgcnVsZXMgYXJlOg0KDQog ICAgIGhvbWUgYWdlbnQgU1BEIE9VVDoNCiAgICAgICAtIElGIGludGVyZmFjZSA9IElQdjYgdHVu bmVsIHRvIGhvbWVfYWRkcmVzc18xICYNCiAgICAgICAgICAgIHNvdXJjZSA9IGFueSAmIGRlc3Rp bmF0aW9uID0gaG9tZV9hZGRyZXNzXzEgJg0KICAgICAgICAgICAgcHJvdG8gPSBNSA0KICAgICAg ICAgVEhFTiBVU0UgU0EgU0E0DQoNCiAgICAgaG9tZSBhZ2VudCBTUEQgT1VUOg0KICAgICAgIC0g SUYgaW50ZXJmYWNlID0gSVB2NiB0dW5uZWwgdG8gaG9tZV9hZGRyZXNzXzEgJg0KICAgICAgICAg ICAgc291cmNlID0gYW55ICYgZGVzdGluYXRpb24gPSBob21lX2FkZHJlc3NfMSAmDQogICAgICAg ICAgICBwcm90byA9IFgNCiAgICAgICAgIFRIRU4gVVNFIFNBIFNBOA0KDQpTdXBwb3NlIGhhdmUg ImludGVyZmFjZSA9IElQdjYgdHVubmVsIHRvIGhvbWVfYWRkcmVzc18xIiwgc291cmNlID0gYW55 LA0KZGVzdGluYXRpb24gPSBob21lX2FkZHJlc3NfMSBhbmQgcHJvdG8gPSBNSC4gQm90aCBydWxl cyBtYXRjaC4gRG8gd2UNCnVzZSBTQTQgb3IgU0E4Pw0KDQpTb21lIHByYWN0aWNhbCBjb25zaWRl cmF0aW9uczoNCjEpIEZvciBwZXJmb3JtYW5jZSByZWFzb25zLCBzb21lIHBlb3BsZSBtaWdodCB3 YW50IHRvIHVzZSBkaWZmZXJlbnQgY3J5cHRvDQp0cmFuc2Zvcm1zIGZvciBTQTMvNCBhbmQgU0E3 LzgsIGUuZy4gYXV0aGVudGljYXRpb24tb25seSBmb3IgU0E3LzguDQoNCjIpIFRoZSBtb3JlIFNQ RCBlbnRyaWVzIHdlIGhhdmUsIHRoZSBsb25nZXIgaXQgdGFrZXMgdG8gY29uZmlndXJlIE1JUHY2 Og0KICAgdGhlcmUgYXJlIG1vcmUgU1BJIHZhbHVlcyBhbmQgY3J5cHRvIGtleXMgdG8gZW50ZXIg bWFudWFsbHkuIEZyb20gYQ0KICAgdXNhYmlsaXR5IHBvaW50IG9mIHZpZXcsIDYgc2VjdXJpdHkg YXNzb2NpYXRpb25zIGFyZSBxdWlja2VyIHRvIGNvbmZpZ3VyZQ0KICAgdGhhbiA4Lg0KDQozKSBU aGUgImludGVyZmFjZSA9IElQdjYgdHVubmVsIHRvIGhvbWVfYWRkcmVzc18xIiBidXNpbmVzcyBn aXZlcyByaXNlIHRvDQogICBpbXBsZW1lbnRhdGlvbiBwcm9ibGVtcyB0aGF0IHdvdWxkIG1ha2Ug aXQgbm9uLXRyaXZpYWwgZm9yIHVzIHRvIHN1cHBvcnQNCiAgIGJvdGggKGIpIGFuZCAoYykuDQoN Ck1pa2UNCg0KDQoNCg== --===============1756555754== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1756555754==-- From mip6-bounces@ietf.org Mon Oct 25 12:52:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13307 for ; Mon, 25 Oct 2004 12:52:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM8IK-0002im-8j for mip6-web-archive@ietf.org; Mon, 25 Oct 2004 13:06:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM7pD-00073E-FS; Mon, 25 Oct 2004 12:36:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM7mf-0006W1-5h for mip6@megatron.ietf.org; Mon, 25 Oct 2004 12:33:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12106 for ; Mon, 25 Oct 2004 12:33:22 -0400 (EDT) Received: from dns2.tilab.com ([163.162.42.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM7zx-0002LC-T2 for mip6@ietf.org; Mon, 25 Oct 2004 12:47:21 -0400 Received: from iowa2k01b.cselt.it ([163.162.242.202]) by dns2.cselt.it (PMDF V6.1 #38895) with ESMTP id <0I6500L3GEVQBE@dns2.cselt.it> for mip6@ietf.org; Mon, 25 Oct 2004 18:23:50 +0200 (MEST) Received: from EXC01B.cselt.it ([163.162.4.199]) by iowa2k01b.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Mon, 25 Oct 2004 18:29:41 +0200 Date: Mon, 25 Oct 2004 18:31:51 +0200 From: Giaretta Gerardo Subject: RE: [Mip6] Review of draft-giaretta-mip6-authorization-eap-02.txt To: James Kempf Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: [Mip6] Review of draft-giaretta-mip6-authorization-eap-02.txt thread-index: AcS4lqbjS/PQJiegQ5e5q1HL7x/wOACGSEtQ Content-Class: urn:content-classes:message X-OriginalArrivalTime: 25 Oct 2004 16:29:41.0937 (UTC) FILETIME=[D4700210:01C4BAAF] X-Spam-Score: 0.0 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c Content-Transfer-Encoding: quoted-printable Hi James, thank you very much for reviewing the draft. See my comments below.. > This draft-giaretta proposes a solution for the dynamic bootstrapping > problem that works for IASPs. It is not a solution for WISPs and other > scenarios where the MSP is separate from the ASP. >=20 > I think this version of the draft is a considerable=20 > improvement over the > previous version. I believe it is a candidate for a WG draft for one > solution (not *the* solution) to the dynamic bootstrapping=20 > problem, that > works for IASPs. >=20 > Working group chairs: can we have a concensus call in DC=20 > after the draft is > presented about whether the draft should be made a WG draft? >=20 > I have a few specific comments on the draft. >=20 > General editorial comment: In many cases, the authors have=20 > parenthetical > comments about possible protocols or mechanisms to achieve=20 > some kind of > result, for example, Section 3, Step 6: >=20 > ...the MN gains network access and aquires a valid Care-of=20 > Address within > the visited subnet (e.g. via > stateless autoconfiguration). >=20 > In most cases, the mechanisms cited in the parenthetical=20 > comments are not > exhaustive, but only examplary. While reading the draft, I=20 > was constantly > noting other mechanisms that were missing and could be used.=20 > I think it > would be best to either drop these parenthetical comments or=20 > include an > exhaustive list. Otherwise, readers may think only the listed=20 > mechanisms > apply. >=20 In most cases our intention was to give only some possible examples to accomplish a particular task (the configuration of the Care-of Address in the case you mentioned). However, if you think it is better to have a complete list, we could provide it in the next version, wherever it is possible. > Section 1, paragraph 1: This is a mischaracterization of the dynamic > bootstrapping problem. The problem is not that there is no=20 > way in RFC 3775 > to autoconfigure the HA addr and HoA addr. The problem is=20 > that it is not > possible to do that and, at the same time, dynamically=20 > configure the IPsec > SAs with the home agent. It is also not possible to configure=20 > the HA addr > and the HoA addr independently from statically configuring=20 > some topology > information on the MN. >=20 I see. We'll rephrase it in the next version.=20 > Section 1, paragraph 4: The draft at this point lacks=20 > sufficient clarity > about how a roaming MN would be configured with a dynamically=20 > assigned home > agent in the foreign network. I believe that should be=20 > mentioned, unless it > is a goal of the authors to eventually encompass this=20 > scenario in the draft. >=20 The allocation of the HA in the foreign network is an open issue in our I-D.=20 We tried to provide a solution in version 00. The basic idea was as follows: - in the EAP exchange the MN asks for a HA in the foreign domain - AAAH gets in touch with AAAF via AAA protocol - AAAF selects a Home Agent and communicates its address to AAAH - AAAH forwards this information to the MN through EAP We decided to remove this description because it is related to the AAA-HA interface and does not affect the communication between MN and AAA (that is the scope of this draft). Do you think there are alternative solutions that affect the MN-AAA interface and should therefore be described in the draft? > Figure 2: Is the link between the MN and "AAA Client"=20 > (presumably NAS or > AAA-F) limited to 802.1x and PANA? I think not. Other Layer=20 > 2.5 protocols > might be used for other Layer 2, for example, 802.16 does not=20 > use 802.1x for > auth but does use EAP. >=20 I agree that figure 2 is misleading and too restrictive. Maybe "EAP lower layer" in place of "802.1X or PANA" would sound better. > Section 3, Step 4: The authors have a companion draft for deriving an > application master key, wouldn't it be appropriate to cite=20 > that draft at the > end of this paragraph? >=20 Agreed > Section 4: I think this section should be moved to an appendix. It is > necessary and quite relevant, but not to the specification of=20 > the protocol. >=20 Agreed. > Section 5, paragraph 21: I'm not really sure the AAA server should be > responsible for load balancing MNs among HAs. Some people in=20 > IETF feel that > even using EAP to distribute MIP bootstrapping information=20 > isn't such a good > idea. From the standpoint of the EAP protocol extensions=20 > described in this > document, it doesn't matter. I'd suggest dropping this from=20 > the text, as it > is rather something for the back end protocol between the HA and AAA-H > server. >=20 Agreed that it is related to AAA-HA interface. I'll drop this in the next version. > Section 8.3: I would like a flag here indicating to the MN=20 > that it should > derive its HoA from IKEv2. >=20 This could be an interesting extension.=20 BTW, do you think we need in the MN-AAA interface a mechanism to negotiate the IKE version to be used between MN and HA? > Section 8.8 and 8.9: Could these two options be combined? I=20 > don't see any > case where a message from the server would come with one and=20 > not the other. >=20 If the negotiation fails, there will not be the Authorization-Lifetime-AVP.=20 So it may be better not to combine the two options. What do you think? Regards, --Gerardo > jak >=20 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Oct 25 12:54:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13413 for ; Mon, 25 Oct 2004 12:54:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM8KE-0002ka-3S for mip6-web-archive@ietf.org; Mon, 25 Oct 2004 13:08:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM7pG-00074n-8F; Mon, 25 Oct 2004 12:36:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM7nm-0006lS-13 for mip6@megatron.ietf.org; Mon, 25 Oct 2004 12:34:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12202 for ; Mon, 25 Oct 2004 12:34:30 -0400 (EDT) Received: from dns2.tilab.com ([163.162.42.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM81F-0002NH-SL for mip6@ietf.org; Mon, 25 Oct 2004 12:48:30 -0400 Received: from iowa2k01b.cselt.it ([163.162.242.202]) by dns2.cselt.it (PMDF V6.1 #38895) with ESMTP id <0I6500K8DEXZYO@dns2.cselt.it> for mip6@ietf.org; Mon, 25 Oct 2004 18:25:11 +0200 (MEST) Received: from EXC01B.cselt.it ([163.162.4.199]) by iowa2k01b.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Mon, 25 Oct 2004 18:31:02 +0200 Date: Mon, 25 Oct 2004 18:33:11 +0200 From: Giaretta Gerardo Subject: RE: [Mip6] Review of draft-giaretta-mip6-authorization-eap-02.txt To: Francis Dupont , James Kempf Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: [Mip6] Review of draft-giaretta-mip6-authorization-eap-02.txt thread-index: AcS5AHCstDmVws/rTB2w21pbrOOYAABr2sHA Content-Class: urn:content-classes:message X-OriginalArrivalTime: 25 Oct 2004 16:31:02.0578 (UTC) FILETIME=[0480D920:01C4BAB0] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable >=20 > PS: it should be fine to collect implementation reports too (note this > remark should apply to all WG (relative) documents, including RFC 3775 > and 3776). >=20 I'd like just to mention that we have an implementation of our draft based on open source software (Open1x, FreeRadius, MIPL). --Gerardo > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Oct 25 13:14:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14926 for ; Mon, 25 Oct 2004 13:14:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM8dj-0003AN-Ub for mip6-web-archive@ietf.org; Mon, 25 Oct 2004 13:28:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM8Jl-00058W-22; Mon, 25 Oct 2004 13:07:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM8AH-0003yq-Ro for mip6@megatron.ietf.org; Mon, 25 Oct 2004 12:57:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13692 for ; Mon, 25 Oct 2004 12:57:46 -0400 (EDT) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM8Nl-0002p6-Jv for mip6@ietf.org; Mon, 25 Oct 2004 13:11:46 -0400 Message-ID: <012c01c4bab3$de4606a0$656115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Giaretta Gerardo" References: Subject: Re: [Mip6] Review of draft-giaretta-mip6-authorization-eap-02.txt Date: Mon, 25 Oct 2004 09:58:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit >The allocation of the HA in the foreign network is an open issue in our >I-D. >We tried to provide a solution in version 00. The basic idea was as >follows: >- in the EAP exchange the MN asks for a HA in the foreign domain >- AAAH gets in touch with AAAF via AAA protocol >- AAAF selects a Home Agent and communicates its address to AAAH >- AAAH forwards this information to the MN through EAP > >We decided to remove this description because it is related to the >AAA-HA interface and does not affect the communication between MN and >AAA (that is the scope of this draft). > >Do you think there are alternative solutions that affect the MN-AAA >interface and should therefore be described in the draft? I think this should be dealt with in a separate draft, specifically targeted at dynamic assignment of an HA in the foreign network. There is another alternative, namely that AAAH tells MN to use DHCP to find the HA locally, rather than finding it indirectly via AAA to AAAF. If there's a tight trust relationship between the home and foreign service providers, this procedure might be faster. >I agree that figure 2 is misleading and too restrictive. Maybe "EAP >lower layer" in place of "802.1X or PANA" would sound better. Yes. > Section 8.3: I would like a flag here indicating to the MN > that it should > derive its HoA from IKEv2. > >This could be an interesting extension. > >BTW, do you think we need in the MN-AAA interface a mechanism to >negotiate the IKE version to be used between MN and HA? Hmm, not sure. What does IKE itself provide? If there's adequate support in IKE for version handling, then I think it isn't necessary. On the other hand, the HA might support both and might want to control which one is used by specific kinds of MNs. BTW, I believe many IKEv1 implementations also provide address assignment, though it is not part of the base specification. So just telling the MN to use IKE address assignment probably isn't enough to determine whether IKEv1 or IKEv2 is used. >If the negotiation fails, there will not be the >Authorization-Lifetime-AVP. >So it may be better not to combine the two options. What do you think? If the negotiation fails, then presumably there will be a Status option indicating that, and the lifetime can be set to zero. Combining the two avoids the overhead of an additional type and length. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Oct 25 18:50:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06012 for ; Mon, 25 Oct 2004 18:50:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMDta-0000HA-2h for mip6-web-archive@ietf.org; Mon, 25 Oct 2004 19:04:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMBTq-0003gm-Fm; Mon, 25 Oct 2004 16:30:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMB4r-0006FE-El for mip6@megatron.ietf.org; Mon, 25 Oct 2004 16:04:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29454 for ; Mon, 25 Oct 2004 16:04:23 -0400 (EDT) From: Franck.Le@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMBIM-0006OR-Vi for mip6@ietf.org; Mon, 25 Oct 2004 16:18:23 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9PK4K303300; Mon, 25 Oct 2004 23:04:22 +0300 (EET DST) X-Scanned: Mon, 25 Oct 2004 23:03:03 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i9PK338V026946; Mon, 25 Oct 2004 23:03:03 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00TbWLer; Mon, 25 Oct 2004 23:03:01 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9PK2ra01545; Mon, 25 Oct 2004 23:02:53 +0300 (EET DST) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 25 Oct 2004 15:02:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Review of draft-ietf-mip6-firewalls-00.txt (with referenceto draft-chen-mip6-gprs-02.txt) Date: Mon, 25 Oct 2004 15:02:16 -0500 Message-ID: <57A26D272F67A743952F6B4371B8F811017CA9BD@daebe007.americas.nokia.com> Thread-Topic: [Mip6] Review of draft-ietf-mip6-firewalls-00.txt (with referenceto draft-chen-mip6-gprs-02.txt) Thread-Index: AcS4kHiDtK3VvqSHTliOwcXO3LvzhgCOjMnQ To: , X-OriginalArrivalTime: 25 Oct 2004 20:02:16.0504 (UTC) FILETIME=[86C07B80:01C4BACD] X-Spam-Score: 0.3 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: quoted-printable X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Content-Transfer-Encoding: quoted-printable Hello James, Thank you for your suggestions. Please find some comments below, > One way this draft could be made more readable is to organize=20 > it more like > draft-chen, including all the cases of placement of the MN,=20 > HA, and CN. The > current draft-ietf-mip6-firewalls has specific sections in=20 > 3.1, where the MN > is outside and stays outside, and 3.2 in which the MN is=20 > inside and stays > inside. Even for those cases the discussion is made somewhat=20 > vague by lack > of specific description of the addresses involved and what state is > established (or not) in the firewall when, something that=20 > draft-chen does > very well. However, in draft-ietf-mip6-firewalls the=20 > discussion of the more > complex case when an MN moves from outside a firewall to=20 > inside is somewhat > muddied and vague in Section 3.2.2. This case is especially=20 > in need of very > explict consideration of addresses and firewall state, and very clear > explanation of the problem. For the description of the problem (e.g. mismatch between the firewall = states and incoming packets), we tried to explicitely describe them. As = an example, to quote section 3.1.1: "The state created by the stateful = inspection packet filter protecting A is therefore initially based on = the IP address of A(IP A) and the home address of the node B (IP HoA = B)." then "The Care of Test Init message is sent using the new CoA of B = as the source address. Such a packet does not match any entry in the = firewall protecting A and as described in Section 2, the CoTi message = will thus be dropped by the firewall." If you want to make it clearer, would you have any suggestion? For the other scenarios you pointed out, I agree with you. They are not = in the scope of the document. We described some of the issues, and = specifically focused on the basic ones. I will add an explicit statement = in the document to explain that the scenarios you mentioned are not = included. =20 > Specific comments: >=20 > Section 3.2.2, starting about Paragraph 3: the description of=20 > why packets > forwarded between the HA and MN might get dropped is not very=20 > clear. The > problem seems to be that when a MN roams into an area of=20 > network topology > controlled by a stateful firewall, there is no state in the firewall > corresponding to (HA src addr, MN CoA dest addr). But this is never > specifically articulated. Thank you for your comment. I will try to make it clearer in the next = version of the document. > Section 3.2.2, Paragraph 8: This point is true for any case=20 > where a session > is initiated from outside the firewall, for example, an=20 > incoming VoIP call > started by SIP. Why is MIPv6 any different? Sorry if that section is not clear. MIPv6 is not different. What we = wanted to say is that while MIPv6 has been designed to allow = reachability even when the MN roams (thanks to the HoA and HA), = firewalls may present issues to this property. I will try to clarify our = intent in this section. > Section 3.2.2, Paragraph 10: The discussion doesn't consider=20 > the distinction > between a TCP and UDP session. Earlier in the text, the=20 > description of the > state maintained in the firewall implies a distinction. But=20 > if a MIPv6 host > is receiving TCP packets tunneled from the HA, then the=20 > firewall state will > be for UDP (presuming it is set up at all). The firewall=20 > timers for UDP may > interact negatively with the MN's TCP timeouts, and there may be other > problems. Can you please clarify what you mean? > Section 3.2.3, Paragraph 5: This paragraph is not only true=20 > of RR packets > but also of BU packets if the MN chooses to use ESP=20 > encryption for them as > well. Consequently, it should be discussed in a separate section not > specifically devoted to RR. The problem with IPsec is described in section 3.2.1. We can add a = reference. > Section 3.2.3, Paragraph 7: This paragraph is implying that=20 > the problem may > be due to the lack of ability to detect firewalls. IPsec can=20 > deal with NATs > because they can be detected. Why not simply come out and say=20 > this? Having > the ability to detect and negotiate with a firewall is=20 > something that the > IETF has (in my opinion) been needing for some time, and MIP=20 > only makes the > case stronger. The ability to detect firewalls could help to solve the issue. We will = mention it in the next version of the draft. > In summary, I believe this draft needs a lot of work before=20 > it is ready to > be sent to the IESG. I'd suggest the authors may want to talk=20 > to the authors > of draft-chen about merging the two. We are aware of the draft-chen but draft-ietf-mip6-firewalls is more = generic and applicable to firewalls in general. Xiabao's I-D is focused = on GPRS aspects. Thanking you again for your comments, Franck _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Oct 25 18:53:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06754 for ; Mon, 25 Oct 2004 18:53:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMDw5-0000Vk-8j for mip6-web-archive@ietf.org; Mon, 25 Oct 2004 19:07:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMBTy-0003pH-6s; Mon, 25 Oct 2004 16:30:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMB5Y-0006fm-GW; Mon, 25 Oct 2004 16:05:08 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29564; Mon, 25 Oct 2004 16:05:06 -0400 (EDT) Message-Id: <200410252005.QAA29564@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 25 Oct 2004 16:05:06 -0400 Cc: mip6@ietf.org Subject: [Mip6] I-D ACTION:draft-ietf-mip6-mipv6-mib-05.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv6 Working Group of the IETF. Title : Mobile IPv6 Management Information Base Author(s) : G. Keeni, et al. Filename : draft-ietf-mip6-mipv6-mib-05.txt Pages : 109 Date : 2004-10-25 This memo defines a portion of the Management Information Base (MIB), the Mobile-IPv6 MIB , for use with network management protocols in the Internet community. In particular, the Mobile-IPv6 MIB will be used to monitor and control the mobile node, home agent and correspondent node functions of a Mobile IPv6 (MIPv6) entity. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-mipv6-mib-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mip6-mipv6-mib-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip6-mipv6-mib-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-25162150.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-mipv6-mib-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-mipv6-mib-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-25162150.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --NextPart-- From mip6-bounces@ietf.org Mon Oct 25 20:12:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22842 for ; Mon, 25 Oct 2004 20:12:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMFAE-0005MR-Pd for mip6-web-archive@ietf.org; Mon, 25 Oct 2004 20:26:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMEZe-0007KB-Eu; Mon, 25 Oct 2004 19:48:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CME8f-0007s2-30; Mon, 25 Oct 2004 19:20:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12843; Mon, 25 Oct 2004 19:20:29 -0400 (EDT) Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMEM9-0002QA-LJ; Mon, 25 Oct 2004 19:34:32 -0400 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 25 Oct 2004 19:19:58 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Date: Mon, 25 Oct 2004 19:19:58 -0400 Message-ID: Thread-Topic: MIP and transition issues Thread-Index: AcS66R10DpafzyueS8WJQO1BVKyGow== From: "Soliman, Hesham" To: , , , X-OriginalArrivalTime: 25 Oct 2004 23:19:58.0275 (UTC) FILETIME=[24EB1930:01C4BAE9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable Cc: Tsirtsis George Subject: [Mip6] MIP and transition issues X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Folks,=20 Sorry for the cross posting, but this issue is being discussed in all WG listed.=20 I submitted the following two drafts last night: draft-tsirtsis-dsmip-problem draft-soliman-v4v6-mipv6- The first deals with the problem statement and the=20 second is one of the solution for using MIPv6 only. There is another draft that proposes using MIPv4 only: draft-tsirtsis-v4v6-mipv4 I hope we can discuss the problem statement and scenarios=20 in the next meeting. While the problem statement is on the mip6 charter, it would be useful if we can have a slot allocated for=20 this in v6ops.=20 thx Hesham =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review or distribution by others is = strictly prohibited. If you are not the intended recipient please contact the = sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Oct 26 12:35:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21027 for ; Tue, 26 Oct 2004 12:35:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMUWR-000707-AJ for mip6-web-archive@ietf.org; Tue, 26 Oct 2004 12:50:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMUH4-0000s7-Ur; Tue, 26 Oct 2004 12:34:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMUFJ-0000RR-M3 for mip6@megatron.ietf.org; Tue, 26 Oct 2004 12:32:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20721 for ; Tue, 26 Oct 2004 12:32:27 -0400 (EDT) Received: from dns2.tilab.com ([163.162.42.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMUSq-0006uo-CD for mip6@ietf.org; Tue, 26 Oct 2004 12:46:39 -0400 Received: from iowa2k01b.cselt.it ([163.162.242.202]) by dns2.cselt.it (PMDF V6.1 #38895) with ESMTP id <0I6700J619I8WJ@dns2.cselt.it> for mip6@ietf.org; Tue, 26 Oct 2004 18:22:56 +0200 (MEST) Received: from EXC01B.cselt.it ([163.162.4.199]) by iowa2k01b.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Tue, 26 Oct 2004 18:28:49 +0200 Date: Tue, 26 Oct 2004 18:30:57 +0200 From: Giaretta Gerardo Subject: RE: [Mip6] Review of draft-giaretta-mip6-authorization-eap-02.txt To: James Kempf Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: [Mip6] Review of draft-giaretta-mip6-authorization-eap-02.txt thread-index: AcS6s7I5ya+Ucwg6RY6lZWKl7k63HwAwxwrA Content-Class: urn:content-classes:message X-OriginalArrivalTime: 26 Oct 2004 16:28:49.0093 (UTC) FILETIME=[DF5A6750:01C4BB78] X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Content-Transfer-Encoding: quoted-printable > >The allocation of the HA in the foreign network is an open=20 > issue in our > >I-D. > >We tried to provide a solution in version 00. The basic idea was as > >follows: > >- in the EAP exchange the MN asks for a HA in the foreign domain > >- AAAH gets in touch with AAAF via AAA protocol > >- AAAF selects a Home Agent and communicates its address to AAAH > >- AAAH forwards this information to the MN through EAP > > > >We decided to remove this description because it is related to the > >AAA-HA interface and does not affect the communication between MN and > >AAA (that is the scope of this draft). > > > >Do you think there are alternative solutions that affect the MN-AAA > >interface and should therefore be described in the draft? >=20 > I think this should be dealt with in a separate draft,=20 > specifically targeted > at dynamic assignment of an HA in the foreign network. There=20 > is another > alternative, namely that AAAH tells MN to use DHCP to find=20 > the HA locally, > rather than finding it indirectly via AAA to AAAF. If there's=20 > a tight trust > relationship between the home and foreign service providers,=20 > this procedure > might be faster. >=20 I think that this approach would be very useful if the IPsec SA can be bootstrapped using certs (i.e. there is a certification path between the MN and the HA of the foreign domain). In case pre-shared key authentication is used, who is going to generate the PSK and deliver it to MN and HA? >=20 > > Section 8.3: I would like a flag here indicating to the MN > > that it should > > derive its HoA from IKEv2. > > >=20 > >This could be an interesting extension. > > > >BTW, do you think we need in the MN-AAA interface a mechanism to > >negotiate the IKE version to be used between MN and HA? >=20 > Hmm, not sure. What does IKE itself provide? If there's=20 > adequate support in > IKE for version handling, then I think it isn't necessary. On=20 > the other > hand, the HA might support both and might want to control=20 > which one is used > by specific kinds of MNs. >=20 > BTW, I believe many IKEv1 implementations also provide=20 > address assignment, > though it is not part of the base specification. So just=20 > telling the MN to > use IKE address assignment probably isn't enough to determine=20 > whether IKEv1 > or IKEv2 is used. >=20 This is what I had in mind: does the AAAH need to know if a specific MN supports IKEv1 or IKEv2 or both? Consider a scenario where some HAs support only IKEv1 and some others support IKEv2. In this situation, in order to allocate an appropriate HA, the AAAH must know during the MIPv6 bootstrapping negotiation which version of IKE the MN supports. Do you think this is a meaningful scenario? > >If the negotiation fails, there will not be the > >Authorization-Lifetime-AVP. > >So it may be better not to combine the two options. What do=20 > you think? >=20 > If the negotiation fails, then presumably there will be a=20 > Status option > indicating that, and the lifetime can be set to zero.=20 > Combining the two > avoids the overhead of an additional type and length. >=20 Ok, I get your point. Maybe the termination of the negotiation procedure can be improved. A possible change could be: - leave the Negotiation-Result-TLV as is for the communication from the MN to the AAAH. This TLV is used by the MN to tell the AAAH whether it accepts or not the proposed configuration. - change the format (and maybe also the name) of the Authorization-Lifetime-TLV in a way that it includes a Status field. This is used in the communication from the AAAH to the MN. Regards, --Gerardo > jak >=20 >=20 >=20 Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Oct 26 13:30:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26667 for ; Tue, 26 Oct 2004 13:30:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMVNJ-0000GQ-77 for mip6-web-archive@ietf.org; Tue, 26 Oct 2004 13:44:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMUuH-0004tQ-FN; Tue, 26 Oct 2004 13:14:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMUlH-0001kZ-3P for mip6@megatron.ietf.org; Tue, 26 Oct 2004 13:05:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23501 for ; Tue, 26 Oct 2004 13:05:27 -0400 (EDT) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMUyx-0007k0-Li for mip6@ietf.org; Tue, 26 Oct 2004 13:19:40 -0400 Message-ID: <010301c4bb7e$1e0edb20$656115ac@dcml.docomolabsusa.com> From: "James Kempf" To: , References: <57A26D272F67A743952F6B4371B8F811017CA9BD@daebe007.americas.nokia.com> Subject: Re: [Mip6] Review of draft-ietf-mip6-firewalls-00.txt (with referenceto draft-chen-mip6-gprs-02.txt) Date: Tue, 26 Oct 2004 10:06:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: 7bit X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: 7bit Franck, Some responses. For the description of the problem (e.g. mismatch between the firewall states and incoming packets), we tried to explicitely describe them. As an example, to quote section 3.1.1: "The state created by the stateful inspection packet filter protecting A is therefore initially based on the IP address of A(IP A) and the home address of the node B (IP HoA B)." then "The Care of Test Init message is sent using the new CoA of B as the source address. Such a packet does not match any entry in the firewall protecting A and as described in Section 2, the CoTi message will thus be dropped by the firewall." If you want to make it clearer, would you have any suggestion? jak>> Draft-chen takes each individual case and examines it in detail. For example, Section 4.1.1.1: The IP datagrams sent from A to B use the (reverse) tunnel from A's current CoA to its HA. IP datagrams exit the tunnel at A's home agent and transmit to B using A's home address as the source address. Upon arriving at the GGSN, the IP datagrams' source address matches the IPv6 source address (A's home address) recorded in one of the TFT filters and, if other filtering parameters are matched as well, the IP datagrams will be delivered to B through the PDP Context corresponding to the TFT. No specific issues are identified for this case. This only applies to the Home Agent tunneling case when the MN is under the GGSN and the HA and CN are outside. Draft-ietf-mip6-firewalls segues from the text you've cited above from Section 3.1.1 which is a relatively precise description of a single case into a more vaguely worded description of the problem involving route optimization. I think it would be more helpful for readers to understand the problem if each case (MN inside behind firewall and HA outside, MN outside and HA inside, etc.) were analyzed individually to the same level of detail as in draft-chen and Section 3.1.1. jak>>>(end) For the other scenarios you pointed out, I agree with you. They are not in the scope of the document. We described some of the issues, and specifically focused on the basic ones. I will add an explicit statement in the document to explain that the scenarios you mentioned are not included. jak>>> I'm not clear what you mean. Is this document intended to be a comprehensive exploration of the problems involved in firewall interaction with MIPv6 or not? If not, then we clearly need another document that explores the problems this one doesn't. > Section 3.2.2, Paragraph 10: The discussion doesn't consider > the distinction > between a TCP and UDP session. Earlier in the text, the > description of the > state maintained in the firewall implies a distinction. But > if a MIPv6 host > is receiving TCP packets tunneled from the HA, then the > firewall state will > be for UDP (presuming it is set up at all). The firewall > timers for UDP may > interact negatively with the MN's TCP timeouts, and there may be other > problems. Can you please clarify what you mean? jak>>> Sorry, I wasn't thinking clearly here. Obviously, the firewall will step over the IP packet header and set up the proper state for TCP. There's only an issue if a UDP tunnel is used, such as would be the case for IPsec, and even in that case, it's not clear how serious the problem would be. jak>>>(end) jak>> Hope that helps. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Oct 26 13:42:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27781 for ; Tue, 26 Oct 2004 13:42:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMVYV-0000YJ-BA for mip6-web-archive@ietf.org; Tue, 26 Oct 2004 13:56:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMVHb-0003qY-9B; Tue, 26 Oct 2004 13:38:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMVDB-0002Kz-SC for mip6@megatron.ietf.org; Tue, 26 Oct 2004 13:34:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27098 for ; Tue, 26 Oct 2004 13:34:18 -0400 (EDT) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMVQt-0000O2-0R for mip6@ietf.org; Tue, 26 Oct 2004 13:48:31 -0400 Message-ID: <011c01c4bb82$266607e0$656115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Giaretta Gerardo" References: Subject: Re: [Mip6] Review of draft-giaretta-mip6-authorization-eap-02.txt Date: Tue, 26 Oct 2004 10:35:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: 7bit I think that this approach would be very useful if the IPsec SA can be bootstrapped using certs (i.e. there is a certification path between the MN and the HA of the foreign domain). In case pre-shared key authentication is used, who is going to generate the PSK and deliver it to MN and HA? jak>>> Agree certs are the most likely candidate, but the AAA-H could push a preshared key to the AAA-F. This is less secure than using certs w. DH however, and probably to be discouraged. If it is used at all, the AAA-H would probably derive a key from the preshared key and push that, and the MN would probably use the same kind of derivation. The kind of situation I would expect this to be used is when the network operator has a bunch of subsidiaries that run their own AAA servers for distributed processing rather than centralizing everything. I think it would be less useful between operators, since there's more risk of compromise. > > > Section 8.3: I would like a flag here indicating to the MN > > that it should > > derive its HoA from IKEv2. > > > > >This could be an interesting extension. > > > >BTW, do you think we need in the MN-AAA interface a mechanism to > >negotiate the IKE version to be used between MN and HA? > > Hmm, not sure. What does IKE itself provide? If there's > adequate support in > IKE for version handling, then I think it isn't necessary. On > the other > hand, the HA might support both and might want to control > which one is used > by specific kinds of MNs. > > BTW, I believe many IKEv1 implementations also provide > address assignment, > though it is not part of the base specification. So just > telling the MN to > use IKE address assignment probably isn't enough to determine > whether IKEv1 > or IKEv2 is used. > This is what I had in mind: does the AAAH need to know if a specific MN supports IKEv1 or IKEv2 or both? Consider a scenario where some HAs support only IKEv1 and some others support IKEv2. In this situation, in order to allocate an appropriate HA, the AAAH must know during the MIPv6 bootstrapping negotiation which version of IKE the MN supports. Do you think this is a meaningful scenario? jak>>> Yes, it might occur. But if IKE provides adequate handling of versions, I don't see that anything would be needed in the EAP exchange. For the EAP exchange to indicate IKE address assignment if the HA supports IKEv1, however, the AAA server has to know if the IKEv1 implementation supports an unstandardized IKEv1 address assignment option. > >If the negotiation fails, there will not be the > >Authorization-Lifetime-AVP. > >So it may be better not to combine the two options. What do > you think? > > If the negotiation fails, then presumably there will be a > Status option > indicating that, and the lifetime can be set to zero. > Combining the two > avoids the overhead of an additional type and length. > Ok, I get your point. Maybe the termination of the negotiation procedure can be improved. A possible change could be: - leave the Negotiation-Result-TLV as is for the communication from the MN to the AAAH. This TLV is used by the MN to tell the AAAH whether it accepts or not the proposed configuration. - change the format (and maybe also the name) of the Authorization-Lifetime-TLV in a way that it includes a Status field. This is used in the communication from the AAAH to the MN. jak>>> OK, that would work. It was not clear to me from the document that the Negotiation-Result-TLV also originated at the MN. Is there a need for the MN to indicate a status? The protocol seems more like the AAA server pushing stuff to the MN, so it's kind of take it or leave it from the MN's view, unless I'm missing something. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Oct 26 16:04:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09739 for ; Tue, 26 Oct 2004 16:04:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMXmL-0003xV-Tg for mip6-web-archive@ietf.org; Tue, 26 Oct 2004 16:18:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMXN6-0002z9-PR; Tue, 26 Oct 2004 15:52:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMXLF-00026o-Fr for mip6@megatron.ietf.org; Tue, 26 Oct 2004 15:50:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08287 for ; Tue, 26 Oct 2004 15:50:47 -0400 (EDT) From: Franck.Le@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMXYw-0003cP-MV for mip6@ietf.org; Tue, 26 Oct 2004 16:05:00 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9QJofw14646; Tue, 26 Oct 2004 22:50:45 +0300 (EET DST) X-Scanned: Tue, 26 Oct 2004 22:48:34 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i9QJmYZA021536; Tue, 26 Oct 2004 22:48:34 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00m5gQQK; Tue, 26 Oct 2004 22:48:33 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9QJmVa20313; Tue, 26 Oct 2004 22:48:31 +0300 (EET DST) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 26 Oct 2004 14:48:18 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Review of draft-ietf-mip6-firewalls-00.txt (with referenceto draft-chen-mip6-gprs-02.txt) Date: Tue, 26 Oct 2004 14:48:18 -0500 Message-ID: <57A26D272F67A743952F6B4371B8F811017CA9C0@daebe007.americas.nokia.com> Thread-Topic: [Mip6] Review of draft-ietf-mip6-firewalls-00.txt (with referenceto draft-chen-mip6-gprs-02.txt) Thread-Index: AcS7fmyDJJ7eFdTSQDmVmt4jZlPL6QAFV5Tw To: , X-OriginalArrivalTime: 26 Oct 2004 19:48:18.0873 (UTC) FILETIME=[BDE5E290:01C4BB94] X-Spam-Score: 0.3 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: quoted-printable Hello James, Thank you for the clarifications. > If you want to make it clearer, would you have any suggestion? >=20 > jak>> Draft-chen takes each individual case and examines it=20 > in detail. For > example, Section 4.1.1.1: [...]=20 > I think it would be more helpful for readers to understand=20 > the problem if > each case (MN inside behind firewall and HA outside, MN outside and HA > inside, etc.) were analyzed individually to the same level of=20 > detail as in > draft-chen and Section 3.1.1. > jak>>>(end) Ok. In the next version of the draft, we will try to follow your = suggestion to make the description of the problem clearer. > For the other scenarios you pointed out, I agree with you.=20 > They are not in > the scope of the document. We described some of the issues,=20 > and specifically > focused on the basic ones. I will add an explicit statement=20 > in the document > to explain that the scenarios you mentioned are not included. >=20 > jak>>> I'm not clear what you mean. Is this document intended to be a > comprehensive exploration of the problems involved in=20 > firewall interaction > with MIPv6 or not? If not, then we clearly need another document that > explores the problems this one doesn't. The initial intent of the document was not to list all the possible = problems between the Mobile IPv6 protocol and firewalls, but to describe = the main ones. However we could include the scenarios you just described = in the next version of the draft. =20 > > Section 3.2.2, Paragraph 10: The discussion doesn't consider > > the distinction > > between a TCP and UDP session. Earlier in the text, the > > description of the > > state maintained in the firewall implies a distinction. But > > if a MIPv6 host > > is receiving TCP packets tunneled from the HA, then the > > firewall state will > > be for UDP (presuming it is set up at all). The firewall > > timers for UDP may > > interact negatively with the MN's TCP timeouts, and there=20 > may be other > > problems. >=20 > Can you please clarify what you mean? >=20 > jak>>> Sorry, I wasn't thinking clearly here. Obviously, the=20 > firewall will > step over the IP packet header and set up the proper state=20 > for TCP. There's > only an issue if a UDP tunnel is used, such as would be the=20 > case for IPsec, > and even in that case, it's not clear how serious the problem=20 > would be. > jak>>>(end) >=20 > jak>> Hope that helps. Yes, thank you. Franck _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Oct 26 16:29:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13700 for ; Tue, 26 Oct 2004 16:29:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMYA1-00057r-Nb for mip6-web-archive@ietf.org; Tue, 26 Oct 2004 16:43:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMXZQ-0000dj-LP; Tue, 26 Oct 2004 16:05:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMXRq-0005BR-M0 for mip6@megatron.ietf.org; Tue, 26 Oct 2004 15:57:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08908 for ; Tue, 26 Oct 2004 15:57:36 -0400 (EDT) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMXfX-0003mI-OI for mip6@ietf.org; Tue, 26 Oct 2004 16:11:49 -0400 Message-ID: <01da01c4bb96$27602f40$656115ac@dcml.docomolabsusa.com> From: "James Kempf" To: , References: <57A26D272F67A743952F6B4371B8F811017CA9C0@daebe007.americas.nokia.com> Subject: Re: [Mip6] Review of draft-ietf-mip6-firewalls-00.txt (with referenceto draft-chen-mip6-gprs-02.txt) Date: Tue, 26 Oct 2004 12:58:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Franck, >> jak>>> I'm not clear what you mean. Is this document intended to be a >> comprehensive exploration of the problems involved in >> firewall interaction >> with MIPv6 or not? If not, then we clearly need another document that >> explores the problems this one doesn't. > >The initial intent of the document was not to list all the possible problems between the Mobile IPv6 protocol and >firewalls, but to describe the main ones. However we could include the scenarios you just described in the next version > of the draft. Yes, I think that would be helpful. Especially if the draft ends up generating some requirements for other WGs, for example, to allow communication with the firewall. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Oct 26 21:56:41 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20270 for ; Tue, 26 Oct 2004 21:56:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMdH8-0000tA-4P for mip6-web-archive@ietf.org; Tue, 26 Oct 2004 22:10:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMd1T-0001Br-5F; Tue, 26 Oct 2004 21:54:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMd0r-0000sg-Jv; Tue, 26 Oct 2004 21:54:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20193; Tue, 26 Oct 2004 21:54:06 -0400 (EDT) Received: from tyo202.gate.nec.co.jp ([202.32.8.202]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMdEb-0000qK-PG; Tue, 26 Oct 2004 22:08:22 -0400 Received: from mailgate3.nec.co.jp (mailgate53.nec.co.jp [10.7.69.162] (may be forged)) by tyo202.gate.nec.co.jp (8.11.7/3.7W01080315) with ESMTP id i9R1rJn26272; Wed, 27 Oct 2004 10:53:21 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id i9R1rJg07967; Wed, 27 Oct 2004 10:53:19 +0900 (JST) Received: from dns02.ubq.nec.co.jp (dns02.ubq.nec.co.jp [10.17.225.2]) by mailsv.nec.co.jp (8.11.7/3.7W-MAILSV-NEC) with ESMTP id i9R1rIx28641; Wed, 27 Oct 2004 10:53:18 +0900 (JST) Received: from dns03.ubq.nec.co.jp (dns03.ubq.nec.co.jp [10.17.225.65]) by dns02.ubq.nec.co.jp (8.11.7/8.11.7) with ESMTP id i9R1r3I09112; Wed, 27 Oct 2004 10:53:03 +0900 (JST) Received: from localhost ([10.17.226.96]) by dns03.ubq.nec.co.jp (8.11.7/8.11.7) with ESMTP id i9R1r3W27699; Wed, 27 Oct 2004 10:53:03 +0900 (JST) To: ipv6@ietf.org, v6ops@ops.ietf.org, mip6@ietf.org X-Mailer: Mew version 1.94.2 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20041027105303P.kitamura@da.jp.nec.com> Date: Wed, 27 Oct 2004 10:53:03 +0900 From: Hiroshi KITAMURA X-Dispatcher: imput version 20000228(IM140) Lines: 46 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: anycast@anarg.jp Subject: [Mip6] Call for Participation on IPv6 Anycast discussion ML X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Dear All, People, who are interested in IPv6 Anycast discussion, please read this mail. I thing there are many people who are interested in IPv6 Anycast. Since IPv6 Anycast has many good potential functionalities, many people are expecting that it will be widely used in the real-world. Currently, IPv6 Anycast is only used at limited area for limited purpose. It is a pity that IPv6 Anycast is not widely used. This situation should be changed. A small IPv6 Anycast discussion team has been made by people who are interested in this topic. http://anycast.anarg.jp/ is a web site for IPv6 Anycast discussion. anycast@anarg.jp is a ML for it. People, who are interested in IPv6 Anycast discussion, please join this ML and let us know your comments. Let's discuss on IPv6 Anycast issues at this ML. (Instruction how to join the ML is written in above web site.) We have already issued four I-Ds on IPv6 Anycast. (Of course, they are under construction.) 1. IPv6 Anycast Terminology Definition 2. Applicability Statement of IPv6 Anycasting 3. A Protocol for Anycast Address Resolving 4. Possible Deployment Scenarios for IPv6 Anycasting You can find them at above web site. We'd like to have a Practical Anycasting BoF in the near future. We have already talked with Internet Area Directors on this issue. A draft for charter proposal is written in above web site, please read them and let us know your comments. Regards, Hiroshi _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Oct 27 03:37:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13178 for ; Wed, 27 Oct 2004 03:37:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMiaj-0007Zi-8u for mip6-web-archive@ietf.org; Wed, 27 Oct 2004 03:51:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMiLe-0007eP-Bp; Wed, 27 Oct 2004 03:35:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMiIP-00076Q-U1 for mip6@megatron.ietf.org; Wed, 27 Oct 2004 03:32:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12943 for ; Wed, 27 Oct 2004 03:32:35 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMiWE-0007UF-DT for mip6@ietf.org; Wed, 27 Oct 2004 03:46:54 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i9R74qi23528; Wed, 27 Oct 2004 00:04:52 -0700 X-mProtect: <200410270704> Nokia Silicon Valley Messaging Protection Received: from danira-pool05052.americas.nokia.com (10.241.50.52, claiming to be "[10.241.50.52]") by darkstar.iprg.nokia.com smtpdveWd2A; Wed, 27 Oct 2004 00:04:50 PDT Message-ID: <417F4EE5.1010509@iprg.nokia.com> Date: Wed, 27 Oct 2004 00:31:49 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Roe Subject: Re: [Mip6] MIPv6 use of IPsec References: <892867B805D4DA42A1C48103BF4CFA5A932122@EUR-MSG-20.europe.corp.microsoft.com> In-Reply-To: <892867B805D4DA42A1C48103BF4CFA5A932122@EUR-MSG-20.europe.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: 7bit hi, Michael Roe wrote: > At the ETSI IPv6 plugtest, I encountered some interoperability problems > with MIPv6 use of IPSec. I am starting to think that replacements for > RFC 3776 (e.g. the IKEv2 and MIPv6 document) ought to give more detail > on what is mandatory to implement - so that we can guarantee that a > conforming MN and a conforming HA will be able to talk to each other. > > There are (at least) three ways to IPSec protect RR and payload packets > between a MN and HA: > > a) RR signalling uses SA3/SA4; payload packets use IP-in-IP (not IPSec) encapulation > > b) RR signalling and payload packets use the SAME pair of Sas > > c) RR signalling and payload packets use a DIFFERENT pair of Sas > (SA4/SA4 for RR, SA7/SA8 for payload) > > The Microsoft implementation only supports option (b). I believe that > KAME can also support (b). > > RFC 3776 says this: > > o ESP encapsulation of the Home Test Init and Home Test messages > tunneled between the mobile node and home agent MUST be supported > and SHOULD be used. > > o ESP encapsulation of the ICMPv6 messages related to prefix > discovery MUST be supported and SHOULD be used. > > o ESP encapsulation of the payload packets tunneled between the > mobile node and home agent MAY be supported and used. > > But this isn't enough to guarantee interoperability. An implementation that > only supports (a) is conforming, but so is an implementation that only supports > (c), and the two don't interoperate. > > For example, RFC 3775 does not say that IP-in-IP encapsulation of payload > packets MUST be implemented. Should it? actually it does. RFC 2473 is referenced and there is the following text Each intercepted packet is tunneled to the mobile node's primary care-of address. This tunneling is performed using IPv6 encapsulation [15]. in section 8.5 o The node MUST be able to perform IPv6 encapsulation and decapsulation [15]. [15] is RFC 2473. > RFC 3775 isn't very clear on whether you should implement (b) or (c) if you > support ESP encapsulation of payload packets. both MN and HA must support a) and must support b) or c). they should use b) or c), if the reverse tunneled payload traffic needs to be protected by IPsec. they should use a), if the reverse tunneled payload traffic does not need IPsec protection. this is my understanding. > Part of the problem is that > the IPSec security policy database is an ordered list, but RFC 3775 doesn't > say what order the rules are in. Does the rule in section 5.2.4 have higher > priority than the rule in section 5.2.2 (in which case we have option b) or > is it the other way round (in which case we have option c)? the SPD entries in RFC 3776 are ordered. in section 5.2.2 Note that the rules in the SPD are ordered, and the ones in the previous section must take precedence over these ones. in section 5.2.4 It is assumed that the entries for protecting Binding Updates and Acknowledgements, and the entries to protect Home Test Init and Home Test messages take precedence over these entries. you can have the following policy in your SPD to achieve (b). Mobile Node SPD OUT: IF interface = IPv6 tunnel to home_agent_1 & source = home_address_1 & destination = any & proto = any THEN USE SA some_tunnel_sa you can ignore the SPD entries in section 5.2.2 and 5.2.4 and have the just the above SPD. and you make sure you negotiate only such an SA with the Home Agent. > > The rules are: > > home agent SPD OUT: > - IF interface = IPv6 tunnel to home_address_1 & > source = any & destination = home_address_1 & > proto = MH > THEN USE SA SA4 > > home agent SPD OUT: > - IF interface = IPv6 tunnel to home_address_1 & > source = any & destination = home_address_1 & > proto = X > THEN USE SA SA8 > > Suppose have "interface = IPv6 tunnel to home_address_1", source = any, > destination = home_address_1 and proto = MH. Both rules match. Do we > use SA4 or SA8? they are ordered. so the first one matches. > Some practical considerations: > 1) For performance reasons, some people might want to use different crypto > transforms for SA3/4 and SA7/8, e.g. authentication-only for SA7/8. > > 2) The more SPD entries we have, the longer it takes to configure MIPv6: > there are more SPI values and crypto keys to enter manually. From a > usability point of view, 6 security associations are quicker to configure > than 8. > > 3) The "interface = IPv6 tunnel to home_address_1" business gives rise to > implementation problems that would make it non-trivial for us to support > both (b) and (c). if you are using IKE, there shouldnt be a problem negotiating security associations for either b) or c). but at any time, I see only either b) or c) used. not both. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Oct 27 10:45:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10239 for ; Wed, 27 Oct 2004 10:45:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMpH0-0006u2-Ak for mip6-web-archive@ietf.org; Wed, 27 Oct 2004 10:59:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMowh-00079y-Ln; Wed, 27 Oct 2004 10:38:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMooZ-0004Yi-RJ for mip6@megatron.ietf.org; Wed, 27 Oct 2004 10:30:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08596 for ; Wed, 27 Oct 2004 10:30:13 -0400 (EDT) Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMp2P-0006Ov-3Q for mip6@ietf.org; Wed, 27 Oct 2004 10:44:36 -0400 Received: from iraspam.ira.uni-karlsruhe.de ([141.3.10.6] helo=spamhost.ira.uka.de) by iramx2.ira.uni-karlsruhe.de with esmtp (Exim 3.30 #10) id 1CMooI-0006KL-00; Wed, 27 Oct 2004 16:29:58 +0200 Received: from amavis by spamhost.ira.uka.de with scanned-ok (Exim 3.30 #3) id 1CMooH-0004ts-00; Wed, 27 Oct 2004 16:29:57 +0200 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by spamhost.ira.uka.de with esmtp (Exim 3.30 #3) id 1CMooD-0004th-00; Wed, 27 Oct 2004 16:29:53 +0200 Received: from i72chvogt.tm.uni-karlsruhe.de ([141.3.71.83]) by iramx2.ira.uni-karlsruhe.de with asmtp (Exim 3.30 #10) id 1CMooD-0006KA-00; Wed, 27 Oct 2004 16:29:53 +0200 Message-ID: <417FB0DA.80207@tm.uka.de> Date: Wed, 27 Oct 2004 16:29:46 +0200 From: Christian Vogt User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jianying Zhou , baofeng@i2r.a-star.edu.sg, robertdeng@smu.edu.sg, qiuying@i2r.a-star.edu.sg, jyzhou@i2r.a-star.edu.sg Subject: Re: [Mip6] RR protocol References: <4148080E.10009@i2r.a-star.edu.sg> <41481E0B.6000904@kolumbus.fi> In-Reply-To: <41481E0B.6000904@kolumbus.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: 7bit Cc: Jari Arkko , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: 7bit Hi folks! Jianying Zhou wrote: >> Does the improvement of RR protocol given in >> [...]draft-qiu-mip6-rr-improvement-00.txt >> provide better security without additional cost? Jari Arkko wrote: > I don't know about the "better security" part -- I would have to > think about this in detail. However, I think I can answer for the > "without additional cost" part. [...] Maybe, I can add a bit on the "better-security" part. Here are a few comments on your draft [1]... My first comment is on movement-halting attacks (section 3.2). I agree that an attack like this is possible. Actually, this is what [2] calls a "time-shift attack": get a token at one time and use it at another time. Note that the movement-halting attack can be even simpler than the one you describe in your draft. Since you assume that the MN moves rapidly enough such that the previous Care-of Keygen Token is still valid when the MN is at its new place, it wouldn't surprise if the previous Home Keygen Token is still fresh as well. So, the attacker could even use both tokens from the previous RR in order to redirect the MN's packet back to the old CoA. Note that this attack is simpler for the attacker to accomplish than the attack in your draft: Here, the attacker does not need to follow the MN to the new location. In your draft, it needs to. Second, traffic-permutation attacks. This kind of attack is interesting. It's a variation of the attack where the perpetrator redirects a MN's (or a stationary node's) packets to a random IP address (section 3.1.5 of [2]). But note that it is well-known that RR is vulnerable to an attacker inside the CN's network (more precisely: somewhere on the intersection of all paths between the CN and one of the victims). The attacker can impersonate any other node in this position, and it can redirect other nodes' packets to any IP address. One way of doing this is the method you describe in your draft. (Although I don't quite understand why the CN would accept a spoofed Binding Update only with probability 1/4. The probability should be 1.0 unless you consider things like nonce-lifetime expiration...) Ok, my last comment is on your improvement proposal. Your argumentation is interesting, but I am not sure about the benefit your proposal has. Consider that, at some point, an attacker must do something actively. There is no passive attack against the RR except dropping messages. And we know that RR is vulnerable to an attacker on the path between the CN and the MN's HA (section 3.1.1 of [2]). In this position, the attacker can send its own HoTI with the victim's HoA (and, if we apply your proposed improvement, with a CoA that the attacker chooses). Due to its position, the attacker can intercept the HoT. The attacker would then send a CoTI, again with the victim's HoA (and, if we follow your proposal, the chosen CoA). The attacker must send the CoTI from a place where it can intercept the CoT. This attack is possible in the RR as defined in RFC 3775, and it is still possible with your approach. I might be missing something. If so, don't hesitate to tell me. ;-) Bye, see you in Washington D.C... - Christian [1] Improvement of Return Routability Protocol draft-qiu-mip6-rr-improvement-00.txt [2] Mobile IP version 6 Route Optimization Security Design Background draft-ietf-mip6-ro-sec-02.txt -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/ "Science knows only one commandment: contribute to science." (Bertolt Brecht) Jari Arkko wrote: > I don't know about the "better security" part -- I would have to > think about this in detail. > > However, I think I can answer for the "without additional cost" > part. If the home and care-of addresses are bound to each other > in the HOTI/COTI signaling, this implies that a HOTI/HOT you did > 30 seconds ago in your previous attachment point is no longer > valid in this new attachment point. This implies more latency > at the new attachment point, if you have to redo HOTI/HOT. > > So it seems that there is additional cost. > > --Jari > > Jianying Zhou wrote: > >> In the RR protocol, any pair of home keygen token and care-of keygen >> token can generate a valid binding key as long as the indexes, i and >> j, are still valid. >> >> Does the improvement of RR protocol given in >> http://www.ietf.org/internet-drafts/draft-qiu-mip6-rr-improvement-00.txt >> provide better security without additional cost? >> >> In that proposal, HoA and CoA are bound together. A mobile node MN sends >> >> HoTI = {HoA, CNA, CoA, CKh} and CoTI = {CoA, CNA, HoA, CKc} >> to a correspondent node CN, which replies with the home keygen token >> >> KTh = HMAC_SHA1(Kcn, (HoA|Nj|CoA|0)) and the care-of keygen token >> KTc = HMAC_SHA1(Kcn, (CoA|Ni|HoA|1)). _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Oct 27 15:40:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06703 for ; Wed, 27 Oct 2004 15:40:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMtt6-0005NP-GV for mip6-web-archive@ietf.org; Wed, 27 Oct 2004 15:55:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMtaA-0008Pf-Vk; Wed, 27 Oct 2004 15:35:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMtUz-0004rc-Va for mip6@megatron.ietf.org; Wed, 27 Oct 2004 15:30:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05656 for ; Wed, 27 Oct 2004 15:30:19 -0400 (EDT) From: Basavaraj.Patil@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMtit-0005Am-KE for mip6@ietf.org; Wed, 27 Oct 2004 15:44:45 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9RJUHw16255 for ; Wed, 27 Oct 2004 22:30:17 +0300 (EET DST) X-Scanned: Wed, 27 Oct 2004 22:29:56 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i9RJTuj9006682 for ; Wed, 27 Oct 2004 22:29:56 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00qOkQFx; Wed, 27 Oct 2004 22:29:55 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9RJTsa03462 for ; Wed, 27 Oct 2004 22:29:54 +0300 (EET DST) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 27 Oct 2004 14:29:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Oct 2004 14:29:20 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF4403B1C079@daebe007.americas.nokia.com> Thread-Topic: Privacy issues - Bar BoF proposal Thread-Index: AcS8W0Am+iEavVNTTV6vbXcYUWTM9w== To: X-OriginalArrivalTime: 27 Oct 2004 19:29:24.0277 (UTC) FILETIME=[440A0650:01C4BC5B] X-Spam-Score: 0.3 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable Subject: [Mip6] Privacy issues - Bar BoF proposal X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: quoted-printable Privacy concerns are a topic of interest when dealing with mobility. The MIP6 WG has previously touched on the aspect of privacy during WG meetings and on the mailing list. The WG charter currently does not include any mention of privacy. The primary thinking as far as privacy goes in the WG has been that all data should be reverse tunnelled from the MN via its HA if maintaining privacy is a concern. However this deals with just one aspect of privacy, i.e location privacy. There are a number of other perspectives and issues dealing with privacy. Additionally=20 operators deploying Mobile IPv6 will need to deal with privacy requirements coming from a regulatory perspective. I-D : draft-haddad-momipriv-problem-statement-00 deals with privacy We would like to have a Bar BoF at IETF61 to discuss this idea further and determine: 1. If privacy issues are a topic of interest within the scope of the MIP6 work and hence needs to be dealt with within the WG 2. If the scope of privacy is broader than just mobility, how should we proceed with this work. Details of the Bar BoF will be made available on the MIP6 WG list soon. -Basavaraj _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Oct 27 17:16:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16318 for ; Wed, 27 Oct 2004 17:16:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMvNG-00080S-8o for mip6-web-archive@ietf.org; Wed, 27 Oct 2004 17:30:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMv0X-0003qR-W0; Wed, 27 Oct 2004 17:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMunM-0003uw-Mn for mip6@megatron.ietf.org; Wed, 27 Oct 2004 16:53:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12965 for ; Wed, 27 Oct 2004 16:53:22 -0400 (EDT) From: Basavaraj.Patil@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMv1H-00079a-KT for mip6@ietf.org; Wed, 27 Oct 2004 17:07:49 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9RKrK325610 for ; Wed, 27 Oct 2004 23:53:20 +0300 (EET DST) X-Scanned: Wed, 27 Oct 2004 23:53:15 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i9RKrFJw031840 for ; Wed, 27 Oct 2004 23:53:15 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00RYz4B8; Wed, 27 Oct 2004 23:53:13 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9RKrCa05467 for ; Wed, 27 Oct 2004 23:53:12 +0300 (EET DST) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 27 Oct 2004 15:52:45 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Oct 2004 15:52:45 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF4403B1C07E@daebe007.americas.nokia.com> Thread-Topic: Draft agenda of MIP6 WG meeting at IETF61 Thread-Index: AcS8ZueqbLm4mY26RXONauCs00BJHw== To: X-OriginalArrivalTime: 27 Oct 2004 20:52:45.0529 (UTC) FILETIME=[E9048490:01C4BC66] X-Spam-Score: 0.3 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable Subject: [Mip6] Draft agenda of MIP6 WG meeting at IETF61 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable Time and Date of WG meeting at IETF61: TBD Duration: 2.5 hours Agenda =3D=3D=3D=3D=3D=3D 1. Agenda, Bluesheets, Note-takers and Jabber scribes 5 Mins 2. WG status update Chairs 10 Mins 3. MIP6 Operation with IKEv2 and the revised IPsec Arch. 10 Mins I-D: draft-ietf-mip6-ikev2-ipsec-00.txt Vijay Devarapalli 4. a. Using IPsec to protect signaling between MN and CN 5 Mins I-D: draft-dupont-mipv6-cn-ipsec-01.txt b. Care-of address test procedure using a state cookie 5 Mins I-D: Annex of draft-dupont-mipv6-cn-ipsec-01.txt Francis Dupont 5. MIPv6 Authorization and Configuration based on EAP 10 Mins I-D: draft-giaretta-mip6-authorization-eap-02.txt Giaretta Gerardo =20 6. Application Master Session Key (AMSK) for Mobile IPv6 5 Mins I-D: draft-giaretta-mip6-amsk-00.txt Giaretta Gerardo =20 7. Goals for AAA-HA interface 10 Mins I-D: draft-giaretta-mip6-aaa-ha-goals-00.txt Giaretta Gerardo =20 8. AAA Mobile IPv6 Application Framework 10 Mins I-D: draft-yegin-mip6-aaa-fwk-00.txt Alper Yegin 9. Diameter Mobile IPv6 Bootstrapping Application using PANA 10 Mins I-D: draft-jee-mip6-bootstrap-pana-00.txt Junghoon Jee 10. Mobile IPv6 Bootstrapping Architecture Using DHCP 15 Mins I-D: draft-ohba-mip6-boot-arch-dhcp-00 Yoshihiro Ohba 11. Precomputable Binding Management Key Kbm for Mobile IPv6 5 Mins I-D: draft-ietf-mip6-precfgkbm-01.txt Charles Perkins 12. Improvement of Return Routability Protocol 10 Mins I-D: draft-qiu-mip6-rr-improvement-00.txt Jianying ZHOU 13. Next steps Chairs 5 Mins _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Oct 27 18:16:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21801 for ; Wed, 27 Oct 2004 18:16:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMwJR-0000iQ-4W for mip6-web-archive@ietf.org; Wed, 27 Oct 2004 18:30:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMw4K-0000nm-TV; Wed, 27 Oct 2004 18:15:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMvuy-0004pv-Ml for mip6@megatron.ietf.org; Wed, 27 Oct 2004 18:05:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20358 for ; Wed, 27 Oct 2004 18:05:17 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMw8v-0000SY-0e for mip6@ietf.org; Wed, 27 Oct 2004 18:19:45 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i9RM4eH27558; Thu, 28 Oct 2004 00:04:40 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i9RM4eSj025333; Thu, 28 Oct 2004 00:04:41 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200410272204.i9RM4eSj025333@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Michael Roe" Subject: Re: [Mip6] MIPv6 use of IPsec In-reply-to: Your message of Mon, 25 Oct 2004 17:29:36 BST. <892867B805D4DA42A1C48103BF4CFA5A932122@EUR-MSG-20.europe.corp.microsoft.com> Date: Thu, 28 Oct 2004 00:04:40 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Michael, can you resend (if not already done) your mail with a more common charset and encoding (i.e., not UTF-8 in base64) ? BTW I agree but for another reason: with IKEv2 you can have multiple traffic selectors for the same SPD entry so explicitly share SAs... Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Oct 27 19:45:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28725 for ; Wed, 27 Oct 2004 19:45:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMxhV-0002Wt-2y for mip6-web-archive@ietf.org; Wed, 27 Oct 2004 19:59:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMxNk-0007V5-Re; Wed, 27 Oct 2004 19:39:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMxM6-0007Ep-3w; Wed, 27 Oct 2004 19:37:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28227; Wed, 27 Oct 2004 19:37:22 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMxa3-0002Mv-GO; Wed, 27 Oct 2004 19:51:52 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i9RN9ac21731; Wed, 27 Oct 2004 16:09:36 -0700 X-mProtect: <200410272309> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "[205.226.2.40]") by darkstar.iprg.nokia.com smtpdrkY4hi; Wed, 27 Oct 2004 16:09:35 PDT Message-ID: <41803123.3060901@iprg.nokia.com> Date: Wed, 27 Oct 2004 16:37:07 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040816 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ville Nuorvala References: <7892795E1A87F04CADFCCF41FADD00FC3894F8@xmb-ams-337.emea.cisco.com> <418008F0.6060507@sun.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, mip6@ietf.org, Erik Nordmark Subject: [Mip6] Multiple address in RH type 2 (was Re: [nemo] RO taxonomy) X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit sorry for the cross posting, but here is something to consider when RFC 3775 is revised. Ville Nuorvala wrote: > On Wed, 27 Oct 2004, Erik Nordmark wrote: > > >>When the CN sends packets to HoA(MN) it would match the first binding. >>I don't think RFC 3775 prescribes what a CN should do when, after >>applying the binding and adding RH2 to the packet, there is another >>binding which matches what is then in the destination field of the >>packet. (But it would make sense to check this in the spec). >>So different CN implementations might do different things such as: >> - ignore the second binding >> - apply the second binding in a recursive way i.e. add another RH2 >> header >> - fail (drop the packet or crash) > > > RFC 3775 Section 6.1.7 says: > > Binding Updates for a care-of address which is not a unicast routable > address MUST be silently discarded. Similarly, the Binding Update > MUST be silently discarded if the care-of address appears as a home > address in an existing Binding Cache entry, with its current location > creating a circular reference back to the home address specified in > the Binding Update (possibly through additional entries). > > What this exactly means is open to interpretation. Strictly speaking it > might mean it is ok to have several linked entries as long as they don't > create a circular reference, but it is unlikely. yes, it should be possible to have several linked binding cache entries. > > I think the general assumption is that there will be just one RH type 2 > per packet. That's at least what we assume in MIPL, but of course I can't > speak on the behalf other implementations. but we seem to have disallowed by the above by mistake in RFC 3775. RFC 3775 restricts RH Type 2 to only one address (segments left is always 1). RFC 2460 says a routing header can occur only once in a packet. (except for destinations options header, all other extension headers can appear only once in a packet). RFC 3775 should have allowed more than one address in RH type 2 and required that the desination address on the packet and the next addressed to be processed in the routing header belong to the same node. this would have allowed us to include more than one address in the routing header, but still satisfy the security requiements of Mobile IPv6. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Oct 28 07:54:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04664 for ; Thu, 28 Oct 2004 07:54:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CN95b-0007Wl-Ht for mip6-web-archive@ietf.org; Thu, 28 Oct 2004 08:09:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN8mq-0002Qv-6N; Thu, 28 Oct 2004 07:49:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN8gX-0001R5-Mm; Thu, 28 Oct 2004 07:43:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03553; Thu, 28 Oct 2004 07:43:17 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CN8ub-00078j-I5; Thu, 28 Oct 2004 07:57:50 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 28 Oct 2004 14:00:25 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9SBg9TB000255; Thu, 28 Oct 2004 13:42:39 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 28 Oct 2004 13:42:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Oct 2004 13:39:52 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC3898BE@xmb-ams-337.emea.cisco.com> Thread-Topic: Multiple address in RH type 2 (was Re: [nemo] RO taxonomy) Thread-Index: AcS8fs+a9tlYOP+6RVSg7dgChKCVtAARw8MA From: "Pascal Thubert \(pthubert\)" To: "Vijay Devarapalli" , "Ville Nuorvala" X-OriginalArrivalTime: 28 Oct 2004 11:42:11.0865 (UTC) FILETIME=[29D52890:01C4BCE3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, mip6@ietf.org, Erik Nordmark Subject: [Mip6] RE: Multiple address in RH type 2 (was Re: [nemo] RO taxonomy) X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On=20 > Behalf Of Vijay Devarapalli > Sent: jeudi 28 octobre 2004 01:37 > To: Ville Nuorvala > Cc: nemo@ietf.org; mip6@ietf.org; Erik Nordmark > Subject: Multiple address in RH type 2 (was Re: [nemo] RO taxonomy) >=20 > sorry for the cross posting, but here is something to=20 > consider when RFC 3775 is revised. >=20 > Ville Nuorvala wrote: > > On Wed, 27 Oct 2004, Erik Nordmark wrote: > >=20 > >=20 > >>When the CN sends packets to HoA(MN) it would match the=20 > first binding. > >>I don't think RFC 3775 prescribes what a CN should do when, after=20 > >>applying the binding and adding RH2 to the packet, there is another=20 > >>binding which matches what is then in the destination field of the=20 > >>packet. (But it would make sense to check this in the spec). > >>So different CN implementations might do different things such as: > >> - ignore the second binding > >> - apply the second binding in a recursive way i.e. add another RH2 > >> header > >> - fail (drop the packet or crash) > >=20 > >=20 > > RFC 3775 Section 6.1.7 says: > >=20 > > Binding Updates for a care-of address which is not a=20 > unicast routable > > address MUST be silently discarded. Similarly, the=20 > Binding Update > > MUST be silently discarded if the care-of address=20 > appears as a home > > address in an existing Binding Cache entry, with its=20 > current location > > creating a circular reference back to the home address=20 > specified in > > the Binding Update (possibly through additional entries). > >=20 > > What this exactly means is open to interpretation. Strictly=20 > speaking=20 > > it might mean it is ok to have several linked entries as=20 > long as they=20 > > don't create a circular reference, but it is unlikely. >=20 > yes, it should be possible to have several linked binding=20 > cache entries. >=20 > >=20 > > I think the general assumption is that there will be just=20 > one RH type=20 > > 2 per packet. That's at least what we assume in MIPL, but=20 > of course I=20 > > can't speak on the behalf other implementations. >=20 > but we seem to have disallowed by the above by mistake in RFC 3775. >=20 > RFC 3775 restricts RH Type 2 to only one address (segments=20 > left is always 1). RFC 2460 says a routing header can occur=20 > only once in a packet. (except for destinations options=20 > header, all other extension headers can appear only once in a packet). >=20 > RFC 3775 should have allowed more than one address in RH type=20 > 2 and required that the desination address on the packet and=20 > the next addressed to be processed in the routing header=20 > belong to the same node. this would have allowed us to=20 > include more than one address in the routing header, but=20 > still satisfy the security requiements of Mobile IPv6. >=20 Agreed. That's actually part of the RRH spec.=20 There's also a rule that enforces that the RH2 can only be forwarded down the nested tree. If you look at=20 9.4 Processing of the extended Routing Header Type 2 in http://www.ietf.org/internet-drafts/draft-thubert-nemo-reverse-routing-h eader-05.txt You'll find that the constraint of teh next hop being in a same node is replaced by=20 =20 /* new security check */ if Address [i] doesn't belong to one of the Mobile Network prefixes { discard the packet return } Pascal _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Oct 28 15:50:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27556 for ; Thu, 28 Oct 2004 15:50:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNGWB-0007o3-D7 for mip6-web-archive@ietf.org; Thu, 28 Oct 2004 16:05:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNCq1-0007P6-HF; Thu, 28 Oct 2004 12:09:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNC7x-0007Df-VL; Thu, 28 Oct 2004 11:23:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26139; Thu, 28 Oct 2004 11:23:48 -0400 (EDT) Received: from mailout.zma.compaq.com ([161.114.64.103] helo=zmamail03.zma.compaq.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNCM3-0004qn-5L; Thu, 28 Oct 2004 11:38:23 -0400 Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 12A3FF2; Thu, 28 Oct 2004 11:23:12 -0400 (EDT) Received: from kitche.zk3.dec.com (kitche1.zk3.dec.com [16.140.160.161]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id 106C430C; Thu, 28 Oct 2004 10:23:10 -0500 (CDT) Received: from hp.com by kitche.zk3.dec.com (8.9.3/1.1.27.5/27Oct00-1235PM) id LAA0000789337; Thu, 28 Oct 2004 11:23:08 -0400 (EDT) Message-ID: <41810EDB.3070106@hp.com> Date: Thu, 28 Oct 2004 11:23:07 -0400 From: Brian Haley Organization: Linux Open Source Lab User-Agent: Mozilla/5.0 (X11; U; OSF1 alpha; en-US; rv:1.2) Gecko/20021205 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli References: <7892795E1A87F04CADFCCF41FADD00FC3894F8@xmb-ams-337.emea.cisco.com> <418008F0.6060507@sun.com> <41803123.3060901@iprg.nokia.com> In-Reply-To: <41803123.3060901@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, mip6@ietf.org, Ville Nuorvala , Erik Nordmark Subject: [Mip6] Re: Multiple address in RH type 2 (was Re: [nemo] RO taxonomy) X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: >>> When the CN sends packets to HoA(MN) it would match the first binding. >>> I don't think RFC 3775 prescribes what a CN should do when, after >>> applying the binding and adding RH2 to the packet, there is another >>> binding which matches what is then in the destination field of the >>> packet. (But it would make sense to check this in the spec). >>> So different CN implementations might do different things such as: >>> - ignore the second binding >>> - apply the second binding in a recursive way i.e. add another RH2 >>> header >>> - fail (drop the packet or crash) I know I purposefully did 1) to not have nesting problems, it's just been a while since I played with that code to remember more. >> RFC 3775 Section 6.1.7 says: >> >> Binding Updates for a care-of address which is not a unicast routable >> address MUST be silently discarded. Similarly, the Binding Update >> MUST be silently discarded if the care-of address appears as a home >> address in an existing Binding Cache entry, with its current location >> creating a circular reference back to the home address specified in >> the Binding Update (possibly through additional entries). >> >> What this exactly means is open to interpretation. Strictly speaking it >> might mean it is ok to have several linked entries as long as they don't >> create a circular reference, but it is unlikely. But how can this happen? If I'm a MN at COA1, would I ever send a BU to anyone to say COA1 is now at COA2? I would think you'd just update the existing binding to point at COA2. In the draft-thubert-nemo-reverse-routing-header-05.txt case, the HA would construct a multi-hop routing header, then send it to the first hop. What am I missing? > RFC 3775 should have allowed more than one address in RH type 2 > and required that the desination address on the packet and the next > addressed to be processed in the routing header belong to the same > node. this would have allowed us to include more than one address > in the routing header, but still satisfy the security requiements > of Mobile IPv6. I guess I don't agree 100% with this since RH2 was supposed to be a special case to hold the HoA. Extending it to have more than that seems to turn it into a glorified RH0 with MRs in it, but that's my opinion... -Brian _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Oct 28 15:52:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27874 for ; Thu, 28 Oct 2004 15:52:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNGXt-0007tR-Rs for mip6-web-archive@ietf.org; Thu, 28 Oct 2004 16:07:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNCsl-0001kO-59; Thu, 28 Oct 2004 12:12:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNCHB-0002Ik-60 for mip6@megatron.ietf.org; Thu, 28 Oct 2004 11:33:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28337 for ; Thu, 28 Oct 2004 11:33:18 -0400 (EDT) Received: from av1-1-sn3.vrr.skanova.net ([81.228.9.105]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNCV6-0005Zt-Eg for mip6@ietf.org; Thu, 28 Oct 2004 11:47:55 -0400 Received: by av1-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 02F7D37E60; Thu, 28 Oct 2004 17:32:33 +0200 (CEST) Received: from smtp1-2-sn3.vrr.skanova.net (smtp1-2-sn3.vrr.skanova.net [81.228.9.178]) by av1-1-sn3.vrr.skanova.net (Postfix) with ESMTP id E43AD37E4E for ; Thu, 28 Oct 2004 17:32:33 +0200 (CEST) Received: from shiraz.levkowetz.com (h195n1fls311o871.telia.com [213.64.174.195]) by smtp1-2-sn3.vrr.skanova.net (Postfix) with ESMTP id D13EB3800E for ; Thu, 28 Oct 2004 17:32:33 +0200 (CEST) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=h195n1fls311o871.telia.com) by shiraz.levkowetz.com with esmtp (Exim 4.34) id 1CNCGO-0002QH-Td for mip6@ietf.org; Thu, 28 Oct 2004 17:32:33 +0200 To: mip6@ietf.org From: Franck Le Date: Thu, 28 Oct 2004 15:32:31 +0000 MIME-Version: 1.0 Message-Id: <1098977551.13.0.655466819409.issue11@mip4.org> X-Roundup-Name: Mip6 issue tracker X-Roundup-Loop: hello X-Exim-Helo-Check-Failed: Verification failed for HELO h195n1fls311o871.telia.com X-SA-Exim-Connect-IP: 192.168.3.14 X-SA-Exim-Mail-From: roundup-admin@mip4.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on shiraz.levkowetz.com X-Spam-Status: No, hits=-2.1 required=3.0 tests=AWL,BAYES_00, X_HELO_CHECK_FAILED autolearn=no version=2.64 X-SA-Exim-Version: 4.1 (built Tue, 17 Aug 2004 11:06:07 +0200) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable Subject: [Mip6] [issue11] Editorial issues (for clarification) X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mip6 issue tracker List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable New submission from Franck Le : James Kempf proposed the following: 1) Add specific description of the addresses involved and established state= (or=20 not) in the firewall for the scenarios analyzed in sections 3.1 and 3.2 to=20 clarify the problems 2) Add the complex case when an MN moves from outside a firewall to inside,=20 with consideration of addresses and firewall state. Others: Section 3.2.2, starting about Paragraph 3: the description of why packets forwarded between the HA and MN might get dropped is not very clear. The problem seems to be that when a MN roams into an area of network topology controlled by a stateful firewall, there is no state in the firewall corresponding to (HA src addr, MN CoA dest addr). But this is never specifically articulated. Section 3.2.2, Paragraph 8: This point is true for any case where a session is initiated from outside the firewall, for example, an incoming VoIP call started by SIP. Why is MIPv6 any different? Section 3.2.3, Paragraph 5: This paragraph is not only true of RR packets but also of BU packets if the MN chooses to use ESP encryption for them as well. Consequently, it should be discussed in a separate section not specifically devoted to RR. Section 3.2.3, Paragraph 7: This paragraph is implying that the problem may be due to the lack of ability to detect firewalls. IPsec can deal with NATs because they can be detected. Why not simply come out and say this? Having the ability to detect and negotiate with a firewall is something that the IETF has (in my opinion) been needing for some time, and MIP only makes the case stronger. ---------- category: Editorial draft: draft-ietf-mip6-firewalls messages: 44 nosy: franck priority: Should fix status: Pending title: Editorial issues (for clarification) _________________________________________________ Mip6 issue tracker _________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Oct 28 15:53:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28199 for ; Thu, 28 Oct 2004 15:53:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNGZC-0007yT-Pi for mip6-web-archive@ietf.org; Thu, 28 Oct 2004 16:08:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CND0Q-000793-Ah; Thu, 28 Oct 2004 12:20:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNCLg-0004Eq-In for mip6@megatron.ietf.org; Thu, 28 Oct 2004 11:38:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29543 for ; Thu, 28 Oct 2004 11:37:58 -0400 (EDT) From: Franck.Le@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNCZl-00061y-I3 for mip6@ietf.org; Thu, 28 Oct 2004 11:52:34 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9SFbu320466; Thu, 28 Oct 2004 18:37:57 +0300 (EET DST) X-Scanned: Thu, 28 Oct 2004 18:37:05 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i9SFb5QR006836; Thu, 28 Oct 2004 18:37:05 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00SRUhgX; Thu, 28 Oct 2004 18:37:03 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9SFb2S15179; Thu, 28 Oct 2004 18:37:02 +0300 (EET DST) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 28 Oct 2004 10:36:35 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Review of draft-ietf-mip6-firewalls-00.txt (with referenceto draft-chen-mip6-gprs-02.txt) Date: Thu, 28 Oct 2004 10:36:34 -0500 Message-ID: <57A26D272F67A743952F6B4371B8F81103F299BA@daebe007.americas.nokia.com> Thread-Topic: [Mip6] Review of draft-ietf-mip6-firewalls-00.txt (with referenceto draft-chen-mip6-gprs-02.txt) Thread-Index: AcS7liTXcibWEEFDRfmcILj+nrbG6gBbYHhQ To: , X-OriginalArrivalTime: 28 Oct 2004 15:36:35.0647 (UTC) FILETIME=[E87FFCF0:01C4BD03] X-Spam-Score: 0.3 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable Hi James, > >The initial intent of the document was not to list all the possible > problems between the Mobile IPv6 protocol and >firewalls, but=20 > to describe > the main ones. However we could include the scenarios you=20 > just described in > the next version > of the draft. >=20 > Yes, I think that would be helpful. Especially if the draft ends up > generating some requirements for other WGs, for example, to allow > communication with the firewall. Ok, I agree with you. To keep track of the suggestions you gave, I = reported them on the issue tracker. http://www.mip4.org/issues/tracker/mip6/ Thank you again for your comments, Franck _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Oct 28 19:01:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05355 for ; Thu, 28 Oct 2004 19:01:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNJV8-0001sV-H5 for mip6-web-archive@ietf.org; Thu, 28 Oct 2004 19:16:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNGSO-0001hM-91; Thu, 28 Oct 2004 16:01:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNDtp-0005An-PD; Thu, 28 Oct 2004 13:17:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23413; Thu, 28 Oct 2004 13:17:19 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNE7v-0005CE-RC; Thu, 28 Oct 2004 13:31:56 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i9SHGbt20090; Thu, 28 Oct 2004 20:16:37 +0300 Date: Thu, 28 Oct 2004 20:16:37 +0300 (EEST) From: Pekka Savola To: "Soliman, Hesham" In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: nemo@ietf.org, mip6@ietf.org, mip4@ietf.org, miptrans@ops.ietf.org, v6ops@ops.ietf.org, Tsirtsis George Subject: [Mip6] Re: MIP and transition issues X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Hi, I've created a new mailing list to discuss Mobile IP transition issues. There is no single good mailing list to do that, and crossposting to upto 4 WGs is not a good idea. Address: miptrans@ops.ietf.org To subscribe: 'subscribe miptrans' in the body to majordomo@psg.com Web archives: http://ops.ietf.org/lists/miptrans/ **** DO NOT POST ANY FURTHER MESSAGES ON V6OPS LIST! **** (if you respond, please remove the other lists from Cc:) FWIW, I also noticed there is another related draft: Use of MIPv6 in IPv4 and MIPv4 in IPv6 networks draft-larsson-v6ops-mip-scenarios-00.txt (Larsson, Gustafsson, Levkowetz) As there have been various presentations on v6ops two times already, with no clear resolution, it would seem to be useful to have various people working on different documents bang their heads together on miptrans or offlist on which document(s) describing the problems and scenarios is the most appropriate as a basis for discussion. On Mon, 25 Oct 2004, Soliman, Hesham wrote: > Sorry for the cross posting, but this issue is being > discussed in all WG listed. > > I submitted the following two drafts last night: > draft-tsirtsis-dsmip-problem > draft-soliman-v4v6-mipv6- > > The first deals with the problem statement and the > second is one of the solution for using MIPv6 only. > There is another draft that proposes using MIPv4 > only: draft-tsirtsis-v4v6-mipv4 > > I hope we can discuss the problem statement and scenarios > in the next meeting. While the problem statement is on the mip6 > charter, it would be useful if we can have a slot allocated for > this in v6ops. > > thx > Hesham > > =========================================================== > This email may contain confidential and privileged material for the sole use > of the intended recipient. Any review or distribution by others is strictly > prohibited. If you are not the intended recipient please contact the sender > and delete all copies. > =========================================================== > > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Oct 28 19:18:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08305 for ; Thu, 28 Oct 2004 19:18:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNJlk-0002lb-Jy for mip6-web-archive@ietf.org; Thu, 28 Oct 2004 19:33:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNGYD-0006cY-KY; Thu, 28 Oct 2004 16:07:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNEnF-0002vQ-3S; Thu, 28 Oct 2004 14:14:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06761; Thu, 28 Oct 2004 14:14:36 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNF1L-0001HO-CR; Thu, 28 Oct 2004 14:29:12 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i9SIEWNH006039; Thu, 28 Oct 2004 12:14:33 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i9SIEUJQ000727; Thu, 28 Oct 2004 20:14:31 +0200 (MEST) Message-ID: <41813733.5030805@sun.com> Date: Thu, 28 Oct 2004 11:15:15 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Haley References: <7892795E1A87F04CADFCCF41FADD00FC3894F8@xmb-ams-337.emea.cisco.com> <418008F0.6060507@sun.com> <41803123.3060901@iprg.nokia.com> <41810EDB.3070106@hp.com> In-Reply-To: <41810EDB.3070106@hp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, mip6@ietf.org, Ville Nuorvala , Vijay Devarapalli Subject: [Mip6] Re: Multiple address in RH type 2 (was Re: [nemo] RO taxonomy) X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Brian Haley wrote: > But how can this happen? If I'm a MN at COA1, would I ever send a BU to > anyone to say COA1 is now at COA2? I would think you'd just update the > existing binding to point at COA2. > > In the draft-thubert-nemo-reverse-routing-header-05.txt case, the HA > would construct a multi-hop routing header, then send it to the first hop. > > What am I missing? The Nemo context where this was discussed. There might be a MR which will help a MNN by sending BUs on its behalf and the MNN might be a MIPv6 MN doing its own BUs. The MR only "sees" what the MNN has as its CoA so we end up with the MR creating a binding in the CN from CoA(MN) -> CoA(MR) and the MN creating a binding in the same CN from HoA(MN) -> CoA(MN). My question was whether RFC 3775 defined what would happen if this was done; for instance if it specified to ignore the second binding. Seems like it does not. Erik _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Oct 28 22:58:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28844 for ; Thu, 28 Oct 2004 22:58:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNNC3-0001hI-8p for mip6-web-archive@ietf.org; Thu, 28 Oct 2004 23:12:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNMEF-0004mO-Ab; Thu, 28 Oct 2004 22:10:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMdKK-0008Nb-74; Tue, 26 Oct 2004 22:14:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21330; Tue, 26 Oct 2004 22:14:13 -0400 (EDT) Received: from coconut.itojun.org ([221.249.121.227]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMdY5-0001FW-4N; Tue, 26 Oct 2004 22:28:30 -0400 Received: by coconut.itojun.org (Postfix, from userid 1001) id 419051C0CE; Wed, 27 Oct 2004 11:14:02 +0900 (JST) To: kitamura@da.jp.nec.com In-Reply-To: Your message of "Wed, 27 Oct 2004 10:53:03 +0900" <20041027105303P.kitamura@da.jp.nec.com> References: <20041027105303P.kitamura@da.jp.nec.com> X-Mailer: Cue version 0.8 (041013-0602/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20041027021402.419051C0CE@coconut.itojun.org> Date: Wed, 27 Oct 2004 11:14:02 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-Mailman-Approved-At: Thu, 28 Oct 2004 22:10:57 -0400 Cc: v6ops@ops.ietf.org, mip6@ietf.org, anycast@anarg.jp, ipv6@ietf.org Subject: [Mip6] draft-ata-ipv6-anycast-resolving-02.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a (sorry to spam 3 wgs, i have not received response to subscription request for anycast@anarg.jp yet) > draft-ata-ipv6-anycast-resolving-02.txt > A Protocol for Anycast Address Resolving due to the way the proposal resolves (or hides) anycast address into unicast address, we will experience a severe problem. application thinks that it is communicating with anycast address AA, but ARL (basically a NAT within client) translates it into unicast address. therefore, applications which embeds address into its protocol payload (like ftp) won't work as expected. section 4 (applicability statement) is not true. appendix A (how to map anycast address into unicast) basically has no security considerations. section 5 (security consideration) is also too weak. another issue with this approach is, that anycast is being used as service discovery mechnaism on the first contact only. anycast has other benefits such as failure recovery/tolerance. these benefits are gone with this draft. itojun _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Oct 29 05:50:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12815 for ; Fri, 29 Oct 2004 05:50:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNTdE-0002Gh-KY for mip6-web-archive@ietf.org; Fri, 29 Oct 2004 06:05:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNT1h-0007hN-UW; Fri, 29 Oct 2004 05:26:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNSiN-00043h-Ol; Fri, 29 Oct 2004 05:06:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09759; Fri, 29 Oct 2004 05:06:29 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNSwc-0001NA-TI; Fri, 29 Oct 2004 05:21:15 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 29 Oct 2004 11:23:57 +0200 X-BrightmailFiltered: true Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9T95brS024830; Fri, 29 Oct 2004 11:05:54 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 29 Oct 2004 11:05:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 29 Oct 2004 11:05:45 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC389BB7@xmb-ams-337.emea.cisco.com> Thread-Topic: Multiple address in RH type 2 (was Re: [nemo] RO taxonomy) Thread-Index: AcS9J1JAiXa8GtGyRU2PSR/FVxEFBAAbrpDA From: "Pascal Thubert \(pthubert\)" To: "Brian Haley" , "Vijay Devarapalli" X-OriginalArrivalTime: 29 Oct 2004 09:05:50.0173 (UTC) FILETIME=[7C5250D0:01C4BD96] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, mip6@ietf.org, Ville Nuorvala , Erik Nordmark Subject: [Mip6] RE: Multiple address in RH type 2 (was Re: [nemo] RO taxonomy) X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable >=20 > > RFC 3775 should have allowed more than one address in RH type 2 > > and required that the desination address on the packet and the next > > addressed to be processed in the routing header belong to the same > > node. this would have allowed us to include more than one address > > in the routing header, but still satisfy the security requiements > > of Mobile IPv6. >=20 > I guess I don't agree 100% with this since RH2 was supposed to be a special case > to hold the HoA. Extending it to have more than that seems to turn it into a > glorified RH0 with MRs in it, but that's my opinion... >=20 Well, there is a difference: we can (and must) put a restriction in the usage of the extended RH2. And that restriction is to go down the nested tree only. In particular if the source routed path in the RH2 is strict (not loose), we can force that the next entry in the RH is actually part of an MNP of the MR that processes the RH2. This is explicitly what the RRH draft says. Pascal _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Oct 29 06:34:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15181 for ; Fri, 29 Oct 2004 06:34:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNUKB-00037H-S5 for mip6-web-archive@ietf.org; Fri, 29 Oct 2004 06:49:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNThl-0006At-NA; Fri, 29 Oct 2004 06:09:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNTMH-0001b1-VB for mip6@megatron.ietf.org; Fri, 29 Oct 2004 05:47:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12454 for ; Fri, 29 Oct 2004 05:47:43 -0400 (EDT) Received: from clarinet.u-strasbg.fr ([130.79.90.157]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CNTaX-0002CI-Nv for mip6@ietf.org; Fri, 29 Oct 2004 06:02:30 -0400 Received: (qmail 31014 invoked for bounce); 29 Oct 2004 09:47:46 -0000 Received: from unknown (HELO ?10.0.0.1?) (montavont@unknown) by unknown with SMTP; 29 Oct 2004 09:47:46 -0000 Message-ID: <418211A9.4070102@clarinet.u-strasbg.fr> Date: Fri, 29 Oct 2004 11:47:21 +0200 From: Nicolas Montavont User-Agent: Mozilla Thunderbird 0.8 (X11/20040926) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com, mip6@ietf.org Subject: Re: [Mip6] Draft agenda of MIP6 WG meeting at IETF61 References: <697DAA22C5004B4596E033803A7CEF4403B1C07E@daebe007.americas.nokia.com> In-Reply-To: <697DAA22C5004B4596E033803A7CEF4403B1C07E@daebe007.americas.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7bit Cc: Thierry Ernst , Ryuji Wakikawa , Koojana Kuladinithi X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7bit Dear Basavaraj and folks, We just published a new version of our draft on Multihoming analysis in MIPv6. You can find the new version at http://www.ietf.org/internet-drafts/draft-montavont-mobileip-multihoming-pb-statement-02.txt This draft analyses the MIP6 behavior when a MN is multihomed and classifies the different cases when a MN is multihomed. It completes the generic draft (http://www.ietf.org/internet-drafts/draft-ernst-generic-goals-and-benefits-00.txt) which explains the goals and benefits we can expect from the multihoming of host. It would be good to have feedback from the working group on this work. We would like to request a short slot to discuss the interest of the Working Group on the multihoming. It is a long time that several drafts deal with MIPv6 and multihoming. Our two drafts could be the starting point to add a new item to the WG charter. These two drafts may define the problem statement of MN multhoming. Once more, please don't hesitate to comment both the drafts and the proposition to add a new item in the WG charter. Regards, Nicolas Basavaraj.Patil@nokia.com wrote: > > >Time and Date of WG meeting at IETF61: TBD >Duration: 2.5 hours > >Agenda >====== > >1. Agenda, Bluesheets, Note-takers and Jabber scribes 5 Mins > >2. WG status update Chairs 10 Mins > >3. MIP6 Operation with IKEv2 and the revised IPsec Arch. 10 Mins > I-D: draft-ietf-mip6-ikev2-ipsec-00.txt > Vijay Devarapalli > > >4. a. Using IPsec to protect signaling between MN and CN 5 Mins > I-D: draft-dupont-mipv6-cn-ipsec-01.txt > b. Care-of address test procedure using a state cookie 5 Mins > I-D: Annex of draft-dupont-mipv6-cn-ipsec-01.txt > Francis Dupont > >5. MIPv6 Authorization and Configuration based on EAP 10 Mins > I-D: draft-giaretta-mip6-authorization-eap-02.txt > Giaretta Gerardo > >6. Application Master Session Key (AMSK) for Mobile IPv6 5 Mins > I-D: draft-giaretta-mip6-amsk-00.txt > Giaretta Gerardo > >7. Goals for AAA-HA interface 10 Mins > I-D: draft-giaretta-mip6-aaa-ha-goals-00.txt > Giaretta Gerardo > >8. AAA Mobile IPv6 Application Framework 10 Mins > I-D: draft-yegin-mip6-aaa-fwk-00.txt > Alper Yegin > >9. Diameter Mobile IPv6 Bootstrapping Application using PANA 10 Mins > I-D: draft-jee-mip6-bootstrap-pana-00.txt > Junghoon Jee > >10. Mobile IPv6 Bootstrapping Architecture Using DHCP 15 Mins > I-D: draft-ohba-mip6-boot-arch-dhcp-00 > Yoshihiro Ohba > >11. Precomputable Binding Management Key Kbm for Mobile IPv6 5 Mins > I-D: draft-ietf-mip6-precfgkbm-01.txt > Charles Perkins > >12. Improvement of Return Routability Protocol 10 Mins > I-D: draft-qiu-mip6-rr-improvement-00.txt > Jianying ZHOU > > >13. Next steps Chairs 5 Mins > >_______________________________________________ >Mip6 mailing list >Mip6@ietf.org >https://www1.ietf.org/mailman/listinfo/mip6 > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Oct 29 13:02:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15744 for ; Fri, 29 Oct 2004 13:02:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNaNV-0003VL-Sa for mip6-web-archive@ietf.org; Fri, 29 Oct 2004 13:17:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNZzh-0006Dc-Fa; Fri, 29 Oct 2004 12:52:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNZlm-0005QN-Db; Fri, 29 Oct 2004 12:38:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13804; Fri, 29 Oct 2004 12:38:27 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNa04-0002vD-IC; Fri, 29 Oct 2004 12:53:18 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i9TGbP7q009942; Fri, 29 Oct 2004 09:37:25 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i9TGbMJQ029489; Fri, 29 Oct 2004 18:37:22 +0200 (MEST) Message-ID: <418271ED.5060102@sun.com> Date: Fri, 29 Oct 2004 09:38:05 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <7892795E1A87F04CADFCCF41FADD00FC389BB7@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC389BB7@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, mip6@ietf.org, Brian Haley , Vijay Devarapalli , Ville Nuorvala Subject: [Mip6] Re: Multiple address in RH type 2 (was Re: [nemo] RO taxonomy) X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > Well, there is a difference: we can (and must) put a restriction in the > usage of the extended RH2. And that restriction is to go down the nested > tree only. In particular if the source routed path in the RH2 is strict > (not loose), we can force that the next entry in the RH is actually part > of an MNP of the MR that processes the RH2. This is explicitly what the > RRH draft says. How would the strict restriction work when the mobile network (imagine a large cruise ship) has one or more layers of regular routers, and then the passangers arrive with their PANs that have their MRs? A strict routing check assumes that all the routers are listed. Erik _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Oct 29 20:36:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29575 for ; Fri, 29 Oct 2004 20:36:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNhSv-0006d1-Ot for mip6-web-archive@ietf.org; Fri, 29 Oct 2004 20:51:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNhAL-0007Tu-AZ; Fri, 29 Oct 2004 20:32:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNgwB-0007wZ-U7 for mip6@megatron.ietf.org; Fri, 29 Oct 2004 20:17:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28279 for ; Fri, 29 Oct 2004 20:17:42 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNhAY-0006IM-Uq for mip6@ietf.org; Fri, 29 Oct 2004 20:32:35 -0400 Received: from jurassic.eng.sun.com ([129.146.87.31]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i9U0Hf7q020472 for ; Fri, 29 Oct 2004 17:17:41 -0700 (PDT) Received: from shubho (shubho.SFBay.Sun.COM [129.146.73.85]) by jurassic.eng.sun.com (8.13.1+Sun/8.13.1) with SMTP id i9U0Hf45860559; Fri, 29 Oct 2004 17:17:41 -0700 (PDT) Message-Id: <200410300017.i9U0Hf45860559@jurassic.eng.sun.com> Date: Fri, 29 Oct 2004 17:17:18 -0700 (PDT) From: Samita Chakrabarti To: mip6@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: qf+93+oAcWA/u3q4v5S4VQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_54 SunOS 5.10 sun4u sparc X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: samita.chakrabarti@sun.com Subject: [Mip6] Last Call Comments: draft-ietf-mip6-firewalls-00.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Samita Chakrabarti List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Here are some comments for the mip6-firewalls draft: - RRT is mentioned several places in the document, please define this term in the begining - In the section 2.1 , it would be good to clarify the three areas of firewall packet filtering this document is addressing - such as addresses (src, dst), ports and protocols. - Section 2.2 talks about packet filtering problem in 3G networks, but I don't see much relevance of that in this document. This document structure may be modeled after that- this paragraph may be moved to appendix or to a different section toward the end ( to show that similar deployment problem exists in 3G networks). - section 3.1.1 "Return Routability Test sp" -- what is sp? typo? This section could be shorter with some more editing. It might be effective to point out the issue (COTI, but not HOTI) in the beginiing of the paragraph. It seems fig 2. could be replaced by fig 3- thus fig2 may be redundant. - section 3.1.2 last paragraph " Requiring the stateful inspection ...network" I am not sure if I understand the problem here. How does BU come into the picture? Previously it talks about COTI. I assume, the same problem applies to BU/BA between CN (within firewall) and MN (external) when RR is used. Also, if the firewall checks for MIP6 nexthdr and type (COTI, BU, BA), then it would not be a big issue- becuase the validity checks are supposed to happen at CN anyway. For DOS attack, I agree it is easier than sending packets for a particular port and upperlayer proto, but DOS attacks are hard to prevent. I guess we are going into solution space here- let's just state the issues. - section 3.2 Scenario when the inner node is a Mobile Node I think this section needs to discuss the two cases: 1) when MN moves within the same Firewalled network 2) when MN moves into the firewalled network from external network - section 3.2.1 Issue with ESP and Firewall: -- Firewall dropping ESP packets is a IPsec issue - which is not MIP6 problem. It should be solved though for deployment for MIP6. -- ESP protecting mobility header in transport mode or tunnel mode could be a problem if we want to allow MIP6 BU/BA between MN-HA in the firewall. You may want to clarify these two cases. -- section 3.2.2 This section discusses about state life time issue- but it is not clear to me how CN-MN come into question given that we were talking about MN-HA states. Is it talking about problem with IP-n_IP IPsec tunnel where the ESP header sits above the internal IPv6 header ( MN(HOA)-->HAA) ? This can be clarified by giving the packet sequence as described in RFC3776. -- section 3.2.3 This section needs editing for concise description. Also it needs to separate issues in subsections such as HOTI/HOT under ESP tunnel or COTI/COT or BU to the CN. This section is again trying to indicate some solutions - it may be good idea not to suggest that in this doc. -- section 3.2.4 ==> this really belongs to section 3.2 as one of the configurations. -- section 3.2.5 Please clarify two cases (without and with RR). If RR is not used then it is no different (wrt the new FW and MN) than external MN is moving into firewalled network as MN needs to rebuild a new tunnel to HA assuming its COA changes. BTW, it is good to see this document which discusses the real-life issues. Thanks, -Samita _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat Oct 30 21:47:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04978 for ; Sat, 30 Oct 2004 21:47:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CO53d-0006MB-Mp for mip6-web-archive@ietf.org; Sat, 30 Oct 2004 22:03:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CO4f5-0006NR-4n; Sat, 30 Oct 2004 21:37:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CO4ZY-0005e0-U3 for mip6@megatron.ietf.org; Sat, 30 Oct 2004 21:31:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04143 for ; Sat, 30 Oct 2004 21:31:54 -0400 (EDT) Received: from neon.tcs.hut.fi ([130.233.215.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CO4o9-00067X-R5 for mip6@ietf.org; Sat, 30 Oct 2004 21:47:02 -0400 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id BC5C88001B8 for ; Sun, 31 Oct 2004 03:31:23 +0200 (EET) Date: Sun, 31 Oct 2004 03:31:23 +0200 (EET) From: Wassim Haddad To: mip6@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Mip6] I-D ACTION:draft-haddad-mip6-cga-omipv6-03.txt (fwd) X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Applying Cryptographically Generated Addresses to Optimize MIPv6 (CGA-OMIPv6) Author(s) : W. Haddad, et al. Filename : draft-haddad-mip6-cga-omipv6-03.txt Pages : 28 Date : 2004-10-28 This memo suggests a new and enhanced route optimization security mechanism for Mobile IPv6 (MIPv6). The primary motivation for this new mechanism is the reduction of signaling load and handoff delay. The performance improvement achieved is elimination of all signaling while not moving, and 33% of the per-movement signaling. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-haddad-mip6-cga-omipv6-03.txt Regards, Wassim H. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6